Framework
The AI Engineering
Capacity Map
One capacity for each step of AI engineering delivery, and where the work waits.
AI raises how much change an engineering organisation can produce. Whether that change becomes value depends on everything around the code: how many bets the organisation can steer, how clearly it specifies intent, how much it can prove, release, run and learn from. The capacity map names each of those limits. It gives every step of the AI Engineering Production System Forthcoming one capacity: how much work that step can absorb at its quality bar.
Build capacity is the supply side. Every other capacity decides how much of that supply becomes validated business value. The distance between the two is the Absorption Gap, and the capacity map shows where it opens.
A note on terms: “AI engineering” here means the engineering function as agents join its workforce, rather than the discipline of building products on foundation models.
The map
- DirectionFocus capacity
- IntentIntent capacity
- SupplyBuildBuild capacity
- VerifyVerification capacity
- ReleaseIntegration capacity
- ProductionOperating capacityrecovery capacity at its core
- Observe & ImproveOutcome capacity
In the six stage view of the model, Verify & Release is one stage. Read in detail, it splits into two steps with one capacity each, verification and integration, which is why the map shows seven.
The capacities
Step: Direction
Focus capacity
How many bets an organisation can fund and steer with a declared value.
Usually lowered by: organisational coupling, where teams are cut across the value flow and decision rights are shared, so most initiatives need several teams to move.
A sign it is binding: decisions queue at Direction, and many initiatives are in flight with few declared values.
Read more: Not Yet: When AI in Coding Is the Wrong Investment Forthcoming
Step: Intent
Intent capacity
The volume of change an organisation can specify to a testable standard.
Usually lowered by: functional coupling, where business rules and domains are entangled, and by requirements written as prose that nothing can test.
A sign it is binding: work starts without testable acceptance criteria or a declared outcome, and rework traces back to ambiguity. Agents act on whatever the requirement says, so an ambiguous requirement becomes a wrong implementation at agent speed.
Read more: Not Yet Forthcoming; Designing the Verification System Forthcoming
Step: Build
Build capacity
How much change people and agents can produce.
Build capacity is the only capacity that can be raised with a purchase order: a licence and a token budget. It is not infinite, since AI cost and energy use grow with it, but it is far cheaper to raise than any other capacity on the map, which is why it tends to run ahead.
Usually lowered by: structural and functional coupling, where shared code makes parallel changes collide and work depends on another team.
A sign it is binding: work waits for someone to produce the change. When build holds the largest queue and teams release independently, agents are likely the right investment.
Read more: Not Yet Forthcoming
Step: Verify
Verification capacity
The volume of change an organisation can prove, at each level of risk, in a given period, without lowering the bar.
Usually lowered by: test and data coupling, where test suites and test data need the whole system to run.
A sign it is binding: review queues lengthen, or changes merge with less review as the bar quietly drops.
Read more: Designing the Verification System Forthcoming
Step: Release
Integration capacity
The volume of verified change an organisation can merge, integrate and release in a given period while the main branch stays healthy.
Usually lowered by: temporal and technical coupling, where releases are coordinated across teams and services depend on each other synchronously.
A sign it is binding: feature branch throughput rises while main branch throughput stays flat or falls.
Read more: The Agent Ready Delivery Pipeline Forthcoming
Step: Production
Operating capacity and recovery capacity
Operating capacity is an organisation's ability to run what it ships, from observability and service objectives to on call, incident management and learning. Its core is recovery capacity: the volume of change production can absorb while still detecting, attributing and recovering from failures within its service objectives.
Usually lowered by: runtime coupling, where shared infrastructure and cascading failure paths widen the blast radius of each incident.
A sign it is binding: incidents and hotfixes cluster after releases, and the time to attribute a failure to its change grows.
Read more: Designing Operating Capacity Forthcoming
Step: Observe & Improve
Outcome capacity
How many outcomes get read after release and fed back to Direction.
Usually lowered by: semantic coupling, where outcome measures depend on shared definitions that nobody owns.
A sign it is binding: released work rarely has its outcome read, so Direction steers on output.
Read more: Not Yet Forthcoming
Underneath every step
Step: Every step, on the input side
Context capacity
The rate of change an organisation can keep accurately described, owned and current for the agents acting on its systems.
Usually lowered by: context with no named owner, and context refreshed by clean up campaigns instead of by the delivery pipeline.
A sign it is binding: the lag between a change shipping and its context being updated grows as change volume grows.
Read more: Building a Governed Context Supply Forthcoming; The Second Absorption Gap
Step: Every step; the core of governance
Control capacity
How much agent action an organisation can authorise, constrain, trace and reverse within its risk appetite, without slowing the change that is safe.
Usually lowered by: agents acting on borrowed identities and standing privileges, and approvals that run at meeting cadence.
A sign it is binding: agent credentials outlive their tasks, or actions that need a person wait in an approval queue. Control capacity sets how far autonomy can safely extend at every other step.
Read more: Governance as Architecture Forthcoming
How the capacities
work together.
Supply against absorption. Build adds supply. Each of the other capacities absorbs it at one step. The step whose capacity falls furthest short of the supply reaching it is the constraint, and that is where work waits.
The constraint moves. Raise the capacity that binds, and the next one starts to bind. This is Constraint Migration. The practical rule is to invest one stop ahead of the constraint, where the next queue will form, and nowhere else yet.
Architecture shows up as coupling. Architecture is not a separate step on the map. Each kind of coupling lowers a specific capacity, which is why the same agents can pay strongly in one team and add little but review load in another.
Everything rolls up to one ratio. A shortfall at any step shows as work that waits, work that escapes or comes back, or human effort spent compensating. All three move validated business value per unit of human intervention, the ratio the system is optimised for. Each step can therefore be read through the same three questions: how long work waits there, how much escapes or comes back, and how many human minutes each change consumes.
Using
the map.
Start where work actually waits, rather than where AI is easiest to add. Name the capacity at that step and fund it, then prepare the next one. Build capacity is usually the last capacity to raise, unless build is where the work waits, in which case agents are likely the right first move.
Frequently asked questions
What is the AI Engineering Capacity Map?
A map of nine capacities, one for each step of AI engineering delivery plus two that sit underneath every step. Build capacity adds supply; the others decide how much of it becomes validated business value. The step that falls furthest short of its supply is the constraint.
How is it different from capacity planning?
Capacity planning usually sizes teams against the demand for work. The capacity map looks at the whole delivery system and asks how much of what is produced each step can absorb, and where the system as a whole is limited.
Is this the Theory of Constraints?
Largely, yes, applied to a supply shock. Improving a step that is not the constraint does not improve the system. What AI changes is the speed and cost at which one capacity, build, can be raised. The map adds the steps, the coupling behind each queue and a metric that counts validated value rather than output.
Which capacity should we raise first?
The one where work waits longest. In many organisations that is not build, which is why adding agents can leave delivery where it was.
Read
further.
- The Absorption Gap
- AI Won't Replace Your Engineering Bottleneck. It Will Move It.
- What Is Your AI Engineering System Optimising For?
- The AI Engineering Production System Forthcoming
- Not Yet: When AI in Coding Is the Wrong Investment Forthcoming