--- title: "The Agentic Sprint" description: "A human-gated operating model for autonomous software delivery." date: "2026-08-28" updated: "2026-08-28" type: concept topics: - "Agentic Systems" - "Delivery & Organisations" canonical: "https://dalugoda.com/agentic-sprint" series: "Working concepts" sources: - "https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews" - "https://openai.com/index/running-codex-safely/" - "https://arxiv.org/abs/2509.16941" --- ## Why the operating model has to change Software engineering is moving through a more fundamental transition than simply giving developers better autocomplete. The first generation of AI-assisted development made individual engineers faster. Developers could generate functions, write tests, explain code, refactor modules and produce documentation without leaving their IDE. The next generation is different. AI agents can now: - inspect repositories - reason across multiple files - execute commands - build implementation plans - modify applications - run tests - create pull requests - respond to review comments - work asynchronously on engineering tasks. The interesting question is no longer only: **How can AI help a developer write code faster?** It is also: **What happens when writing the code is no longer the software engineer's primary job?** I call the resulting operating model an **Agentic Sprint**. An Agentic Sprint is a software delivery cycle in which a coordinated system of specialised AI agents performs much of the planning, implementation, testing, documentation and remediation work. A small number of human engineers retain authority over intent, architecture, quality and production acceptance. The agents execute. Humans govern. The delivery system learns from each meaningful human correction. ### In brief - An Agentic Sprint delegates much of the execution work to specialised agents. - Humans retain authority over product intent, architecture, quality acceptance, risk and release. - A Build Plan is approved before implementation begins. - Independent review and deterministic engineering controls challenge agent output before human acceptance. - Human corrections can become versioned engineering context, so the system improves without changing the underlying model. - The model increases execution capacity, but it also makes review capacity, decision quality and governance more important. ## 1. From assistance to delegated execution Traditional software delivery is organised around human execution capacity. A typical flow moves through seven stages: - requirement - refinement - design - development - code review - QA - release. Each stage consumes human engineering time. Even when AI coding tools are available, the organisational model usually remains the same. A developer receives a Jira ticket, opens an IDE, asks an AI assistant for help and eventually submits a pull request. The developer remains the execution engine. The Agentic Sprint changes that assumption. Instead of assigning work directly to an engineer, an organisation assigns it to an **agentic delivery system**. That system might contain: - an orchestration layer such as n8n - one or more coding agents - planning agents - architecture agents - testing agents - security agents - review agents - repository-specific skills - organisational engineering standards - architecture documentation - product context - test frameworks - CI/CD infrastructure - isolated development environments - GitHub or equivalent source-control integration - Jira or another work-management platform. The exact technology is secondary. The important change is the operating model: the agentic system becomes part of the delivery workforce rather than a tool sitting beside the engineer. ## 2. The governing principle: automate execution, preserve authority An Agentic Sprint operates around one principle: > **Automate execution. Preserve human authority.** Current coding agents can perform repository-level work. GitHub, for example, allows issues to be assigned to coding agents that work asynchronously and produce pull requests. GitHub's own guidance still calls for thorough human review of agent-generated changes, and its controls prevent its coding agent from approving or merging its own pull requests. That is the boundary this model preserves. The goal is not autonomous production. It is **autonomous execution inside a governed delivery system**. The model separates engineering responsibility into two groups. ### Machine responsibility Agents perform high-volume execution, including: - repository analysis - solution exploration - implementation planning - code generation - cross-repository changes - unit and integration tests - documentation - static-analysis remediation - test-failure remediation - pull-request preparation - implementation evidence - repetitive review cycles. ### Human responsibility Humans retain high-value judgement, including: - product intent - requirement approval - architecture - engineering trade-offs - risk acceptance - implementation-plan approval - code-review approval - quality acceptance - production authority. This changes the engineer's role. The engineer moves from being the primary producer of code to being a governor of software production. :::figure responsibilities The conceptual responsibility split between machine execution and human judgement in an Agentic Sprint. The figure should show the two responsibilities side by side, with human authority remaining at the decision boundaries. ::: ## 3. Prepare the environment and start the work An organisation cannot simply point an LLM at its source code and declare itself agentic. Before the first Agentic Sprint, the environment needs to become **machine-understandable**. ### Agentic readiness Knowledge that historically existed in developers' heads needs to become persistent context. This may include: - `AGENTS.md` - architectural principles - repository maps - coding conventions - domain terminology - API contracts - data models - integration boundaries - security requirements - testing requirements - design patterns - prohibited patterns - the Definition of Ready - the Definition of Done - branching conventions - migration rules - observability standards - error-handling conventions - performance requirements - deployment constraints - repository-specific agent skills. Modern agent tooling is moving in this direction. GitHub supports repository custom instructions and agent skills that provide coding and review agents with organisational context. Documentation therefore stops being merely something humans read. It becomes part of the execution environment. Architecture documentation becomes executable organisational knowledge. ### Triggering a sprint The sprint begins with a normal unit of product work. For example, a Jira ticket might contain the following user story: > As a customer, I want to cancel a scheduled payment before processing begins. Its acceptance criteria might be: - Only future, unprocessed payments may be cancelled. - The cancellation must be recorded in the audit log. - The customer must receive confirmation. - The payment must not subsequently enter the processing workflow. - Cancellation must be idempotent. - Appropriate permissions must be enforced. When the ticket reaches an agreed status, or is assigned to an identity such as **AI Agent**, the orchestration platform detects the event. This could happen through a Jira webhook connected to n8n, or through a GitHub Issue event connected to an orchestration platform. The orchestration system then creates an **Agentic Sprint execution**, and the agents begin working. The architecture can support either a monorepo or a multi-repository environment. :::figure agentic-sprint-architecture The conceptual Agentic Sprint architecture: a work item enters orchestration and context assembly, passes through a human-approved Build Plan, moves through autonomous implementation and independent verification, and reaches QA and release authority only through explicit human gates. The learning loop runs alongside the delivery path. ::: ## 4. Plan before implementation The first agent does **not write code**. It produces an implementation plan. The planning agent examines: - the acceptance criteria - architecture documentation - affected repositories - existing implementations - relevant data models - APIs - business rules - test infrastructure - security requirements - dependencies - existing patterns - likely regression areas. It then creates a formal **Build Plan**. A good plan is closer to a lightweight engineering design document than to a coding prompt. It can include: 1. **Requirement interpretation:** exactly what the agent believes the requirement means. 2. **Scope:** what will change and what will explicitly remain unchanged. 3. **Repository impact:** for example, `customer-portal`, `payment-api`, `workflow-service` and `notification-service`. 4. **Component impact:** the individual services, modules or components that require modification. 5. **Proposed implementation:** the intended technical solution. 6. **Sequence diagrams:** how the interaction occurs across services. 7. **Data-flow diagrams:** where information enters, moves and persists. 8. **State transitions:** particularly for workflow-heavy applications. 9. **Database changes:** tables, fields, migrations and backward compatibility. 10. **API changes:** endpoints, request contracts, response contracts and version implications. 11. **Security implications:** authentication, authorisation, secrets, PII and trust boundaries. 12. **Test strategy:** unit, integration, contract, UI and regression testing. 13. **Failure scenarios:** what happens when dependencies fail. 14. **Rollback strategy:** how the change can safely be reversed. 15. **Acceptance-criteria traceability:** how each criterion maps to an implementation component and a test. ### Human Gate One: plan approval The Agentic Sprint stops at this point. Nothing is implemented until a human engineer approves the Build Plan. The engineer reviews questions such as: - Did the agent understand the requirement? - Is the architecture sensible? - Has it found the correct services? - Is it modifying something it should not? - Has it introduced unnecessary complexity? - Are the security boundaries correct? - Are the test boundaries sufficient? The engineer can approve the plan or reject it with feedback. If it is rejected, another agent iteration updates the plan. Only an approved Build Plan unlocks implementation. This changes the economics of engineering work. Instead of spending hours discovering a solution and then coding it, the engineer spends concentrated time reviewing a structured technical proposal. ## 5. Implement, challenge and verify ### Autonomous implementation Once the plan is approved, the orchestration system begins implementation. This does not have to mean one enormous agent. It may be a collection of specialised agents: - a **Backend Agent** for API and domain changes - a **Frontend Agent** for UI behaviour - a **Database Agent** for schema and migration changes - an **Integration Agent** for service integrations - a **Test Agent** for automated tests - a **Documentation Agent** for relevant documentation. The orchestration platform coordinates dependencies between them. In a multi-repository environment, individual agents may work in separate isolated workspaces and produce coordinated branches. For example, `agent/TM-248-payment-cancellation` could exist across several repositories. Agents may: - inspect code - modify branches - compile applications - execute approved tooling - run unit tests - run integration tests - analyse failures - iterate on implementations. They should not automatically have authority to: - merge to protected branches - deploy production workloads - access unrestricted production data - alter infrastructure outside approved boundaries; or - modify organisational security controls. Sandboxing and approval boundaries are essential. OpenAI describes a similar security philosophy for coding agents: productive operation should happen within technically bounded environments, while higher-risk actions cross explicit approval boundaries. ### Machine review before human review Sending raw agent output directly to a senior engineer wastes human attention. The implementation should first survive a **machine review swarm** in which different agents independently evaluate the work. The review roles can include: - **Code Review Agent:** readability, architectural consistency, complexity, duplication, maintainability and coding standards. - **Security Agent:** authentication, authorisation, injection risks, dependency risk, secrets, insecure data handling, privilege escalation and logging exposure. - **Test Agent:** edge cases, negative cases, boundary conditions and integration scenarios designed to break the implementation. - **Requirements Agent:** direct comparison between the implementation and the acceptance criteria. - **Architecture Agent:** comparison between the implementation and the approved Build Plan. The important idea is **independent verification**. The agent that creates something should not be the sole agent deciding whether it is correct. ### Deterministic quality controls Before a human engineer sees the implementation, it should pass deterministic engineering controls such as: - compilation - linting - unit tests - integration tests - contract tests - static analysis - dependency scanning - secret scanning - code-coverage thresholds - architecture tests - security scanning - migration validation - performance thresholds where applicable. Agents may attempt to repair failures, but they cannot remove the quality gate simply because they cannot satisfy it. The system must optimise for **passing the engineering standard**, not for making the pipeline green by any available method. ### Human Gate Two: implementation review Only after machine verification succeeds does the implementation reach the engineer. The engineer receives a structured review package containing: - the original requirement - the approved Build Plan - changed repositories - an architectural summary - the pull-request diff - tests created - test results - security findings - machine-review findings - deviations from the original plan - unresolved risks. The human engineer reviews the implementation as they would review an experienced engineer's pull request. Current industry practice supports maintaining this boundary. GitHub explicitly states that coding-agent pull requests deserve the same thorough review as human contributions and that AI review is not a substitute for human review. There is also a capability gap. SWE-Bench Pro was created to better represent difficult, long-horizon professional engineering work. Its published evaluation found leading models below 25% Pass@1 under its evaluation setup. Impressive coding capability does not yet imply reliable autonomous software engineering across complex tasks. The engineer remains accountable for the decision that **this implementation is technically acceptable**. That decision belongs to the human engineer, not the model, orchestrator or test agent. ### QA as independent product assurance An Agentic Sprint does not eliminate QA. It makes independent QA more strategically important because agents can generate large amounts of technically plausible code quickly. QA should work from product intent and acceptance criteria rather than simply trusting the implementation. It validates: - functional behaviour - cross-feature interactions - business rules - exploratory scenarios - regression impact - customer journeys - accessibility - browser and device behaviour - integration behaviour - operational edge cases - data integrity. AI can increase QA capacity too. Agents can: - generate candidate test cases - maintain automation - identify regression areas - synthesise test data - analyse failures - compare expected and actual results. Final product assurance remains independent from the implementation agent. The system that creates the software should not be the only system determining whether the software works. ## 6. Use corrections to improve the system This is where an Agentic Sprint differs materially from ordinary AI-assisted development. Imagine that an agent creates a repository query directly inside a controller. An engineer reviews it and says: > We never perform persistence operations directly from controllers. This must go through the application-service layer. The easy response is to fix the code. That is insufficient. The correction represents **new organisational knowledge**. The review process should therefore trigger two actions: 1. Correct the current implementation. 2. Decide whether the correction should become persistent agent context. If it should, an Agent Learning step updates the relevant: - skill - architecture instruction - repository rule - example - validation test; or - review rule. For example, `architecture/service-boundaries.md` might gain the following rule: > **Controllers must not access repositories directly. Persistence operations must be mediated through application services.** The next task begins with better context, making the same mistake less likely. This creates a compounding loop: 1. Agent output is reviewed. 2. A human identifies a correction. 3. The correction is assessed as a reusable lesson or a local fix. 4. Reusable lessons are added to agent context. 5. Future output improves and repeat corrections should decline. Over dozens or hundreds of Agentic Sprints, the engineering system becomes increasingly calibrated to the organisation. The team's engineering judgement is gradually encoded into the delivery platform. This is effectively **continuous organisational fine-tuning without model training**. :::figure learning-loop The learning loop that connects agent output, human correction, versioned context changes and future Agentic Sprints. The figure should make clear that reusable lessons are governed and reviewed before they influence later work. ::: ### Agent context is production infrastructure Once agents produce meaningful quantities of production code, instruction files can no longer be treated as casual prompts. They become production assets. Changes to the following can alter future software delivery: - agent skills - engineering instructions - architecture context - security rules - review criteria. They should therefore be: - version-controlled - code-reviewed - tested - owned - auditable - releasable - reversible. A bad agent instruction could theoretically create defective patterns across dozens of implementations. The Agentic Sprint introduces another engineering discipline: **Agent Context Engineering**, whose job is to maintain the knowledge environment in which agents operate. ## 7. Reorganise around judgement and evidence ### The agentic engineering team A mature Agentic Sprint team might look different from a traditional delivery squad. Traditional staffing may include: - an Engineering Manager - a Tech Lead - six to ten Software Engineers - QA Engineers - a Product Manager - a Designer. An agentic delivery unit might eventually include: - a Product Manager - one or two Senior or Staff Engineers - QA or Quality Engineering - an agentic orchestration platform - specialised implementation agents - testing agents - security agents - review agents. The number is intentionally not fixed. A complex financial platform will require different human oversight from a simple internal application. The economic principle does change. Traditional organisations scale delivery largely by increasing the number of people performing implementation. Agentic organisations attempt to scale **machine execution capacity while keeping human judgement comparatively scarce**. That is the leverage point. ### What happens to the software engineer? The software engineer does not disappear. The role moves upward in abstraction. The most valuable engineering skills become increasingly concentrated around: - architecture - systems thinking - debugging - specification - decomposition - security - observability - performance - reviewing unfamiliar code - understanding business intent - identifying hidden failure modes - creating engineering guardrails - teaching agents organisational patterns. The engineer who only converts well-defined Jira tickets into code is increasingly exposed to automation. The engineer who can determine **what should be built, how it should behave, what can go wrong and whether an implementation is safe** becomes more valuable. The Agentic Sprint does not remove engineering. It separates **engineering judgement** from **engineering labour**. ### Metrics for an Agentic Sprint Velocity alone is a poor measurement. An Agentic Sprint should measure throughput and the amount of human intervention required. Useful metrics include: - **Agentic throughput:** completed work per sprint. - **Plan acceptance rate:** the percentage of Build Plans approved without revision. - **First-pass implementation acceptance:** the percentage of implementations approved without material human correction. - **Human intervention minutes:** engineer review time per completed work item. This could become one of the most important metrics. - **Agent rework rate:** how often implementations return to an agent. - **Escaped defect rate:** production defects originating from agent-created changes. - **Context correction rate:** how frequently human reviews identify reusable organisational knowledge. - **Repeat error rate:** whether agents continue producing previously corrected mistakes. - **Autonomous test recovery rate:** the percentage of test failures agents successfully diagnose and resolve. - **Cost per accepted change:** the combined model, infrastructure and human cost required to create production-accepted software. Over time, a healthy Agentic Sprint system should aim for: - lower human intervention - fewer repeat mistakes - higher first-pass acceptance - higher delivery throughput - stable or improving quality. These are target directions, not reported results. :::figure metrics A conceptual metric framework for an Agentic Sprint. The figure should present each metric with its intended direction and a reminder that throughput must remain coupled to quality and human control; it must not imply measured results. ::: ### The Agentic Sprint maturity model Organisations will not jump directly to full agentic delivery. A useful maturity model is: 1. **Level 0, human development.** Humans design and implement software. 2. **Level 1, AI-assisted development.** Developers use AI coding assistance. 3. **Level 2, agent delegation.** Individual tickets are delegated to coding agents. 4. **Level 3, human-gated Agentic Sprint.** Planning and implementation are orchestrated, with mandatory human gates. 5. **Level 4, multi-agent delivery.** Specialised agents coordinate planning, implementation, testing, review and documentation. 6. **Level 5, learning agentic delivery.** Human corrections continuously update shared agent context and engineering skills. 7. **Level 6, high-autonomy engineering.** Most routine implementation runs autonomously through governed pipelines, while humans primarily manage exceptions, architecture and risk. The objective should not necessarily be Level 6. Different systems may intentionally stop at different levels because of their risk profile. :::figure maturity The Agentic Sprint maturity model from human development through high-autonomy engineering. The figure should show increasing execution autonomy alongside the continuing need for human governance, rather than presenting the levels as a promise or performance scale. ::: ## 8. Control the risks and move the bottleneck ### Guardrails are not optional The biggest mistake an organisation could make would be to focus on autonomy before control. Agentic velocity without governance simply allows mistakes to happen faster. At minimum, the model should enforce: - **Protected branches:** agents cannot push directly to `main`. - **Mandatory human approval:** agent-authored production code requires a human approval path. - **Isolated execution:** agents operate in sandboxed environments. - **Least-privilege credentials:** an implementation agent receives only the permissions required for the task. - **Controlled network access:** external access is explicitly governed. - **Auditability:** agent actions, tools, commands and outputs are recorded. - **Independent testing:** implementation and verification responsibilities are separated. - **Deterministic CI gates:** agents cannot bypass required engineering standards. - **Production separation:** production deployment authority remains outside the coding agent. These concepts are increasingly reflected in real coding-agent platforms. GitHub restricts agent-created pull requests and maintains human merge controls, while OpenAI describes sandboxing, constrained execution, network policies and agent-native telemetry as core controls for operating coding agents safely. ### Failure modes Agentic Sprints will fail if organisations underestimate several problems: - **Poor requirements:** agents amplify ambiguity. Bad acceptance criteria produce bad software faster. - **Missing organisational context:** a technically correct implementation can still violate the organisation's architecture. - **Review overload:** if agents create code faster than humans can understand it, the bottleneck moves from implementation to review. - **Automation bias:** engineers may assume that passing tests means software is correct. It does not. - **Context poisoning:** bad instructions can propagate incorrect behaviour across future work. - **Test gaming:** an agent optimising only for passing CI may modify tests or implementation boundaries in ways that technically pass but violate intent. - **Architectural entropy:** independent agent changes can damage system coherence unless architecture is actively governed. - **Oversized work items:** long-horizon engineering remains significantly harder for current agents than small, bounded changes. Agentic work therefore benefits from a practice software engineering should already follow: use **small, clearly bounded and independently verifiable units of work**. ### What changes about Agile? The Agentic Sprint does not necessarily eliminate Agile. It changes what a sprint optimises. Traditional sprint planning asks: > **How much engineering capacity do we have?** Agentic sprint planning increasingly asks: > **How much validated work can our human governance layer safely absorb?** Coding capacity can potentially become elastic. Review capacity does not. The bottleneck moves from implementation throughput towards decision throughput. This is why senior engineering capability becomes so important. One strong engineer who can rapidly assess architecture, code quality and system behaviour may be able to govern a large amount of machine-generated implementation. ## 9. What an Agentic Sprint changes ### A practical example Imagine that ten Jira tickets become ready on a Monday. 1. Planning agents analyse all ten in parallel. 2. Six Build Plans are straightforward and approved rapidly. 3. Two are returned because the agents misunderstood a domain rule. 4. One reveals a previously unknown architecture dependency. 5. One is rejected because the requirement itself is incomplete. 6. The six approved plans move into implementation. 7. Implementation agents work in parallel across isolated branches. 8. Testing and review agents inspect the work continuously. 9. Four implementations pass automated verification. 10. Two return to implementation agents after security and integration-review findings. 11. An engineer reviews the four completed implementations. 12. Three are approved. 13. One exposes an architectural convention the agents did not know. 14. The engineer updates the relevant agent skill rather than fixing only the pull request. 15. The agent regenerates the affected portion. 16. QA validates the accepted features. 17. The remaining implementations continue through the pipeline the next morning. Notice what the engineer did not spend the day doing: - writing boilerplate - creating DTOs - wiring APIs - writing repetitive tests - fixing linting - updating documentation - waiting for CI; or - repeatedly switching between repositories. The engineer spent the time **making engineering decisions**. That is the Agentic Sprint. ### The real economic shift There is a tempting narrative that AI means replacing twenty engineers with one. That may occur in some environments, but it is not the most interesting implication. The more important change is that the relationship between **headcount and software throughput** may no longer be linear. Historically, producing more software has generally required more engineers. Agentic delivery creates the possibility of producing more software through more autonomous execution combined with sufficient human governance. That changes the economics of software organisations. It may allow: - smaller teams - faster experimentation - reduced coordination overhead - more senior engineering concentration - significantly greater output per engineer - smaller hand-off surfaces - continuous execution outside normal working hours - faster remediation and regression cycles. The scarce resource becomes less about typing code and more about **trusted engineering judgement**. ### Why I call it an Agentic Sprint A sprint has historically represented a timebox containing human engineering capacity. An **Agentic Sprint** represents something different: a controlled execution window in which: - requirements initiate autonomous work - agents plan before implementing - humans approve architecture before execution - specialised agents implement in parallel - independent agents challenge the implementation - automated controls verify deterministic requirements - human engineers accept technical quality - QA independently validates product behaviour - production remains protected - every human correction improves future agent behaviour. The complete loop is: 1. Specify the requirement. 2. Plan the implementation. 3. Approve the plan. 4. Build the change. 5. Challenge the implementation. 6. Verify it independently. 7. Review it as a human engineer. 8. Test the product behaviour. 9. Learn from meaningful corrections. 10. Repeat. That final step matters. The long-term advantage will not necessarily belong to the organisation with access to the best model. Everyone will eventually have capable models. The advantage may belong to the organisation that has built the best **engineering context around those models**: - architecture - patterns - rules - product knowledge - security constraints - lessons learned - a definition of quality. Once that institutional knowledge becomes machine-readable and continuously improved, the agentic engineering system begins to behave less like a generic coding assistant and more like an engineering organisation that understands how that company builds software. That is where the model becomes genuinely powerful. ### Conclusion AI coding agents are already here. The more interesting transformation comes when organisations stop adding those agents to an existing software-development process and instead redesign the process around them. The Agentic Sprint is one possible operating model for that future. It is not autonomous software development. It is **governed autonomous execution**. Machines provide scalable implementation capacity. Humans provide intent, judgement and accountability. QA provides independent assurance. Automation provides enforcement. Every review teaches the system how the organisation expects software to be built. The future software team may therefore not be defined by how many engineers can write code. It may be defined by how much autonomous engineering work a small number of highly capable humans can safely govern. That is the Agentic Sprint. ## Sources and attribution - [Source code on GitHub](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews) - [Reference](https://openai.com/index/running-codex-safely/) - [Reference](https://arxiv.org/abs/2509.16941)