-
-
AutonomyOS
-
Pipeline History
-
Jobs
-
Tests
Inspiration
Software development has become remarkably good at generating code, yet delivering that code safely to production remains a fragmented, coordination-heavy process. An issue may be clearly defined, but turning it into a reliable software change still involves a chain of disconnected activities: understanding requirements, navigating a repository, implementing a solution, running tests, investigating failures, reviewing security implications, managing merge requests, deploying changes, and verifying application health.
The real bottleneck is not always the act of writing code. It is everything that must happen correctly before and after the code is written.
We were inspired by a fundamental question: What if a software issue could become the starting point of an autonomous delivery workflow rather than another task that requires constant human coordination?
That question led to AutonomyOS.
Our vision is to move beyond isolated AI-assisted coding toward a system that coordinates the broader software delivery lifecycle. Instead of stopping when code is suggested, an autonomous delivery system should know what needs to happen next, gather evidence, respond to failures within defined limits, preserve execution history, and communicate the actual outcome.
This vision aligns directly with the Best Hands-off Agent track of Life After Code. The objective is not to remove human accountability or automate every action indiscriminately. It is to eliminate unnecessary handoffs while retaining the controls that make software delivery trustworthy.
We wanted to explore a model in which humans define the intended outcome and the permitted boundaries, while the system handles as much of the execution, validation, and recovery as its configured capabilities allow.
What it does
AutonomyOS is a GitLab-native software delivery system designed to coordinate the journey from an issue to validated code and, where the necessary integrations are available, deployment and post-deployment verification.
Its core idea is to treat delivery as a connected workflow with explicit states, persisted execution records, validation gates, and meaningful failure handling.
1. From issue to workflow
The process begins with a GitLab issue event. A webhook receiver accepts the event, validates the request, and routes eligible work into the workflow orchestrator.
The webhook layer is designed to support signature verification, payload validation, and duplicate-event protection. This establishes a controlled entry point for issue-driven automation.
2. Understand and implement
The issue-analysis component interprets the requested change and helps establish the work required. An implementation agent can then be connected to produce or modify code within the available repository and execution environment.
The objective is to connect the original request to a concrete implementation rather than treating issue analysis and code generation as unrelated activities.
Actual code generation depends on a functioning coding-agent integration; receiving an issue alone does not mean an implementation has been completed.
3. Validate before delivery
A proposed change must be evaluated before it advances. AutonomyOS includes components for test execution and security scanning, allowing the workflow to record available validation results and determine whether the change satisfies its configured requirements.
The intended approach is evidence-driven: actual test results and scanner findings should determine the next action. A failed check must remain a failure until it is resolved or explicitly reported as blocked.
4. Recover from eligible failures
Failures are an expected part of software engineering. Rather than treating every failure as the end of the workflow, AutonomyOS is designed to support bounded repair attempts when an actionable error and a functioning implementation agent are available.
The intended recovery cycle is to capture the failure, examine the diagnostic evidence, attempt an appropriate correction, and rerun the relevant checks. If recovery does not succeed within the configured limit, the workflow should stop safely and report what remains unresolved.
This makes recovery a controlled engineering operation rather than an unbounded loop of repeated attempts.
5. Manage merge requests and deployment
After the required validation gates pass, the system is designed to coordinate merge-request operations through GitLab. It must respect repository permissions, branch protections, required checks, and approval policies.
Deployment adapters for Docker and Kubernetes provide integration points for configured environments. A health-verification component is intended to determine whether a deployment is operating as expected, while supported rollback mechanisms can provide a recovery path for unhealthy releases.
These capabilities depend on their corresponding integrations, permissions, and infrastructure being configured and verified.
6. Preserve evidence and report outcomes
AutonomyOS includes a database layer, workflow orchestration, reporting components, and dashboard API routes intended to expose execution status and history.
The objective is to make the delivery process inspectable. A reviewer or operator should be able to understand what was attempted, which checks ran, where a failure occurred, and whether the workflow completed or was blocked.
The system's defining objective is therefore not simply to automate more steps. It is to coordinate those steps into a traceable delivery process with explicit outcomes.
How we built it
AutonomyOS is organized around a modular Python application using Flask for HTTP endpoints and webhook handling, with separate components for orchestration, GitLab communication, analysis, implementation, testing, security validation, deployment, health verification, and reporting.
This separation allows the workflow engine to coordinate the delivery process without placing every responsibility inside a single application function.
Workflow orchestration
The orchestrator serves as the coordination layer. It is responsible for advancing eligible work through the workflow, tracking state transitions, handling errors, and maintaining execution history.
Webhook processing and event deduplication help prevent repeated incoming events from creating unintended duplicate work.
Persistence and observability
The database layer supports workflow records and execution history. SQLite provides a lightweight option for local development and testing, while PostgreSQL is supported as a production database option.
Dashboard API routes are intended to expose workflow summaries, individual workflow details, and metrics. These interfaces help make execution state accessible to both the application and its observers.
GitLab integration
A dedicated GitLab client separates API operations from workflow logic. This makes it possible to configure authentication and project access independently of the orchestration code.
GitLab integration requires appropriate credentials and permissions. For local testing, external-service boundaries can be replaced with deterministic test doubles so that application behavior can be validated without depending on a live GitLab account.
Mock-based tests and live integration tests serve different purposes: the former validate local behavior, while the latter establish whether the external integration works in the configured environment.
Testing and CI/CD
Pytest is used to exercise application behavior and workflow components. The GitLab CI/CD configuration provides a repeatable place to install dependencies and run automated checks.
The purpose of this validation process is to catch implementation errors early and preserve evidence of the checks that actually ran. A green pipeline is useful evidence of code health, but it does not independently prove that an external coding agent, live merge, or production deployment has succeeded.
Deployment and recovery architecture
The deployment controller and health-verification components separate delivery operations from post-deployment checks. Docker and Kubernetes adapters provide paths for connecting the application to supported deployment environments.
Celery and Redis can support background task processing when configured. These components require the relevant broker, worker, and environment configuration.
Across these layers, the design principle is consistent: separate responsibilities, persist important events, handle failures explicitly, and distinguish verified outcomes from unavailable integrations.
Challenges we ran into
One of the central challenges was ensuring that components designed to work together also behaved correctly when external dependencies were unavailable.
External authentication and test isolation
GitLab authentication introduced a concrete testing challenge. The CI pipeline reported 401 Unauthorized errors in endpoint and end-to-end tests, indicating that some test paths were attempting authenticated GitLab operations despite the intended offline configuration.
This exposed an important architectural requirement: local application tests should not depend accidentally on live external credentials. Tests must isolate external-service boundaries, while live integration tests should explicitly validate authentication and permissions.
The correct solution is to fix client initialization, dependency injection, and test fixtures—not to weaken production authentication or suppress the errors.
Coordinating workflow state
A multi-stage delivery workflow must maintain a coherent state even when a stage fails, a request is repeated, or an external service becomes unavailable.
This requires careful handling of transitions, event deduplication, persistence, retries, and exceptions. A request being accepted is not the same as a workflow being completed, and a workflow record existing is not proof that code was generated or deployed.
Distinguishing implementation from integration
A deployment adapter, task definition, or agent interface can establish an integration point without proving that the corresponding external operation has succeeded.
AutonomyOS therefore needs explicit boundaries between implemented components, mock-based validation, configured integrations, and verified live execution. This distinction is particularly important for code generation, security scanning, merging, deployment, and rollback.
Reliability without unsafe shortcuts
Making an automated pipeline green is valuable only if its tests continue to detect genuine failures. Removing failing tests, bypassing authentication, or reporting false success would undermine the purpose of the system.
The challenge is to make the project reliable without compromising the security and validation controls that autonomous delivery requires.
Accomplishments that we're proud of
We are proud of establishing a modular foundation for an issue-driven software delivery system rather than building only a standalone code-generation interface.
The project brings together several important responsibilities:
- A Flask application with health and workflow API endpoints.
- A GitLab webhook receiver and event-deduplication component.
- A workflow orchestrator and state-management layer.
- Database-backed workflow records and execution history.
- Separate components for issue analysis and implementation.
- Test-execution and security-scanning interfaces.
- Repair-agent and merge-request handling components.
- Docker and Kubernetes deployment adapters.
- Health-verification and reporting components.
- Dashboard API routes for inspecting workflow information.
- Pytest configuration and GitLab CI/CD integration.
We are also proud of the emphasis on failure visibility and controlled recovery. The goal is not to produce a success message at any cost; it is to make the system's actual state understandable and its actions traceable.
These components establish the architectural foundation for the hands-off delivery vision. Their presence should not be confused with verification that every external integration is fully operational. The strongest evidence of progress comes from passing tests, successful pipeline runs, persisted workflow records, and demonstrated integration results.
What we learned
Building AutonomyOS reinforced a fundamental lesson about autonomous engineering: generating a change is only one part of delivering software reliably.
A useful autonomous system must also understand its environment, validate its actions, recover within safe limits, preserve state, and report the truth about its outcomes.
We learned that orchestration is as important as the individual agents. Without clear workflow states, reliable persistence, and meaningful error handling, a collection of capable components can still produce an unreliable system.
We also learned the importance of isolating external services during testing. Local tests should be deterministic and reproducible, while live integration tests should verify authentication, permissions, and actual API behavior.
Another lesson was that safety controls must be part of the workflow itself. Bounded retries, protected-branch policies, authorization checks, deployment health verification, and accurate failure reporting are not optional additions to autonomy; they are what make automation trustworthy.
Finally, we learned to distinguish architectural ambition from demonstrated capability. A convincing engineering project must explain not only what it is designed to do, but also what has been implemented, what has been tested, and what still depends on external configuration.
What's next for AutonomyOS
The next stage is to strengthen the connection between the existing application components and verified end-to-end execution.
Our priorities are:
- Reliable CI: Resolve authentication-related test failures and establish a repeatable, fully passing required test pipeline.
- Reproducible local execution: Ensure the application starts reliably, initializes its database, and processes test events without requiring live credentials for offline tests.
- Verified issue-to-workflow execution: Demonstrate an issue event creating a persisted workflow with accurate state transitions and an inspectable outcome.
- Working implementation-agent integration: Connect a functioning coding agent and verify that it produces actual code changes.
- Evidence-based repair: Demonstrate a controlled test failure, a bounded repair attempt, and successful revalidation where recovery is possible.
- Authorized GitLab operations: Verify merge-request handling against an isolated test project while preserving required repository protections.
- Real deployment verification: Exercise a configured staging environment, health checks, and rollback behavior where the necessary infrastructure is available.
- Transparent evidence: Publish sanitized logs, accessible pipeline links, reproducible setup instructions, and a demonstration that clearly distinguishes live operations from simulations.
The longer-term vision is a delivery system that can take a well-defined issue, execute the permitted engineering work, validate the result, recover from eligible failures, and deliver a clear report with minimal routine human intervention.
AutonomyOS is being developed around a simple principle: autonomy should not mean less accountability. It should mean less unnecessary coordination, more consistent execution, and better evidence of what happened.
AutonomyOS — From issue to production, with autonomy, traceability, and control.
Log in or sign up for Devpost to join the conversation.