The Agentic Awakening, and the Layer Above the Agents

Bessemer published a study this week called The Agentic Awakening, written by Liran Eshel and Adam Fisher, and it contains the single most useful number we have seen this year. Across the companies they studied, engineers got roughly ten times faster at producing code. Organization-level throughput gains landed between 25 and 30 percent and never broke 50. Their external data is worse: across more than 400 companies, median pull request throughput rose 7.76 percent while AI adoption rose 65 percent.

We read that and recognized every quarter of the last two years. They summarize it as a Ferrari at every stoplight, and the chapter behind that line asks you to picture trading a slow sedan for a sports car and then driving it a city route with a red light every 200 meters. That is exactly the shape of the problem, and it is the reason we get on calls with engineering leaders who are simultaneously thrilled about what their best engineers can now do and unable to point at a single business metric that moved.

We wrote about this stall in May, in The Plateau at Level Three, using Dan Shapiro's mapping of AI-assisted development onto the five NHTSA levels of driving automation. The argument there was that teams get to Level 3, the human-in-the-loop reviewer with an agent running in five tabs, and stop, because trust doesn't compound between runs, verification doesn't scale, and specs aren't precise enough to hand to a machine. What we didn't have then was evidence at scale. Now there is a study of hundreds of companies putting numbers on the same wall, and its own maturity ladder lands on the same rung.

The gap between a fast engineer and a fast organization

The report's ladder has four rungs. Level I is the AI-assisted IDE, driver assist. Level II puts AI into CI as a reviewer. Level III is long-running sandboxed agents that write code and open pull requests on their own, several per engineer. Level IV is fleet autonomy, where the system triggers itself from bugs, CI failures, production incidents, Slack threads, and PRDs, and humans govern only the consequential changes.

Two independently built frameworks, and they stall at the same place and reach for the same word for the top. Bessemer's Level III is Shapiro's Level 3 almost to the sentence, and both call the summit a dark factory. When two people counting different things arrive at the same rung, the plateau is a structural feature of how this technology gets adopted rather than an artifact of anyone's sample.

Almost every team we talk to sits at Level III and has been stuck there for a while. They have capable agents. Engineers run three or five in parallel. The code is good. And the moment a piece of work has to move between two humans or two systems, everything reverts to human latency. A bug gets filed and waits for someone to notice it. Triage produces a scoped ticket that waits for someone to decide it is worth working on. A pull request opens and waits in a queue. An agent finished its work in eleven minutes and the ticket took nine days.

The step from Level III to Level IV is a change in who starts the work. Level III is developer-initiated: a person opens a tool, chooses an agent, pastes context, reviews output. Every unit of agent work is gated on a human remembering to summon it, which means total organizational output is capped by human attention no matter how fast any individual agent runs. Level IV inverts that. The organization's own signals become the triggers, and work starts because something happened, not because someone had time.

This is the part of the report we would underline for anyone reading it. The ceiling is not caused by agents being too slow. It is caused by everything between the agents still running at the speed of a person noticing.

What the churches are built for

The report's first chapter, Build the Churches, is the part we'd defend hardest against a skim reader, because it insists that infrastructure comes before belief and it is specific about what infrastructure means. Four dimensions of foundation: coding infrastructure moving from worktrees to containers to managed sandboxes, a dedicated AI Ops team owning the internal stack, measurement, and a security posture that assumes agents. Their closing line on it is that a company which has only bought AI coding licenses is still experimenting. We agree with the chapter and we'd agree with the order.

Look at what those four dimensions have in common, though. Every one of them is about the agent. How it runs, who owns the thing it runs on, how you count what it produced, and how you keep it from hurting you. Build all four well and you get an excellent Level III: capable agents, safely sandboxed, properly measured, owned by a real team. That is a substantial achievement and it is where their study's median sits.

Now read their own definition of the rung above it. Level IV is systems that self-trigger from bugs, CI failures, incidents, Slack threads, and PRDs, with humans governing only the consequential changes. That requires a layer that decides what work starts, routes it between agents and people, and holds the gates. None of the four foundations produce it, and the report knows that, which is why its closing sections turn to who should build that layer and to the new tools rebuilding the substrate underneath it. Our two disagreements both live there.

That layer is the entire thing we build, so we would rather say plainly what we think it consists of than gesture at it. The plateau post named six capabilities the Level 3 to 4 step needs: memory that compounds across runs, verification that scales past human reading speed, specifications precise enough to execute, governance, audit trails, and a way for the system to improve itself. Written before this study existed, that list is our answer to the gap the study measured.

Start with the substrate. Their section on rebuilding the stack below collaboration observes that GitHub and Slack were designed around human speed, developers making occasional pushes and teammates reviewing a manageable number of changes, then points at Origin, Buzz, and Band as the alternatives taking shape, with the forge products meant to sit alongside GitHub now and replace it once human-paced hosting becomes the bottleneck. They read all of it as the direction of travel, infrastructure built for agent-scale execution rather than, in their words, human-scale workflows with agents bolted on. The observation about human speed is correct. The conclusion isn't the one we'd draw. Our bet is that the coordination layer sits above the tools teams already trust and makes their existing control surface programmable, because a label change, a ticket comment, and a review approval are already control actions an engineering organization understands. Asking a company to move its forge and its chat in order to run agents is a much larger ask than the problem requires, and it is the kind of ask that keeps a good idea in a pilot forever.

The second disagreement is with a single clause. Their fourth key takeaway says that a dedicated team must own the internal AI infrastructure, and that the wiring into your own runtime is the part you can't buy off the shelf. On build versus buy the chapter itself is more balanced than that clause suggests, and it lands close to where we land, telling you to own the parts specific to you, your context, your sandboxes, your evals, and buy the rest. But the clause is the part a reader remembers, and we think it is the part that has stopped being true. The wiring is precisely what can be bought now. A team of two to five people permanently tracking a stack that turns over monthly is a real and recurring cost, and for most companies in their own study it is how the Level IV project becomes a roadmap item that slips every quarter. We wrote about that tradeoff separately.

What we see when a team tries to get past it

The interesting thing is that teams find this on their own. We have watched the same progression enough times that we can now predict it.

A team adopts one workflow and it earns trust. Usually triage, sometimes root cause analysis, sometimes an autonomous review pass. It works, so they add a second. Then they want the two to connect, and because there is no other mechanism available, they connect them with conventions. Triage finishes by putting a needs-rca label on the ticket. A trigger watches for the label and fires RCA. That chain works, and it carries teams a surprisingly long way.

Then it hits a ceiling of its own. The journey exists only as an emergent property of scattered triggers and label conventions across runs that do not know they are related, so nobody can see it in one place. Every workflow ends up carrying hardcoded knowledge of whatever runs downstream, which makes each one harder to change. And the chain only moves forward. When a review turns up evidence that the root cause was wrong, going back means a person re-triggering workflows by hand and pasting context between them, which is the exact coordination work the automation was supposed to remove.

That is the concrete version of the 50% ceiling, and it explains why the report's headline gap is so wide. The teams in that study automated the parts of the lifecycle that fit inside a single agent invocation, which is most of the visible work, and left the connective tissue to humans, which is most of the elapsed time.

We built orchestrations for that connective tissue specifically. The journey gets pulled out of the individual workflows and given a first-class home: a prose goal describing what "done" means, a closed set of workflows the orchestration is allowed to invoke, gates wherever a human should decide, and bounds the engine enforces. Routing happens at runtime. A workflow reports a structured result and usually a proposal for what should happen next, and that proposal becomes a decision that rules resolve instantly, a supervisor agent reasons about, or a human answers. The flow is a record of the path actually taken rather than a graph somebody drew in advance.

The reason this shape matters for the ceiling is that the handoffs stop depending on attention. Two orchestrations run against Overcut's own backlog today. One carries a new issue from triage through analysis and design to an open pull request. The other picks up that pull request and runs the review loop until it is validated ready. Chained together, a ticket travels from filed to merge-ready with humans making three calls: approve the design, approve the fix, merge the result. Everything else that used to be a person noticing an output and starting the next thing is now a decision the system makes and records.

Governance is what makes the inversion survivable

Here is where we think the report is most useful to people who have to actually sign off on this, and where it lines up almost exactly with what we built.

Their security chapter ends with ten rules for agentic security. Give every agent an identity with an owner, purpose, permissions, and expiry. Separate exposure from authority, keeping untrusted intake apart from high-impact execution. Control tools and shield credentials, allow-listing destinations and brokering short-lived access so agents never see secrets. Monitor, contain, recover, with sandboxes, budgets, kill switches, and rollback. Know where humans must decide, defining what runs automatically, what needs review, and what requires sign-off.

Read that list again as an infrastructure requirement rather than a policy document and it describes a control layer. Every one of those rules is a property of the system that runs the agent, and none of them can be satisfied by an agent that runs in an engineer's terminal against their personal credentials. This is the argument we made in why we build the run and control layers, and seeing it arrived at independently from a study of other people's companies was the most validating part of reading the report.

The rules we care about most are the ones about where humans decide, because that is where the ceiling and the governance question turn out to be the same question. The report is honest about a thing most vendors will not say out loud: when agents write most of the code, human review becomes the bottleneck, and much of it becomes theater, with low-risk pull requests rubber-stamped in seconds because nobody can meaningfully read that volume. Their proposed middle ground is risk-tiered, with a model doing the first pass and presenting judgment plus evidence, the change surfaced and acknowledged in the channels where work already happens so it becomes an audited record, and genuine scrutiny reserved for the tail that carries real risk.

That is exactly what a gate should do, and it is why we modeled approval as a first-class decision record rather than a status field. Every promotion in an orchestration writes a row: what was proposed, by whom, at what confidence, and how it resolved. The approval inbox is literally the set of decisions still pending. The audit trail, the analytics on how often humans override the router, and the approval interface all fall out of the same table, which means the record exists whether or not anyone ever asks for it.

Two properties of that design matter more than they look. A gated workflow skips the supervisor agent entirely, so there is no prompt anywhere in the system that could talk a model through a human gate, because gate checks run in the promotion path outside any model. And the gate lives on the ticket or the pull request, where the engineer already is, so approving a design is a comment rather than a trip to another console. The report's "workable middle" only works if the acknowledgment happens in the channel where work happens. We agree, and that is also why we made control actions in Jira, GitHub, and Slack first-class rather than building a separate AI console nobody wants to learn.

The report's most expensive anecdote makes the case better than we could. An AI-native startup let agents build a critical internal application with no explicit architecture review, the system failed, and it cost roughly $500K in lost billing over two months. Their fix was to add a system design review between requirements and code. That is a gate. The distance between recognizing you need one and having one that cannot be skipped is a platform, and it is a distance most teams underestimate.

The distribution problem is a distribution problem

One more finding deserves attention, because we think it is commonly misread. Citing Cursor's 2026 developer habits data, the report notes that AI output is brutally concentrated: the p99 engineer ships 46 times the median's AI-written lines, with a Gini coefficient of 0.77. CircleCI data shows the top 5 percent of teams nearly doubling throughput while the median grew 4 percent.

The report's read is that gains concentrate rather than spread, so you should manage the distribution rather than the average. True, and we would add the mechanism. Individually-scoped tooling concentrates gains by construction. When the unit of adoption is an engineer configuring their own environment, the returns go to whoever invests the most in configuring it, and there is no path by which that investment reaches anyone else. The best engineer's context files, subagent setup, and hard-won prompt patterns live on their laptop.

The way that practice reaches the other 95 percent is by becoming a workflow that anyone's ticket can travel through. That is what a playbook is: one engineer's judgment about how a code review should go, encoded once, applied to every pull request in the organization whether or not the person who wrote it is on shift. The report's own framing of Believers needing "visibility, distribution as champions, and reusable playbooks" is pointing at this. We would say the playbook has to be executable rather than a document, or it stays a document.

What this does not solve

We should be clear about the parts of the report we cannot answer with software, because pretending otherwise would be the wrong kind of confidence.

The conversion problem is real and it is human. The report distinguishes architecture-bound resistance, where an engineer's objection is about missing tests, sandboxes, and observability, from identity-bound resistance, where the objection is about mastery and control. No platform converts the second kind. Their plays there are social: pair the resistant engineer with a believer, convert expertise into validation criteria, name the fear out loud. Those work, and nothing we ship substitutes for a leader willing to run them.

Architecture-bound resistance we can help with but not fix. If a codebase has no test coverage and no service boundaries, running more agents against it faster produces more changes against weak foundations, and orchestration makes that happen at a higher rate. Bounded autonomy contains the blast radius; it does not create a verification layer that was never there. Teams sitting on a coupled monolith should read the report's six plays for an agent-ready stack before they read anything we have written.

Measurement is the place where we are most honest about being early. The report found measurement to be the weakest dimension across their entire study, a median score of 1 out of 4, with fast movers skipping instrumentation on purpose because it feels like drag. We think that is partly an architecture problem, since work that runs through a system measures itself and work that runs in a thousand private terminals cannot be measured at all. Every orchestration run leaves a full record of which workflows ran, what each concluded, who approved what, and why. But turning that into the metric the report actually asks for, complexity-weighted throughput per engineer, is not something we have solved. We can tell you what happened. Weighting it by how hard it was is still an open problem, and anybody claiming otherwise is selling a number they made up.

The cost picture in the report is a good reminder of why the run layer has to own budgets. One AI-native company burned $28,000 in a month from a single command that spawned 50 parallel agents and left them looping. Uber exhausted its entire 2026 AI budget in four months. Step caps, repeat limits, concurrency ceilings, and idle timeouts are the difference between a fleet and a runaway process, and they belong in the engine rather than in a finance review after the fact.

Where we think this goes

The report closes with a line we keep coming back to: those who see the awakening early will define the next era of software, and everyone else will wake up inside it. We would add a smaller and more actionable claim.

The gap between a 10x engineer and a 1.3x organization is made of handoffs. Every one of them is a place where work stops moving and waits for a person to notice. You can attack that by reorganizing the people, which the report covers well and which every company will eventually have to do. You can also attack it by taking the coordination out of people's heads and putting it into a system that runs the same way every time, produces the same evidence every time, and can be inspected afterward. The second one is available now, it does not require anyone to change their title, and it makes the reorganization easier when it comes, because you cannot flatten an org tree around coordination that only exists as tribal knowledge.

The report is right that the turns keep coming, and that a structure built for a 5x world is already behind in a 20x world. What we would add is that Level IV is a layer, not a milestone. It arrives when somebody installs the thing that decides what work starts, routes it, and holds the gates, and it does not arrive because a company got good enough at Level III to graduate. The organizations that get past 50 percent will be the ones who wrote their lifecycle down somewhere a machine can execute it, with humans on the gates that matter and a record of every decision. That is the system we are building. We named the plateau before this study existed, and now there are several hundred companies worth of evidence that it is the real one.