--- title: "Autonomous Loop" description: "An open-source engineering experiment exploring resumable, verifiable and bounded autonomous software execution." date: "2026-08-28" updated: "2026-08-28" type: project topics: - "Agentic Systems" - "Engineering" canonical: "https://dalugoda.com/autonomous-loop" github: "https://github.com/asiridalugoda/autonomous-loop" --- ## The execution engine behind the Agentic Sprint An Agentic Sprint needs more than an orchestrator and a collection of coding agents. It needs a reliable execution protocol. For the implementation layer, I use **Autonomous Loop**, an open-source agentic engineering system I developed for long-running, unattended software work. Autonomous Loop was designed around a simple problem: **An agent completing one prompt is not the same as an engineering system completing a body of work reliably.** Large engineering tasks involve: - interruptions - dependencies - failed approaches - verification - context loss - parallel work - repeated iterations. Autonomous Loop provides the execution discipline underneath the Agentic Sprint. ### In brief - The model keeps execution state in the repository instead of relying on one model session. - Approved plans become dependency-ordered goals with explicit verification conditions. - The agent that makes a change is not the only agent that checks it. - Tests, reviews and evidence provide stopping conditions for each goal. - Failures are recorded as state so later sessions can resume the work. - Parallel work is isolated through Git worktrees and bounded by role-based permissions. - Autonomous Loop is the execution protocol; the Agentic Sprint is the wider human-governed delivery model. ## 1. Keep execution state outside the model LLM sessions are temporary. The repository is not. Autonomous Loop therefore keeps execution state outside the model through a persistent project spine: - `LOOP.md` - `GOALS.md` - `BOARD.md` - `handover.md` - audit artefacts - `EXPERIMENTS.md` where optimisation work is involved. An agent session can terminate, restart or move to another execution environment without losing the state of the engineering task. The Agentic Sprint therefore does not depend on one continuous model conversation. The repository becomes the source of execution truth. ## 2. Turn requirements into verifiable goals Once the Build Plan has passed Human Gate One, the approved plan is converted into a dependency-ordered goal ladder. For example: 1. **G1: add cancellation domain state.** A scheduled payment can transition from `Scheduled` to `Cancelled`, but a processed payment cannot. 2. **G2: implement the cancellation API.** An authorised customer can cancel an eligible payment and receives the correct API response. 3. **G3: prevent cancelled payment execution.** A cancelled payment cannot subsequently enter the processing workflow. 4. **G4: add audit evidence.** Every successful cancellation produces the required immutable audit event. The implementation is no longer simply “build this Jira ticket”. It becomes a request to complete an ordered set of independently verifiable engineering outcomes. That distinction matters. Agents operate more reliably when large objectives are decomposed into bounded stopping conditions. ## 3. Separate making from checking One of the core Autonomous Loop rules is: **The agent that creates an implementation cannot be the sole agent that determines whether the implementation is correct.** The implementation agent is the **Maker**. Independent agents can act as: - Code Reviewer - Verifier - Security Auditor - Red Team, where required. This principle makes separation of duties part of the Agentic Sprint topology rather than merely a prompt instruction. In security-sensitive areas the loop can require additional security review and an explicit audit artefact. Those areas include: - authentication - authorisation - tenant isolation - financial transactions - destructive migrations - privileged operations - production controls. The creator cannot mark its own work as complete. :::figure autonomous-loop-topology The Autonomous Loop topology inside an Agentic Sprint. The figure should show a coordinator assigning bounded work to a Maker, independent reviewers and a verifier, with failure returning the work to a recorded rework state and production capability remaining outside the autonomous execution plane. ::: ## 4. Test first and capture evidence For specification-driven work, Autonomous Loop uses a red-to-green cycle. Each goal begins with a machine-verifiable representation of its acceptance condition. The execution sequence is: 1. Load the relevant context. 2. Select the next goal. 3. Write a failing test. 4. Implement the change. 5. Make the test pass. 6. Request independent review. 7. Run fresh verification. 8. Record the evidence. 9. Advance to the next goal. This provides an important property for Agentic Sprints: **a deterministic stopping condition**. The agent is not deciding that the implementation “looks finished”. The system has evidence that the defined objective has been achieved. ## 5. Make failures resumable Agentic systems will fail, and they will fail in predictable ways: - models will hit context boundaries - API limits will occur - test environments will fail - dependencies will become unavailable - agents will make incorrect assumptions. The wrong architecture is to expect uninterrupted execution. Autonomous Loop treats interruption as normal. If an iteration fails, the system records: - what failed - what was attempted - the current repository state - the next hypothesis - what remains incomplete. A subsequent agent can reload the project spine and continue. This creates **resumable engineering execution**. The distinction is subtle but important: a coding agent performs a task, while an agentic delivery system maintains progress towards an objective. ## 6. Coordinate isolated parallel work Some Build Plans naturally decompose into independent work. For example: - **Goal A: Payment API** - **Goal B: Customer Portal UI** - **Goal C: Notification Service**. These goals can potentially execute simultaneously. Autonomous Loop supports isolated work through Git worktrees, so independent Maker agents can operate without corrupting one another's working state. The Agentic Sprint orchestrator can therefore create execution branches dynamically. The important principle is not simply parallelism. It is **controlled parallelism with explicit dependency management**. ## 7. Keep roles and permissions separate Autonomous Loop can operate through a persistent multi-agent topology. Instead of repeatedly creating generic agents, the delivery environment can contain specialised roles: - an Agentic Sprint Coordinator - a Maker - a Code Reviewer - a Test Verifier - a Security Auditor - a Red Team, where required. Each role can have different: - instructions - permissions - tools - model configurations - context. This allows separation of duties to become a technical control. For example, the Maker may have permission to modify a feature branch but no ability to merge. The Coordinator may create work and manage state. The Reviewer may inspect code but not modify the implementation. Production capability remains outside the autonomous execution plane. ## 8. The complete Agentic Sprint architecture With Autonomous Loop incorporated, the complete architecture can be understood as a sequence of controlled stages. ### Intake and context 1. A Jira or GitHub Issue is assigned to an AI Agent. 2. An orchestration layer, such as n8n, a scheduler or a workflow engine, detects the work. 3. A context assembly step collects the requirements, architecture, repository instructions, engineering standards and domain context. 4. A Build Plan Agent prepares the scope, architecture, dependencies, sequence diagrams, data flows, repository impact, test strategy and risk analysis. ### Human Gate One: Build Plan and design approval The plan must be approved before autonomous execution begins. ### Autonomous execution and machine review 5. Autonomous Loop builds the persistent execution spine, decomposes the approved plan into goals, orders dependencies and creates verification conditions. 6. Multi-agent implementation begins through Maker agents, using isolated worktrees where needed. 7. Machine verification runs unit, integration and contract tests, static analysis, security checks and architecture checks. 8. Independent agent review examines the work through Code Reviewer, Security Auditor, Red Team and Requirements Verifier roles. 9. If the work fails, the system records the failure, updates the hypothesis, sends the work back for a Maker retry and verifies it again. ### Human Gate Two: Engineering implementation review Work that passes machine verification reaches a human engineer for implementation review. ### Product assurance and release 10. QA and product assurance validate functional behaviour, exploratory scenarios, regression impact, business rules and end-to-end behaviour. 11. Human Gate Three retains release and merge authority. 12. Only then does the change reach the protected main branch and release process. The production boundary remains outside the autonomous execution path. ## 9. Keep learning under human control Another loop runs across every Agentic Sprint. It is deliberately outside the autonomous implementation loop. The learning sequence is: 1. An agent produces an output. 2. A human reviews it. 3. The human records a correction. 4. The team decides whether the correction is a reusable engineering lesson. 5. If it is reusable, the team updates the relevant agent context, skill or rule. 6. The context change is versioned and reviewed. 7. Future Agentic Sprints can use the improved context. This is where Autonomous Loop's guarded self-revision becomes useful. The execution system can learn practical heuristics about a repository, but **guardrails and security invariants remain human-controlled**. Agents can learn: > This test suite becomes unstable when executed concurrently. They cannot autonomously decide: > Security review is slowing us down, so remove it. That distinction is fundamental. :::figure learning-loop The governed learning loop connecting agent output, human review, reusable corrections, versioned context changes and future Agentic Sprints. Guardrails and security invariants remain under human control. ::: ## 10. Keep the inner and outer loops distinct The architecture contains two related but deliberately separate loops. ### Inner loop: Autonomous Loop The inner loop is high-frequency machine execution: 1. Select a goal. 2. Define or load its test. 3. Build the change. 4. Review it independently. 5. Verify it. 6. Repeat or advance. This may happen tens or hundreds of times during one body of work. ### Outer loop: Agentic Sprint The outer loop is human-governed software delivery: 1. A requirement is raised. 2. A Build Plan is prepared. 3. A human approves the plan. 4. Autonomous execution takes place. 5. A human reviews the implementation. 6. QA validates the product. 7. Release authority approves the change. 8. Organisational learning updates future context where appropriate. The inner loop optimises implementation. The outer loop protects intent and accountability. That separation is one of the defining architectural principles of the Agentic Sprint. ## 11. Define the two systems clearly The distinction can be stated precisely. ### Agentic Sprint **A human-governed software delivery operating model in which approved product requirements are transformed into machine-executable plans, implemented through autonomous multi-agent loops, independently verified and progressed through explicit human decision gates before release.** ### Autonomous Loop **The execution protocol responsible for decomposing approved engineering plans into verifiable goals and repeatedly implementing, checking, recovering and progressing those goals without requiring continuous human intervention.** They solve different problems. The Agentic Sprint asks: > How should an engineering organisation deliver software using autonomous agents? Autonomous Loop asks: > How do those agents reliably execute the engineering work once authorised? Together, they form a complete operating model. ## Agentic Sprint and Autonomous Loop The complete philosophy can be reduced to six principles: 1. Humans specify intent. 2. Agents propose the implementation. 3. Humans approve the plan. 4. Autonomous Loop executes and independently verifies the work. 5. Humans accept the engineering outcome. 6. Every meaningful correction improves the next execution. In short: **Humans control the gates. Agents run the loops.** That is the Agentic Sprint. ## Sources and attribution - [Source code on GitHub](https://github.com/asiridalugoda/autonomous-loop)