AI is putting agents into production faster than organisations can supply and govern the context those agents run on. The Absorption Gap you have started to worry about on the output side has a twin on the input side, and it is the one almost no one is measuring.
In short: The Absorption Gap has two fronts. On the output side, machines write code faster than you can verify and operate it. On the input side, you deploy agents faster than you can supply, refresh, and govern their context. In Redis's 2026 survey, 97% of leaders called context the deciding factor for production AI while 4% had built the systems to supply it. The measure that matters extends from validated business value per unit of human intervention to whether you can gauge production readiness at all, and whether your context compounds or fragments across use cases.
Start with the number that should worry you
In Redis's 2026 State of Context Engineering survey, 97% of leaders said context is the deciding factor for whether production AI works. Just 4% had built the systems to supply it. Redis sells data infrastructure and has an obvious stake in that framing, so treat the exact figure as directional. The pattern underneath it, belief running far ahead of practice, holds across independent sources with no such stake.
Set that beside a finding from the other side of the system. In a 2025 controlled trial, METR watched experienced developers work in repositories they knew well and measured them 19% slower with AI, while they believed they were roughly 20% faster. The caveat matters, because honesty is the point: these were senior engineers on mature codebases, and greenfield or junior results look different. Even so, the result is hard to forget. Delivery slowed while the dashboard kept smiling.
Two numbers, one problem. On the output side, perceived productivity has come loose from real productivity. On the input side, belief in context has come loose from any system that supplies it. I have written about the first as the Absorption Gap. This piece is about its twin. You solved for too much code; now you have to solve for too many agents.
Figure 1. Belief has raced ahead of practice. Leaders agree context is decisive; almost none have built the capability to supply it.
Same shape, second front
Set the two halves of the gap next to each other and the symmetry is clear.
The output side is code arriving faster than the organisation can verify and operate it. The input side is agents arriving faster than the organisation can supply, refresh, and govern the context they depend on. One economic shape sits underneath both, where supply outruns the capacity to absorb it. That is why the Absorption Gap holds up as an idea rather than fading into a single observation about code review. Whenever AI adds supply, the same disciplined question applies: which capacity now has to scale to take that supply in, and is it able to? Ask it of generated code and you land on verification. Ask it of agents and you land somewhere most operating models have never had to think about, which is the system that feeds them.
The supply is already here
Look at how much has landed while the industry argued about model quality. Gartner estimated that by early 2026 around 80% of enterprise applications were shipping or updating with at least one embedded AI agent, against roughly a third two years earlier. Mayfield's 2026 survey of 266 CXOs found 42% already running agentic AI in production, and 72% once pilots are counted. None of this forecasts the future. It describes the current install base.
What happens to that supply is the revealing part. Anaconda and Forrester report that 88% of agent pilots never reach production, and the reasons have little to do with model capability. The blockers they name are gaps in evaluation and observability (64%), friction around governance (57%), and reliability (51%). Mayfield's respondents point at the same problem from another angle, naming data quality and integration as the top obstacle rather than any shortfall in the technology, with 60% lacking a formal governance framework of any kind. AvePoint's 2026 figures add the financial edge, with 86.9% of organisations having held back a deployment because data security and governance were not ready.
Line those numbers up and the situation is not subtle. Agents are arriving faster than the organisation around them can feed or control. That is a problem of absorption, not capability, and it mirrors on the input side everything the output-side gap has been signalling about code.
Where the constraint actually moves
Here the systemic view starts to pay off, and it parts company with the tidy consensus that the bottleneck simply moved to code review.
Picture the AI Engineering Production System as the map of how work travels from intent to production and back. On that map the constraint never settles in one place; it keeps moving. This is Constraint Migration, the mechanism that governs the output side too: relieve one constraint and it reappears at the next least scalable step. Clear the coding bottleneck and it resurfaces downstream at verification. On the input side it resurfaces in two spots at once. Upstream, at context and data supply, the agent cannot reliably find its way around your systems. Across the whole chain, at governance, nobody can reconstruct afterwards what the agent looked at or why it acted.
Figure 2. The AI Engineering Production System. The constraint reappears not only downstream at verification, but upstream at context supply and across the chain at governance.
The obvious objection is that you solve the upstream problem by handing the agent more context. The mechanism says otherwise. Chroma's research on context rot tested 18 frontier models and watched every one of them lose accuracy as the context grew, several sliding from around 95% down to 60 or 70% well before the window was full. A bigger context window relocates the cliff without removing it. Supplying context that genuinely works turns out to be an engineering and data-modelling problem, one that wants a semantic model of the business, a graph linking its entities, and a freshness guarantee, rather than more text pasted into a prompt.
The parallel with the last decade is almost exact. Teams that compressed release times from weeks to minutes often found they had built a machine for shipping the wrong thing faster, because the pipeline was never the only constraint. The quality of the product intent flowing into it mattered just as much. Agentic AI stages that same lesson on the input side. An agent that moves quickly on a thin or stale picture of the business produces speed rather than value, and often just reaches a confident mistake sooner.
The field has already begun to reprice that risk. In the Redis data, 69% now say an agent that cannot navigate across systems is more dangerous than one that hallucinates. A confident wrong answer is a failure mode we understand. An agent acting on an incomplete model of the organisation, leaving no trace of what it consulted, is a newer and stranger one, and it happens to be the failure the current tooling conversation is worst equipped to catch.
The dashboard lies here too
The input side runs its own version of the perception gap, and it lines up almost perfectly with the METR result. Around 60% of leaders rate themselves ineffective at governing who and what can reach their context. About 58% feel confident that context is well governed.
Figure 3. The same illusion, on both sides of the system. Confidence peaks where control is weakest.
Same illusion, different domain. On the output side, perceived productivity had come loose from real productivity. On the input side, perceived control has come loose from actual control. The second is the more dangerous of the two, since misplaced confidence about governance is the most expensive kind to correct. A team that overestimates its speed loses a little time. A team that overestimates its control puts an unmonitored agent into a regulated process and learns the truth afterwards.
Measure the system, not the belief
The answer here is not another tool. It is a measurement habit joined to an operating-model decision.
The metric I keep returning to on the output side, validated business value per unit of human intervention, carries over to the input side with one addition. Ask alongside it whether you can measure your agents' production readiness at all, and whether your context compounds across use cases or fragments with every new one. In the Redis data, only 42% of organisations say they can measure production readiness. A migration you cannot measure is a migration you cannot manage, and most organisations are still counting belief and adoption while the readiness of the real system goes unwatched.
That reframing lifts the question to the altitude where it belongs. The market is halfway through a rename. Gartner announced in 2025 that prompt engineering was out and context engineering was in, and the label is spreading fast. As a description of the practitioner's bench, it is accurate. Renaming the individual skill, though, leaves the executive question sitting untouched. The industry renamed the discipline; nobody renamed the CTO's job. Either context becomes an organisational asset with a named owner, a budget, and a governance model, or it stays improvised plumbing rebuilt by hand on every new project. Only one of those two compounds.
A test you can run this quarter
Take a single agent already in or near production and try to answer three questions honestly.
Can you state its graduation criteria, meaning what "ready" actually requires of it, in one sentence? A pilot that cannot is not really a pilot. It is a demo with a subscription.
For one real decision that agent made, can you reconstruct what context it saw and why it acted? If not, a governance gap is sitting below the line of anything your dashboards currently show.
Is the context that agent runs on reused and compounding across your other use cases, or rebuilt by hand each time? Rebuilt each time means you are renting a capability that sharper competitors are quietly learning to own.
Most organisations will stumble on at least one of the three. Any stumble points to a second Absorption Gap, this one on the input side, harder to spot than a backed-up review queue and a good deal more expensive to leave alone.
The output-side question asked whether your system could absorb the code your agents produce. The input-side question is quieter and carries further. Does your organisation treat context as improvised plumbing or as compounding infrastructure? Whatever you settle now, by decision or by neglect, sets the ceiling on what your AI can do for the next five years.
FAQ
What is the second Absorption Gap?
It is the input-side version of the Absorption Gap. Where the output side is code generated faster than an organisation can verify and operate, the input side is agents deployed faster than the organisation can supply, refresh, and govern the context they depend on. Both are the same economic shape: AI adds supply faster than the capacity to absorb it can grow.
Isn't this just context engineering?
Context engineering describes the practitioner's craft of assembling what a model sees. It is real and useful, but it sits at the individual bench. The second Absorption Gap is the operating-model question above it: who owns, funds, and governs the system that supplies context across the organisation, so it compounds instead of being rebuilt on every project. Renaming the skill did not answer that.
Won't a bigger context window solve it?
No. Chroma's context-rot research found frontier models losing accuracy as context grows, several dropping from around 95% to 60 or 70% before the window is full. A larger window relocates the failure without removing it. Supplying context that works is a data-modelling and governance problem, not a matter of pasting in more text.
How do I measure input-side readiness without buying tools?
Take one agent in or near production and answer three questions. Can you state its graduation criteria in one sentence? For one real decision, can you reconstruct what context it saw and why it acted? Is that context reused and compounding across use cases, or rebuilt by hand each time? A stumble on any of the three locates your gap.
Who should own context in the organisation?
Someone named, with a budget and a governance model, the same way data or platform capabilities are owned. The alternative is improvised plumbing reassembled per project, which does not compound. It is an operating-model decision before it is a technology one.
Read further
The thesis in full: Redesigning engineering production for the agentic era
The output-side original: The Absorption Gap
The concept page: the Absorption Gap
The model behind this piece: the AI Engineering Production System
Where this goes next: context engineering is the wrong altitude
Sources
Redis, State of Context Engineering 2026 (vendor-sponsored; treat as directional). redis.io
Anaconda / Forrester, 2026 (agent pilots to production). anaconda.com
Mayfield, 2026 CXO survey (agentic AI in production). mayfield.com
AvePoint, State of AI 2026 (governance readiness). avepoint.com
Chroma Research, Context Rot (2025). trychroma.com
Gartner, 2025 (embedded agents; context vs prompt engineering). gartner.com
METR, Measuring the Impact of Early-2025 AI on Experienced OSS Developer Productivity (2025). metr.org