Part of our guide: AI implementation and operating model
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, and most of the industry has not noticed yet.
Most attention is on giving developers better tools such as Cursor, Claude Code and Copilot, all of them useful and all of them leaving the operating model untouched. The developer is still the unit of delivery and the team structure, the governance and the ceremonies all stay the same, and 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 and you do not need the same roles. You do not need sprints, standups or story points in the form you know them, or manual code review at human pace. All of these exist because people write code, and they encode human constraints: working memory, context-switching cost, forgetting and miscommunication.
Agents do not share those constraints and they work continuously, and they do not lose alignment as long as they are reading from a shared, well-structured backlog. They do not need a daily ceremony to remember what they are doing.
They do introduce different constraints of their own: they hallucinate, they struggle with ambiguity and they accumulate technical debt at unprecedented rates. They cannot validate output against business intent without human guidance, and they produce code that looks functional and can still be structurally incoherent or misaligned with existing system behaviour.
The question shifts away from whether we can build it fast enough and becomes whether we can 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, adding up to a structurally different model (not "Agile but faster").
Why Agile is the wrong starting point
Agile transformed software delivery, replacing heavyweight, document-driven processes with collaboration, iteration and responsiveness to change, and that success was well earned.
Agile was designed for a world where people do the work, and its ceremonies, roles and artefacts all assume that people write the code. People test the code and people coordinate the effort, and two-week sprints reflect the limits of collective human working memory. Daily standups compensate for the fact that people forget and lose alignment, and story points exist because human throughput is the bottleneck worth measuring.
Autonomous agents break those assumptions, and 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. That second outcome is unacceptable in any environment that values quality, coherence or regulatory compliance.
Neither is the right answer, and 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, free to use and free to adapt. It is not a finished answer and it is a framework for a conversation that the industry needs to have.
The ADM preserves what Agile got right, holding on to 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 and the people around them define intent, maintain coherence, verify output and govern the process.
The model is sector-agnostic and it works for greenfield and brownfield environments, scaling 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. Eight principles carry the model, beginning with intent over instruction, continuous execution with governed checkpoints and the recognition that verification and validation serve different purposes. The rest cover architectural coherence as a first-class concern, measured technical debt, precision of intent that determines quality of output, human accountability that stays non-negotiable and 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 and the Design Steward owns experience consistency. The Product Owner role evolves and the Agent becomes a governed team member (not just a developer tool), with many traditional roles changing, splitting or disappearing.
Team structure. Delivery is organised around governed agent pools rather than feature squads, so team size and composition shift and the ratio of people to work-in-flight changes dramatically.
Governance cadence. Governance runs in three tiers, with a daily governance review of agent output and a weekly strategic review of architectural drift and debt, and execution continues in real time, not in sprint boundaries.
Artefacts. The model runs on Intent Briefs, Intent Specifications with a Definition of Ready designed for agents and an extended Definition of Done. It also relies on a Coherence Register that tracks architectural drift and on a testing strategy that distinguishes verification from validation.
Metrics. Measurement covers lead time, debt velocity, coherence scores, intent precision and verification coverage, not story points and not velocity in the Agile sense. These are the metrics that reflect what actually determines outcomes in an agent-led delivery system.
Regulated environments. The model covers provenance and audit trail, separation of execution and approval and regulatory overlay templates, with accountability frameworks aligned to SM&CR, SS2/23 and equivalent regimes.
Workforce transition. The model sets out how organisations move from current structures to agent-led delivery, covering the roles that evolve and the roles that disappear. It also covers how to build the new capabilities and 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 are designing the operating model their function will run on as agent capability matures, and the decisions made in the next eighteen months will set the pattern for the next decade.
COOs and transformation leaders are working through the operating model implications of AI across their business, where software delivery is one domain and the patterns generalise.
Heads of engineering and delivery are already experimenting with agents and finding that their existing ceremonies, roles and governance do not fit, and the ADM gives you a model to compare against.
Services firms and consultancies have a commercial model that depends on a view of how software gets built, and the economics of day-rate delivery change when the delivery workforce is agent-based, so the ADM addresses this directly.
Regulators, auditors and risk functions are forming a view on what governed AI-led delivery should look like, and 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, and 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 and 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, and 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, and 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, and 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 and we would encourage you to join it.