The shift from people-executed to agent-executed software delivery is the most significant operating model change in enterprise technology since the move to cloud. Most of the industry has not noticed yet.
Most attention is on giving developers better tools. Cursor. Claude Code. Copilot. Useful, but they leave the operating model untouched. The developer is still the unit of delivery. The team structure stays the same. The governance stays the same. The ceremonies stay the same.
That is not where this ends.
When agents become the workforce, the model has to change
When autonomous agents become the delivery workforce, rather than assistants to developers, the operating model itself has to change. You do not need the same roles. You do not need sprints, standups or story points in the form you know them. You do not need manual code review at human pace. These exist because people write code. They encode human constraints: working memory, context-switching cost, forgetting, miscommunication.
Agents do not share those constraints. They work continuously. They do not lose alignment if they are reading from a shared, well-structured backlog. They do not need a daily ceremony to remember what they are doing.
But they introduce different constraints. They hallucinate. They struggle with ambiguity. They accumulate technical debt at unprecedented rates. They cannot validate output against business intent without human guidance. They produce code that looks functional but can be structurally incoherent or misaligned with existing system behaviour.
The question shifts. It is no longer "can we build it fast enough?" It becomes "can we specify what to build precisely enough, verify that what was built is right and keep the codebase coherent over time?"
That requires different roles, different governance and different economics. Not "Agile but faster." A structurally different model.
Why Agile is the wrong starting point
Agile transformed software delivery. It replaced heavyweight, document-driven processes with collaboration, iteration and responsiveness to change. That success was well earned.
But Agile was designed for a world where people do the work. Its ceremonies, roles and artefacts all assume that people write the code, people test it and people coordinate the effort. Two-week sprints reflect the limits of collective human working memory. Daily standups compensate for the fact that people forget and lose alignment. Story points exist because human throughput is the bottleneck worth measuring.
Autonomous agents break those assumptions. Bolting them onto an Agile operating model produces one of two failure modes. Either the governance and review structures throttle agent output back to human pace, erasing most of the value. Or agent output flows into production unchecked, which is unacceptable in any environment that values quality, coherence or regulatory compliance.
Neither is the right answer. What is needed is an operating model native to a world where agents execute the majority of implementation work and people focus on intent, verification and system integrity.
Introducing the Agentic Delivery Model
The Agentic Delivery Model (ADM) is an open methodology published by Oxygen Bubbles under Creative Commons. It is free to use and free to adapt. It is not a finished answer. It is a framework for a conversation that the industry needs to have.
The ADM preserves what Agile got right: iteration, collaboration and working software as the measure of progress. It restructures what no longer fits: ceremonies built around human coordination, roles defined by manual execution and estimation practices tied to human throughput.
It defines an operating model where a fleet of autonomous agents works collectively against a governed backlog, coordinated by architecture and governance rather than by individual developers. Agents are the delivery workforce. People define intent, maintain coherence, verify output and govern the process.
The model is sector-agnostic. It works for greenfield and brownfield environments. It scales from small teams to large technology functions. It is built to survive regulatory scrutiny in financial services, insurance, legal and other regulated sectors.
What the model covers
The ADM is structured around eight principles and a set of concrete mechanisms for running a delivery function where agents execute the work.
Principles. Intent over instruction. Continuous execution with governed checkpoints. Verification and validation serve different purposes. Architectural coherence as a first-class concern. Measured technical debt. Precision of intent determines quality of output. Human accountability is non-negotiable. Transparency of provenance.
Roles. The Intent Architect owns precision of specification. The Verification Engineer owns the test and validation estate. The System Steward owns architectural coherence. The Design Steward owns experience consistency. The Product Owner role evolves. The Agent becomes a governed team member, not just a developer tool. Many traditional roles change, split or disappear.
Team structure. Delivery is organised around governed agent pools rather than feature squads. Team size and composition shift. The ratio of people to work-in-flight changes dramatically.
Governance cadence. Three tiers. Daily governance review of agent output. Weekly strategic review of architectural drift and debt. Execution continues in real time, not in sprint boundaries.
Artefacts. Intent Briefs. Intent Specifications with a Definition of Ready designed for agents. An extended Definition of Done. A Coherence Register that tracks architectural drift. A testing strategy that distinguishes verification from validation.
Metrics. Lead time, debt velocity, coherence scores, intent precision, verification coverage. Not story points. Not velocity in the Agile sense. Metrics that reflect what actually determines outcomes in an agent-led delivery system.
Regulated environments. Provenance and audit trail. Separation of execution and approval. Accountability frameworks aligned to SM&CR, SS2/23 and equivalent regimes. Regulatory overlay templates.
Workforce transition. How organisations move from current structures to agent-led delivery. Which roles evolve. Which disappear. How to build the new capabilities. How to handle career paths for people whose roles change.
Who this is for
The ADM is for organisations thinking seriously about where their delivery function needs to be in two to three years.
CTOs and CIOs designing the operating model their function will run on as agent capability matures. The decisions made in the next eighteen months will set the pattern for the next decade.
COOs and transformation leaders working through the operating model implications of AI across their business. Software delivery is one domain. The patterns generalise.
Heads of engineering and delivery who are already experimenting with agents and finding that their existing ceremonies, roles and governance do not fit. The ADM gives you a model to compare against.
Services firms and consultancies whose commercial model depends on a view of how software gets built. The economics of day-rate delivery change when the delivery workforce is agent-based. The ADM addresses this directly.
Regulators, auditors and risk functions forming a view on what governed AI-led delivery should look like. The ADM is designed to meet regulatory expectations, not avoid them.
Why open
The model is published openly because this is not something one organisation should define alone. The shift is too large and the implications are too broad. Early convergence around a shared vocabulary and a shared operating pattern will help the industry move faster and more safely than if every organisation reinvents the model privately.
It is published under Creative Commons. You can read it, use it, adapt it, fork it and contribute to it. It will evolve as tooling matures and as organisations contribute experience. Version 1.0 is the start, not the destination.
Where to go next
If you want to understand the model, the fastest route is the methodology itself. It is published on GitHub.
Read the Agentic Delivery Model on GitHub
If you are thinking about where your delivery function needs to be in two to three years, or if you are already building this and want to compare notes, get in touch. We work with organisations on AI-powered operating model change, in software delivery and across the business. The ADM is one expression of that work. The broader question is how your operating model has to evolve as agents become part of the workforce.
This is the conversation the industry needs to have. Join it.