Build an agentic-first delivery org
A no-half-measures playbook for taking a delivery org from agents-assist to agents-ship: the technical rails, the cultural rewiring, and the 90-day sequence, each with a metric attached and a smaller version you can start with.
The seven moves
Rebuild delivery for agents. Fully, or not at all.
This is the how-to, not the pitch. Every move has a metric attached and a minimum viable version, so you know whether it's working before you build the fully-loaded one. What none of them have is a permanent “pilot” state. Start small. Finish anyway.
Agents run in isolated environments
The full version is a headless agent driving a hardware-isolated microVM per task. Boots in seconds, scales to zero, dies when the task dies.
Measure: Time from “agent finishes” to “you trust the diff enough to look away.”
Start here: A disposable container per task is enough to start. MicroVMs are the ceiling, not the entry fee.
Sandboxes talk to each other
The full version is a fleet, not an agent: planner, workers, and an independent review fleet, coordinating over a deliberately weak channel.
Measure: Cross-agent state collisions per week.
Start here: One agent at a time, or a single shared task list, until concurrency is actually your bottleneck.
Everything is gated by CI
No exceptions, no overrides, no “just this once.” CI is the only judge, and the full version runs the same modules the sandbox already ran.
Measure: Break-main rate, and the share of merges that skip a green run.
Start here: A CI check that blocks merge, full stop. Batching and an eval gate come after that's actually true.
Everything ships behind a flag
Every merge deploys. Nothing is exposed by default. Merge speed and release risk stop being the same decision.
Measure: Median time from merge to a safe rollback.
Start here: One flag library and a habit of using it on anything risky. A vendor-neutral flag API and automated canaries are later problems.
Someone has to build the platform
None of this is a tool you buy. At full maturity it's an internal product with a named owner, a team, and a roadmap.
Measure: Hours a week your best engineers spend babysitting agent output.
Start here: One named owner, part-time, before it's a headcount request.
Security, infra, and CI/CD are the skills now
The bottleneck moved out of application code. The people who unlock delivery are the ones building the rails, not the ones prompting well.
Measure: Of your last four hires, how many could debug a broken pipeline versus just write a better prompt.
Start here: Your next infra hire should already be thinking about this. You don't need a new team yet.
Rewire the culture, not just the pipeline
None of the technical rails hold if engineers route around them, reviewers rubber-stamp out of exhaustion, or leadership still treats "a person looked at it" as the real approval. The org has to change how it grants trust, not just how it ships code.
Measure: Share of engineers who say they'd trust an unattended merge on their own service, asked every quarter.
Start here: One public statement from leadership about what ships unattended and why. Culture change starts with a sentence someone's willing to be quoted on.
You don't need the whole stack
Every move below has a maxed-out version and a smaller version that gets you most of the win for a fraction of the build. Start with the metric. Not moving? Build the next piece. Nobody should be provisioning a microVM fleet before a plain CI gate actually blocks bad merges.
The mandate
No half measures. Say the quiet part out loud.
Every move below has a minimum viable version. That's about sequencing, not permission to stop halfway. A part-time flag library you never finish isn't a smaller win. It's a new kind of debt.
A pilot that never ends isn't caution. It's the fastest way to pay for the queue and the fleet, forever.
Partial autonomy buys you nothing
Agents that write code while a human still reads every line before merge keep the entire review bottleneck and add a second one: now someone has to review the agent, too. You paid for a fleet and kept the queue. Velocity only shows up once proof, not a person, is what clears the gate.
State the target out loud, this quarter
Pick the number: the share of merges you intend to ship on proof alone by quarter's end. Put it in the same deck as revenue and headcount. A target nobody said out loud is a target nobody's held to, and “we're exploring agentic development” is not a target.
Every phase has an exit criterion
“We stood up a sandbox” is not done. Done is: the metric attached to that move is moving, and you've already picked the next one. A roadmap that ends at “pilot” was never a roadmap.
Step 1 · diagnose
Where delivery actually seizes up today
Before any of the seven moves matter, look at where things already break. Most of this isn't new. Agents just turn existing cracks into full breaks, faster than anyone's used to reacting to.
AI-assisted is not agentic development
Autocomplete with better manners is still one engineer, one PR, one human review. Agentic development means agents open PRs unsupervised, at a volume no human review queue was ever built for. Different problem, different bottlenecks. Everything below is what breaks once you cross that line.
PR review is the first bottleneck
An agent can write code faster than any reviewer can read it. The queue backs up before infrastructure ever becomes the constraint, and adding reviewers doesn't fix something that's structural.
Merge queues are chaotic
A serial merge queue clears about two PRs an hour on a 30-minute CI cycle. One agent can blow past that in an afternoon. Nobody sized the queue for this.
Managing environments that mimic production
Every agent task needs somewhere real to run. Ten agents sharing one dev database is ten agents corrupting each other's fixtures, and most teams don't have a cheap way to hand out a fresh, realistic environment per task.
CI is flaky
If local and CI don't run the same checks, agents optimize against whatever signal they can see, and you find out the difference at merge time. At volume.
You've never done CD
Deploy and release have quietly been the same event the whole time. Without a way to ship dark and expose separately, every merge is also a release decision, made by whoever happens to be watching.
Security is an afterthought
Sandboxes with standing credentials. Agents that can reach production data. No egress control. None of this was designed with an unsupervised process in mind, and it shows up in the incident reports.
Flaky tests will kill your velocity
Agents retry on failure by default, correct behavior for one agent and a denial-of-service at fleet frequency. A test that flakes once in 200 runs fires daily instead of weekly once agents are running around the clock.
Architecture
Split the stack in two
Two planes, different physics. The agent plane is ephemeral, synthetic-data-only, priced on boot time. The production plane is durable, holds real data, and changes as little as the work allows. The only thing they share is the gate.
This is the ceiling, not the entry fee. Most of what's below earns its place once the simple version of the split stops being enough, not on day one. A staging box agents are free to break, with one flag between it and production, can be your first “two planes.” The dedicated pieces below are what you reach for once that stops holding.
Agent plane
ephemeral · synthetic data only · priced on boot time
Task intake
A triage agent reads the ticket and decides if it's actionable before anything boots. Roughly a third of tickets aren't, and finding that out is free.
Orchestrator
A headless coding agent, long-lived, with an addressable inbox, owning the task graph.
Per-task microVM
A dedicated kernel per sandbox, pause and resume in seconds.
Remote pipeline engine
The same pipeline modules locally and in CI, so the agent validates against reality before it ever opens a PR.
Database branch
A real copy-on-write database per task, created in about a second, thrown away with the sandbox.
Shared build cache
Content-addressed and warm (the difference between a fleet that costs pennies per task and one that doesn't).
Synthetic data only
The agent plane never sees a customer record, enforced at the network layer.
Egress broker
A two-phase network: dependencies with no secrets, then the agent with secrets and no general egress.
The gate
automated · no human queue · same modules the sandbox ran
Review fleet
Narrow reviewers in parallel voting on the diff, not one generalist. One AI lab moved substantive review coverage from 16% to 54% this way.
Merge queue
Batches PRs into one CI cycle and bisects on failure (N-way merge for one run).
Dynamic pipeline
Computed from the diff, same modules the sandbox already ran, no drift.
Eval gate
A held-out suite the agent has never seen, results that never travel back across the gate.
Requeue limiter
Caps how many times a PR can auto-retry on red, because unlimited retries at fleet frequency is a denial-of-service.
Provenance attestation
A signed record of model, task spec, tool set, and every gate result, attached to the merge.
Production plane
durable · real data · low-change
Vendor-neutral flag API
One flag interface behind a standard, so the agent writes flag code once.
Progressive delivery controller
Metric-gated canary promotion, automated analysis and abort.
Promotion state machine
The layer above it, verification between stages.
Flag lifecycle agent
Every flag gets a TTL at creation, and an agent's only job is finding the expired ones and opening the cleanup PR.
Consolidated compute
Fewer, larger clusters, because every extra cluster is another surface the agent plane must never reach.
Secrets and deploy identity
Production secrets are workload-readable only, the deploy role is pipeline-assumable only. No agent identity has a path to either.
Queryable telemetry
Traces and logs an agent can query with SQL, tagged by authorship class.
Automated rollback
Triggered by the analysis guard, rehearsed in staging, not a plan someone assumes will work.
The rule that holds it together
The arrow points one way. An agent puts a PR on the gate, and that's the entire extent of its reach. If you can draw a network path from a sandbox to the production plane, you don't have two planes. You have one plane and a naming convention.
Rule 02
Sandboxes that talk to each other
Only worth building once one agent at a time actually is your bottleneck. Track cross-agent collisions first. If that number's zero, skip this section and come back when it isn't. This is the piece with the least written about it and the highest payoff, and the honest answer is you're going to have to build it yourself.
As of August 2026, the coding-agent platforms ship roughly three inter-agent mechanisms between them, and none of them is sandbox-to-sandbox. Agent teams share a task list and a file-based mailbox on one machine, and are usually unavailable in headless mode. Cross-session messaging works over a per-session socket, but the container boundary is hard. The managed coordinator products give you concurrent worker threads, and every agent in that session shares the same sandbox, filesystem, and credentials.
Read that last one again
Multi-agent means many agents in one sandbox. Teams means many agents on one machine. Neither gives you per-agent blast radius. If you want a fleet where a compromised worker can't reach its peers, you fan out across separate microVMs yourself and you own the transport.
Concurrency you can actually afford
Ten workers on ten microVMs, each with its own database branch, is the only setup that scales past a handful of parallel tasks without agents corrupting each other's state.
The writer literally cannot reach the judge
Put the implementation agent and the review fleet in separate sandboxes, and “don't let the agent grade itself” stops being a policy and starts being a topology nobody can violate.
Design the channel to be weak on purpose
Copy the threat model the agent platforms already publish for inter-agent messaging rather than inventing something richer:
A message is never consent
A teammate denied an action can't relay it through another teammate to get it done.
No configuration transfer
One poisoned worker can't rewrite the rules for everyone else.
Text only, nothing executes
Injection propagating agent-to-agent is the fleet version of a worm. Text-only is the containment.
Provenance is explicit
Peer chatter and human instructions get different trust. They should.
Loop protection
Rate limits and repeat-dropping, so two agents can't talk each other through your budget.
Inbound policy by trust class
Your permissive experiment sandbox can't casually instruct your strict one.
The topology that works
Orchestrator
Owns the task graph, spawns workers, opens the PR. Never touches code itself.
Workers, 3 to 5
One microVM each, one database branch each, one narrow slice of the task.
Review fleet, isolated
Separate sandboxes, no path back to the workers.
Rule 03
Everything is gated by CI
At fleet volume, CI stops being a check and becomes the constraint. The failure is queueing theory, not slow tests, and it shows up faster than anyone plans for.
~2
PRs/hour through a serial merge queue on a 30-min CI cycle
A 50-person team at 2 PRs/dev-day already exceeds this.
12.5%
of merges break main at 40+ developers, vs. 0.77% at 2–5
A 16x scaling with team size, across 153,000 merges in 477 orgs.
94%
of private-repo merges still run one PR per CI cycle
Batching is roughly a 5x lever sitting untouched almost everywhere.
1.9%
break-main rate for AI-assisted PRs, vs. 4.4% for the rest
Same dataset. AI-assisted code broke main half as often, despite bigger diffs.
That last number deserves a fight
Other vendor telemetry claims AI-co-authored PRs carry 1.7x more issues. Both numbers can be true at once, because they're measuring different things. Break-main is a fast, local, CI-detectable failure, exactly the class agents are good at avoiding because CI told them so. The defects that rise under agent authorship are the slow, deep ones: privilege escalation paths, architectural flaws. Use the first number to settle the throughput argument. Don't use either one to settle the quality argument. Whether either number is trustworthy at all is really a question about your test suite, which is the whole case in The agentic prerequisite.
The four things that break, in order
Queue saturation, before CI ever gets slow
As arrival rate approaches capacity, wait time explodes non-linearly. Median queue time runs 5–8 minutes; p90 runs over an hour.
Fix: Batch N PRs into one CI cycle and bisect on failure.
Flake amplification with auto-retry
Agents requeue on red because that's correct behavior for one agent. At fleet frequency, a test that flakes 1 run in 200 fires daily.
Fix: Cap requeues per PR, quarantine flaky tests automatically.
Local and CI drift apart
If the sandbox runs one pipeline and CI runs another, agents optimize against the local signal and you find out at merge time.
Fix: One pipeline definition, executed by the same engine both places.
Review throughput, the real limit
Merge throughput is solvable with batching. Verification throughput isn't. It's the 12.5% break-main rate seen from the other side.
Fix: The review fleet, not more reviewers.
Rule 04
Everything ships behind a flag
A flag-gated merge is reversible in seconds. That single property is what makes agent autonomy affordable.
Flag created in the same PR
Not afterward, not in a follow-up. The kill switch ships with the risk or it doesn't ship. Make it a merge check.
Vendor-neutral API
One flag interface behind an open standard, so the agent writes flag code once. The standards work here is still maturing (worth being accurate about).
Metric-gated promotion
A progressive delivery controller and a promotion state machine above it, promoting or aborting on real signal. No human watching a dashboard deciding whether the canary looks fine.
The new failure mode nobody had before agents
Agents create flags far faster than humans retire them. A codebase with two thousand stale flags is one where nobody can reason about behavior anymore, and it quietly kills the reversibility the whole model depends on. Give every flag a TTL at creation and run an agent whose only job is closing the loop.
Honesty note: no 2025 or 2026 case study names an org publicly running deploy-on-every-merge with everything default-off. Every component is well documented; the full composition looks like something teams do and don't write up. Treat it as a defensible design, not a cited industry practice.
The decision
Autonomy is earned, not assigned
Throw out the table crossing code risk against agent trust. It gates on a static proxy and puts a human in exactly the cells where humans are least reliable. Invert it: an agent can do anything it can prove is safe, where the rig computes the proof. Two things decide: how reversible the change is, and how strong the evidence is.
Reversibility class
Held-out suite hard gate
Mutation score on touched lines
88%Property coverage of the invariants in play
Canary verdict
Surface reputation, last 90 days
72Proof score
threshold 45 · reversible in seconds
Ships unattended
Proof clears the bar for a change that is reversible in seconds. No human in the path, no approval queue, no ticket. Attach the attestation and count it toward the share-shipped-on-proof number.
The move that makes this compound
When the function can't clear a change, that's a defect in your verification, not a reason to page a human. File it against the rig, close it once, and every future change on that surface benefits. Under a tier table the same human gets tapped forever and nothing improves. The autonomy-per-task argument this replaces is laid out in Autonomy levels and blast radius.
Rule 05
Someone has to build this
None of the above is a product you buy. It's an internal platform, and it needs a named owner, a funded team, and a roadmap, or it turns into six half-built things that each work on one team's laptop.
What the platform team owns
Anything systemic is platform; anything specific stays with the team doing the work.
Global context
Shared prompts, patterns, knowledge.
Deterministic guardrails
Security, reliability, compliance.
Agentic tooling
MCP servers, CI/CD, eval frameworks.
Execution engines
Sandbox fleet, inference routing, cost control.
Start here, then grow into it
One person, part-time, with this as a named job, is enough to begin. The published sizing below is what it grows into once the metric says it's worth the headcount, not what you need on day one: 2–4 engineers embedded for a 20–100 person org, 5–15 dedicated at 100–500, federated above that. One frequently cited mature ratio is 8 platform engineers supporting 200 application engineers.
The sobering forecast: 80% of large engineering orgs are expected to have platform teams by 2027. Under 30% are expected to show measurable productivity gains. Having the team isn't the same as the team working (another reason not to over-hire before the metric earns it).
Where teams get this wrong
Putting this inside a central AI org, where it turns into a research function that ships demos: it belongs next to the people who already own CI and deploys, since five of the seven moves here are CI and deploy problems wearing an AI hat. And treating it as temporary: the tooling keeps moving and the fleet's behavior changes underneath you, so fund it as a standing function. The general version of this call, for any platform team and not just this one, is in Platform teams: when, why, and when not.
Rule 06
The bottleneck skill moved
Nobody's velocity problem is that their engineers can't write code anymore.
Code generation is solved. What's scarce now is the ability to build the rails that let generated code reach production safely and fast: a security, infrastructure, and CI/CD skill set. Hiring already moved. Agentic engineering postings care less about prompt writing and more about evaluation harness experience, function calling with real guardrails, multi-agent orchestration, system design. That's an SRE skill list, not an ML one, and senior agentic engineers command roughly a 15 to 20% premium over comparable ML engineers. This is the same shift covered in Review capacity is the new bottleneck.
Every documented failure is an infrastructure failure
- ›Secrets exfiltrated through a malicious issue.
- ›A sandbox escape via indirect injection.
- ›Agent config weaponized as a supply chain attack.
- ›An agent with an over-broad role deleting a production environment.
- ›A merge queue collapsing under a retry storm.
Not one of those gets fixed by a better prompt.
What that means for how you staff this
The scarce person
Someone who can reason about workload identity, egress control, and pipeline design, and is fine with the fact that their users are processes now, not people. Hire from infrastructure and platform, not data science.
The skill to build internally
Verification engineering: mutation testing, property-based testing, held-out eval corpora, flake quarantine. Barely exists as a named discipline yet, and it decides your ceiling.
The trap
Hiring prompt specialists to fix a delivery problem. The prompts are fine. Everything after generation is still built for a world where a human typed the code.
The one number worth reporting
The share of merged changes that reached production on proof alone, no human in the path. Not acceptance rate, not percentage of code written by AI, not seats. If that number isn't climbing quarter over quarter, the platform isn't working, and no model upgrade will move it.
Rule 07
Trust is the actual currency. Redesign how it's granted.
The gate makes autonomy provable. It doesn't make anyone comfortable with it. That's a separate problem, and it's a culture problem, not an infrastructure one.
The bottleneck was never trust in the code. It's trust in the process that checks it. Fix the second one and the first one stops mattering.
Trust of this kind isn't a feeling, it's a price, set the same way it is anywhere else in the org. See Trust is a price, not a poster.
Retire "a human looked at it" as the real approval
Once the gate exists, that sentence stops meaning safety and starts meaning theater. The gate is the approval. A human glance on top of it is a second, slower gate that catches less than the first one.
Reward rail-builders like you reward feature-shippers
If the engineer who closed a mutation-testing gap gets a smaller bonus than the one who shipped a visible feature, you've told the org which one is real work. Calibration committees have to learn to read a verification PR.
Make gate failures blameless, and route them to the rig
A missed property test is a defect in your verification, not in the engineer who approved the pipeline eight months ago. Punish the person and you teach the next one to route around the gate quietly instead of fixing it loudly.
Publish the blast-radius tolerance before an incident forces the conversation
Decide out loud, before it happens, which tier of change is allowed to ship unattended. The alternative is discovering your org's actual risk tolerance during a postmortem, which is the most expensive way to learn it.
Stop treating agent-authored code as guilty until proven innocent
Reflexive extra scrutiny on anything an agent touched re-creates the human bottleneck you just paid to remove. If it cleared the same gate human code has to clear, it gets the same trust. Suspicion belongs in the gate's design, not in a reviewer's gut.
Put a name on who's allowed to raise the autonomy tier
Someone has to own the decision that a surface is ready for a higher proof-score threshold to count as "shipped." Leave it ambiguous and the tier never moves, because nobody wants to be the one who said yes.
What leadership has to do differently
Say the target out loud
The share-shipped-on-proof number goes in the same deck as revenue, not in a chat channel only the platform team reads.
Change what gets promoted
If calibration still rewards heroic manual review over a closed verification gap, the incentive is pointed at the wrong scarce skill.
Absorb the first public failure
One bad unattended merge will happen. Fix the rig, don't revert the program. Rolling back the whole model over one incident is how “pilot forever” happens.
How to sequence it
The first 90 days
Order matters. Build these in sequence, not all at once, and don't let the minimum viable version become the final one.
Days 1–30
Prove you can gate a merge
- ›Turn on one CI check that actually blocks merge. No override, no "just this once."
- ›Name one owner for the platform, part-time is fine, before it's a headcount request.
- ›Leadership writes down the target share-shipped-on-proof number for this quarter. In the same deck as revenue.
- ›Run the reality-check list above against your own org. Write down which of the eight bottlenecks you actually have.
Days 31–60
Make it safe to go faster
- ›Stand up one flag library and a habit of using it on anything risky.
- ›One disposable container per agent task. Skip the microVM fleet for now.
- ›Publish the blast-radius tolerance: what ships unattended, what doesn't, and why, in writing.
- ›Start tracking break-main rate and babysitting hours. You can't manage a number you're not collecting yet.
Days 61–90
Let the gate start saying yes
- ›Run the gate calculator below against your first real change class and read off the proof gap.
- ›Fix the biggest verification gap it finds, not the easiest one to fix.
- ›Ship one change on proof alone, no human in the approval path, and count it.
- ›Report the share-shipped-on-proof number back to leadership. If it's still zero, that's the finding, and it's a useful one.
None of this requires the full stack
It doesn't require the microVM fleet, the six-agent review panel, or a headcount request. It requires committing to finish what you start, on a clock you said out loud.
The scorecard
What to actually track
Nine numbers, pulled from the seven moves above, in one place. Print this. Review it monthly. If a number's flat, that's the next thing to fix, not a reason to add a move you haven't earned yet.
| KPI | What it measures | Good | Watch for |
|---|---|---|---|
| Time-to-trust | Time from an agent finishing a task to a human trusting the diff enough to merge without a full re-read. | ✓ Shrinking, quarter over quarter. | Flat or rising. Your gate isn't doing the trusting for you yet. |
| Break-main rate | Share of merges to main that break the build or a key test. | ✓ Under 2%. | Climbing as agent volume climbs. It's a 16x jump between small and large human teams; agents can do that faster. |
| Cross-agent collisions | Times two agents stepped on the same file, branch, database, or environment in a week. | ✓ Zero. | Any nonzero count that's rising once you're running more than one agent at a time. |
| Time-to-rollback | Time from merge to a rollback you'd actually trust in production. | ✓ Seconds to minutes, because it's flag-gated. | Hours, or “we'd have to redeploy.” That's not a rollback. That's a plan. |
| Share shipped on proof alone | Share of merged changes that reached production with no human in the review path. | ✓ Climbing, quarter over quarter. | Flat. Nothing's actually earning autonomy. |
| Requeue / flake rate | Share of CI runs that fail from flakiness and get auto-retried. | ✓ Under 1% of runs. | Rising retries per PR. An agent stuck in a loop with your test suite. |
| Babysitting hours | Hours a week your best engineers spend supervising or fixing agent output. | ✓ Trending down. | Flat or rising. The platform isn't taking work off anyone. |
| Infra-to-prompt hire ratio | Of your last four engineering hires, how many can debug a broken pipeline versus how many were hired mainly for prompting skill. | ✓ Skewing toward infra and security. | Still hiring for prompt-writing. That's not where the bottleneck is anymore. |
| Engineer trust in unattended merges | Share of engineers who say they'd trust an unattended merge on their own service, asked every quarter. | ✓ Climbing, quarter over quarter. | Flat while share-shipped-on-proof climbs. The gate is working and nobody believes it yet, which is a culture problem, not a technical one. |
Every layer here is described by what it does rather than by who sells it. The products in each category turn over faster than the structure does, and all of them are substitutable. Figures come from a 200,000-PR merge-queue dataset across 477 organizations, vendor documentation for the sandbox and delivery tooling, published agentic platform team topologies, agentic engineering hiring data, and disclosed incidents from 2025 and 2026. Two things flagged as unconfirmed rather than quietly asserted: the open standard for flag APIs is still incubating rather than settled, and no organization was found publicly documenting deploy-on-every-merge with default-off flags as a complete practice. The break-main figures for AI-assisted code contradict other vendor telemetry, and that conflict is called out above, not resolved.