Context Is the Currency
Agile After the AI Agent
AI coding agents produce large gains at the level of the individual developer and almost none at the level of the enterprise. McKinsey’s survey of roughly 300 companies found most capturing five to fifteen percent, even as practitioners report tenfold speedups on individual tasks. The value is real. It is being absorbed before it reaches the P&L.
It is absorbed by the operating model. For most enterprises that model is agile, and agile’s ceremonies (two-week sprints, story-point estimation, daily standups, specialized two-pizza teams, staging gates and sign-off committees) were engineered around one scarce resource: human time. Building was slow, so the rituals existed to ration throughput and to avoid being wrong before too much of that expensive time was spent. When a working first draft of code takes minutes instead of days, the arithmetic those rituals were solving no longer holds.
Time was the old currency. Two things are replacing it. The first is cost: building is now cheap in hours but metered in money, so the governing question moves from “do we have capacity to build this?” to “is it worth what it will cost?” That question belongs to the CFO, not the engineering manager. The second, and the more important, is context. The accumulated, reusable substrate an organization gives its agents (architecture decisions, domain models, conventions, prior specifications, institutional memory) is what determines whether a given task is fast and correct or slow and wrong. Specifications are the visible unit of work, but context is the asset underneath them, and unlike time it compounds. The enterprises pulling ahead are the ones treating context as capital.
The evidence that bolting AI onto an unchanged model fails is now rigorous. A 2025 randomized controlled trial by METR found experienced developers 19 percent slower with AI tools, while believing themselves 20 percent faster. It was a point solution dropped into a context-poor workflow, and the returns were negative. The organizations that rewired rather than layered are seeing gains several times larger, and their pattern is consistent: continuous planning over quarterly, the specification over the user story as the unit of work, testing in production over pre-launch committees, small consolidated pods over large specialized teams, and deliberate investment in the context layer, the thing McKinsey’s top performers build as knowledge graphs. The decisive variable is not tooling, which everyone can buy. It is the discipline of accumulating context and managing the human transition to a new way of working.
Software is simply where this arrived first, because its outputs are digital, specifiable, and testable. The same shift is coming for every function whose work can be specified, delegated, and checked. What follows lays out why the ceremonies strain, why context is the currency that replaces time, and the moves a leader should make now.
The gap nobody can close
Start with the paradox, because it is worth sitting with. Individual developers using AI agents report enormous gains. Work that took two days takes twenty minutes; a migration that would have filled a sprint runs overnight. These are not vendor slides but the ordinary experience of a growing share of practitioners. Yet the enterprise numbers barely move. Most of the roughly 300 companies McKinsey surveyed reported gains of five to fifteen percent. The transformation obvious at the desk all but vanishes by the time it reaches the P&L.
Where does the value go? Not into a technology problem; the tools plainly work. It drains into the operating model, which for most enterprises is agile, and which was engineered around a cost that is now collapsing: the price, in human time, of building software. A good answer to the old economics has quietly become a tax on the new ones.
This is not a claim that agile was a mistake. It was right for the world it was built for. But that world is going, software is where it is going first, and the same pressure is heading for every function whose work can be specified, delegated, and checked. Software is the leading indicator; the rest of this is about reading it.
What the ceremonies were for
Agile’s rituals were not arbitrary. Each solved a concrete problem created by human-paced development, and each problem traces back to a single scarce resource: time.
The two-week sprint solved expensive feedback. When a feature took days or weeks of human effort, discovering late that you had built the wrong thing was costly, so the sprint forced small batches and working software at short intervals. Course corrections landed before too much irreversible effort was spent.
Story points solved allocation. Human throughput was fixed and roughly predictable, and leaders needed a currency to decide what made the cut. Estimation was capacity planning for a workforce whose output could not be dialed up on demand.
The daily standup solved lossy handoffs. Work passed from product to design to front end to back end to QA, and context leaked at every seam. The standup was a daily patch on that leak.
The two-pizza team solved the limits of a single mind. Mastery of a full stack was rare and slow to build, so teams carried a front-end specialist, a back-end specialist, and a QA specialist. Specialization was a workaround for human cognitive load.
The release committee solved expensive mistakes in production. Shipping was risky and reverting was painful, so organizations built elaborate machinery to be right before launch: staging environments, user-acceptance testing, sign-off chains. The apparatus existed because the cost of being wrong in front of real users was high.
Together these describe one coherent world. Building is slow, human throughput is the bottleneck, coordination leaks, no one person can hold the whole, and mistakes in production are expensive. For that world, agile is elegant.
EXHIBIT. The ceremonies were answers to a single constraint. As it changes, so must they.
Now move a single variable. Let the time it takes to produce a working first draft of code fall from days to minutes.
The sprint’s justification weakens, because being wrong is cheap to fix. Rationing throughput in points looks strange once throughput stops being scarce. Much of what the standup patched never occurs, because one person orchestrating agents can carry a feature end to end without the relay. Once one person can hold the whole, splitting it across specialists loses its rationale. And the release committee, built to prevent costly mistakes before launch, starts to look slower and more expensive than simply shipping behind a flag and watching what real users do.
Time was the constraint. Now it is cost, and context
The most important consequence is easy to miss: speed does not make building free. It changes what building costs, and it changes what the organization should be accumulating.
Take cost first. Under the old model, throughput was capped by human hours fixed to headcount; you could not buy more feature this quarter. Under the new model, a feature carries a token cost: a metered, variable price for the generation, iteration, testing, and review the agents perform. Running more agents in parallel buys back time, but it converts saved hours straight into spend rather than saving money. The governing question moves from “do we have capacity to build this?” to “is it worth what it will cost?” Those questions have different owners. Capacity planning belonged to engineering managers; cost per outcome belongs on the CFO’s desk. Story-point estimation was never built to answer what a feature costs at the margin or whether the return justifies it, and agile offers no ritual that does.
But cost is only half of it, and the less interesting half. The deeper shift is in what makes an agent fast and correct in the first place, and the answer is context.
Give an agent a task with no surrounding knowledge and it produces confident, plausible, wrong output, and burns tokens doing it, iterating on drafts that get discarded. Give the same agent the architecture decisions, the domain model, the naming conventions, the prior specifications, the record of why the last three similar features were built the way they were, and it gets the task right on the first pass. Context is what separates the 19-percent-slower developer in the METR study, dropping a tool into a context-poor workflow, from the team shipping overnight. It is the difference between an expensive miss and a cheap hit.
Time was a resource you spent and never got back. Context is a resource you accumulate, and the return on it grows.
This reframes everything, including cost. The way to drive cost per outcome down over time is not to wait for cheaper tokens. It is to build richer context, because a well-contextualized agent wastes nothing. And context has a property that time never had: it compounds. Every specification written, every decision recorded, every convention encoded makes the next task faster and more accurate than the last.
The distinction worth holding onto is stock versus flow. A specification is flow, a point-in-time artifact describing one piece of work. Context is the stock beneath it, the durable substrate every specification draws on and adds to. Agile optimized the flow, obsessing over how fast a story moved across the board. The new game is building the stock. It is why McKinsey found the top performers investing in knowledge graphs as an “AI memory layer” across the development lifecycle. They are not buying better tools than everyone else. They are accumulating the asset that makes the tools work.
The bottleneck moved
When a constraint gives way, the bottleneck does not vanish; it relocates. The expensive error is to keep optimizing where the bottleneck used to be.
The sharpest evidence comes from METR, a nonprofit research group, which ran a randomized controlled trial in 2025 on experienced open-source developers working in codebases they knew well. Developers supplied real issues from their own repositories; each was randomly assigned to permit or forbid AI tools. The researchers expected a speedup. So did the developers, and so did the economists and machine-learning experts asked to forecast the result.
Developers using AI took 19 percent longer.
The perception gap was larger than the slowdown. Afterward the same developers estimated that AI had made them about 20 percent faster, off by nearly forty points, in the direction of believing a tool helped when it did not.
The lazy reading is that AI productivity is a mirage. The useful reading is narrower. This was a specific setup: expert engineers, deep in mature code they already carried in their heads, dropping a powerful tool into a workflow that gave it none of that knowledge. The humans had the context; the agent did not. Under those conditions the tool added friction (context-switching, reviewing and repairing output, shifting mental modes) while nothing in the surrounding system was built to feed it what it needed. That is McKinsey’s disappointing enterprise number reproduced under laboratory control, and it points straight at where the work now concentrates.
Three things become scarce, and a fourth becomes the thing you manage.
The first is context, discussed above and named here as the foundation because everything else depends on it. The second is specification: stating precisely what a task must do, from intent and constraints to acceptance criteria, edge cases, and the things it must not do. Andrew Lau, CEO of engineering-analytics firm Jellyfish, put the shift plainly: for decades the industry assumed coding was the hard part, and it turns out describing what to build is harder. The third is review: a single engineer can now generate more code overnight than a team once wrote in a week, and most enterprises still gate quality through manual human review, so the cheap step got automated while the expensive one flooded. Review is deep, sustained work that does not parallelize by adding agents.
The fourth, cost, is not scarce so much as newly visible and newly variable, and it has to be governed on purpose rather than absorbed into salaries. Context is what keeps it low; loose specification and thin context are what run it up.
Notice that context, specification, and review are all forms of the same thing, namely human judgment applied to what should exist and whether what came back is right. AI did not remove the human from the loop. It moved the human from the middle of the work, where the typing happened, to its two ends: building the context and the spec that go in, and exercising the judgment that checks what comes out.
What the rewired model looks like
The organizations that rewired rather than layered are not stuck at ten percent. McKinsey’s top performers report gains several times larger, and their approach has a recognizable shape.
Planning compresses. The two-week sprint was a batch size tuned to expensive feedback; when feedback is cheap, the batch shrinks, in some cases toward a daily rhythm. Committing to a fixed two-week plan now carries more risk than re-checking direction continuously, so planning becomes a flow rather than a calendar event.
The unit of work shifts from the story to the spec, and the spec draws on accumulated context. This is the most consequential change and the one most easily botched. The loosely written user story with fuzzy acceptance criteria worked when a human engineer filled the gaps from what they knew. Handed to an agent with no such knowledge, the same ambiguity produces expensive rework. In spec-driven development the specification becomes the primary, versioned artifact, with intent, behavior, constraints, and testable criteria written down, and code becomes a regenerable output. But the spec is only as good as the context it sits in, which is why the mature version of this practice invests as heavily in the durable context layer as in any individual spec.
The naive version fails in a predictable direction. Teams that wrap heavy specification ceremony around trivial work rebuild the bureaucracy agile was invented to kill. Martin Fowler’s team documented a spec tool turning a one-line bug fix into four user stories and sixteen acceptance criteria, a sledgehammer for a nut. Specs written once and abandoned drift from the code within hours and become worse than nothing. What works is treating the spec as a living contract sized to the stakes, rich where consequence and irreversibility run high and close to weightless where they do not, all of it drawing on a context base that makes even the lightweight specs land accurately.
Testing moves into production. This is the sharpest break with agile orthodoxy, and it follows directly from cheap reversibility. What once required a cross-functional committee and a round of user testing before launch can increasingly be shipped behind a feature flag and validated against real usage in a week. When building takes a day and reverting is trivial, the elaborate pre-launch apparatus of staging sign-offs, acceptance committees, and the whole machinery built to be right before shipping becomes slower and more expensive than the thing it was protecting against. The discipline does not disappear; it relocates downstream, into observability, guardrails, and fast rollback. Leaders learn from what real users actually do rather than from what a committee predicted they would do.
Teams get smaller and roles consolidate. The two-pizza team gives way to what McKinsey calls one-pizza pods of three to five people, and specialist boundaries blur. Rather than separate front-end, back-end, and QA engineers passing a ticket down a line, a product builder with full-stack fluency orchestrates agents across the whole feature. The job moves from writing to directing and verifying: building context, decomposing work into agent-ready tasks, supervising generation, validating architecture, owning quality. In McKinsey’s phrasing, roles shift away from manual coordination toward architecture coherence, domain modeling, and AI supervision.
The clearest image is a two-shift day. Humans work days, setting direction, resolving ambiguity, hardening guardrails, reviewing output, and aligning stakeholders. Agents work nights, enriching requirements, generating and testing code, packaging results for morning review. A product owner logs in at nine to find a feature moved overnight from structured requirements to tested code, edge cases flagged, trade-offs summarized. Nobody worked late.
This is not a forecast. Consider how one of our directors already operates. The unit of work is the PRD, a precise structured specification, rather than the meeting; because the spec coordinates the work, much of what a standup exists to synchronize happens in the document. Several coding agents run in parallel against that spec, each taking a slice, and they reach into the backlog and issue tracker directly through tool integrations, so status once assembled by hand is read straight out of the system. Underneath sits the part that makes the rest work: a maintained base of skills, conventions, and past specifications the agents draw on, so each new build starts from accumulated context rather than a blank page. Human hours concentrate at the two ends that now matter: getting the context and the spec right going in, and reviewing what returns. The work did not get easier; its shape changed, from producing artifacts to directing and verifying a system that produces them. The top-performer pattern is already someone’s ordinary working week.
The larger signal
Everything above is about software, and it matters to leaders who never ship code because software is a preview. The shift arrived here first because software’s outputs are digital, specifiable, and testable. The underlying dynamic is not confined to engineering: the time cost of producing a class of knowledge work collapses, a variable money cost takes its place, and durable advantage moves to whoever has built the best context for the machines doing the work.
The same pattern is already visible in earlier form wherever work can be described precisely enough to delegate and verified reliably enough to trust: drafting, analysis, design, research synthesis, first-pass legal and financial work. As it arrives, the same questions that surfaced in software will surface again. Four are worth naming now, and one matters more than the rest.
Context is the compounding asset, and it should be managed like one. The organization’s accumulated knowledge (decisions, conventions, precedent, the reasoning behind past choices) used to live in senior people’s heads and leak away when they left. Fed to agents as a maintained context layer, that same knowledge becomes an asset that makes every future task faster and cheaper, and one that compounds rather than depreciating. The strategic question this raises is unfamiliar and important: what is your organization doing to capture, structure, and grow its context, as opposed to merely buying tools that consume it?
Judgment concentrates while execution delegates. Durable human work is collecting at the two ends of the process. It is deciding what should exist and building the context for it, then confirming that what was produced is correct and safe, while first-draft production moves to the machine. Taste, framing, and verification rise in value; raw throughput falls. Companies that built their hiring and promotion ladders around execution speed have pointed those ladders at the wrong skill.
The apprenticeship question is real and largely unanswered. If junior staff no longer produce the volume of code, drafts, and analyses through which expertise was historically built, the pipeline that produces senior judgment thins, and early evidence suggests leaning on AI can erode the very skills needed to supervise it. This is not an argument for slowing down. It is an argument for cultivating judgment deliberately once it stops being a free byproduct of execution, and for putting that on the leadership agenda before the ladder breaks rather than after.
Measurement has to change, and cost per outcome belongs on the board’s dashboard. Bottom performers in McKinsey’s survey frequently were not measuring speed at all, and only about ten percent measured productivity, while many companies proudly tracked tool adoption as though logins were value. Adoption is an input. Leaders capturing value measure the full chain: inputs including the real spend on upskilling, change, and context-building; throughput such as cycle time, quality, and resilience; and economic outcomes such as time to revenue and cost per unit of delivery. That last measure is newly load-bearing, because once cost rather than time constrains building, cost per outcome is what a CFO can read directly, and the fastest way to improve it is to invest in the context that makes agents right the first time.
One finding sits above the rest. The distance between companies stuck at ten percent and those seeing multiples had little to do with which tools they bought, since the tools are available to everyone. It came down to two things money cannot shortcut: the context they accumulated, and the human transition they managed. McKinsey frames that transition as getting twenty or thirty small things right at once: how the change is communicated in terms of someone’s daily work, how it is incentivized, how people are upskilled, how progress is measured. One company rolled tools out without that scaffolding, watched usage spike and fade while impact stayed flat, and had to reset from scratch before anything stuck. Buying the technology is the easy part; building the context and bringing the people are the work.
What to do now
The agile manifesto is not the casualty here. Working software over documentation, responding to change over following a plan, short feedback loops, close collaboration. The agentic model arguably honors those commitments more fully than two-week sprints ever did. Feedback measured in hours is more agile, not less. What has aged out is the specific ceremony built for a world where time was the scarce resource. The task is rewiring, not repudiation.
Six moves follow from the evidence.
Treat context as capital. The single highest-leverage investment is the reusable knowledge layer your agents draw on: architecture, domain models, conventions, decision history, prior specifications. It is what makes everything else faster, cheaper, and more accurate, and it compounds. Start capturing and structuring it now, and fund it as the asset it is rather than as documentation nobody reads.
Start now, and run it as a human change. This is a reworking of habits and roles, not a tool rollout, and the companies that waited for certainty are the ten-percent companies. Begin, and begin expecting the hard part to be people.
Match the model to the work. There is no single replacement for the sprint. Well-defined, high-context work such as legacy modernization suits a factory model, humans specifying and reviewing while agents do the heavy execution. Exploratory greenfield work suits an iterative loop, agents generating options for fast human feedback. Diagnose the work before imposing a model on it.
Move the unit of work to the specification, sized to the stakes and grounded in context. Invest in the skill that is now scarce, precision about intent, and adopt spec-driven practice, but calibrate the weight of each spec to the consequence and reversibility of the work, or the old bureaucracy returns through the side door.
Shift testing toward production, safely. Where reversibility is cheap, replace pre-launch committees with feature flags, real-usage validation, strong observability, and fast rollback. Learn from what users do, not from what a committee predicts, and reserve the heavy pre-launch apparatus for the genuinely irreversible.
Measure outcomes and fund the transition. Replace adoption dashboards with outcome measures across the full chain from input to economic result, make cost per outcome a visible number, and budget seriously for upskilling, coaching, and context-building, because that spend, not the tooling spend, separates the companies that capture the value from the ones that watch it evaporate between the desk and the P&L.
The tools work; that much is settled. What remains unsettled in most enterprises is whether the operating model around them gets rewired to let the value through, whether the organization builds the context, reshapes the roles, and brings its people along. That is a question about how work is organized rather than a technical one, and it is already on the table.
Sources
This point of view draws on McKinsey’s research into AI-native software development and the agentic SDLC, including a survey of roughly 300 enterprises; the METR randomized controlled trial on AI’s effect on experienced developer productivity; and the emerging body of practice around spec-driven development, including published accounts from GitHub, AWS, and Martin Fowler’s team. Full citations available on request.