I built Salt to automate the visible stuff. Config, state, infrastructure you could point at. That was the problem in front of us in 2011, and we solved a good deal of it.
What multi-generational management exposed is the invisible stuff - the components that were there, running, load-bearing, where only the person who built it knew why.
Institutional amnesia dressed up as architecture
A social media company I know ran a metadata audit. A large share of their production datasets came back orphaned, unowned, or redundant. Nobody had a reliable count of running APIs.
I used to treat that as an unusually bad case. It isn’t. When Cloudflare compared what its customers had self-reported as their API inventory against what machine learning could actually discover across their traffic, it found 30.7% more endpoints than the customers knew about - nearly a third of all APIs effectively invisible to the organizations running them. Postman’s 2025 survey of more than 5,700 developers and architects found 34% of teams simply unable to find APIs that already existed inside their own organization.
This is often caused by feature creep, lack of documentation, or simply employee turnover, but in any case it is a major risk and blind spot.
Here’s the part that gets ignored, and it’s the part that matters now: even after that company fixed visibility, the reasoning behind the decisions was gone. The approvals. The exceptions. The judgment calls. None of it had ever been in any system.
For a long time, that was survivable. Someone always remembered. The engineer who set up the exception was still on the team, or one desk over, or at least reachable on Slack. The knowledge lived in people, and people were in the room.
Now you’re handing an agent a renewal decision and a policy cap, and it has no idea why exceptions ever got made.
Agents don’t create this mess. They’re pulling up the rug and trying to work with decades of dirt that got swept under there. They just refuse to hide it anymore.
Automation captured the what. It never captured the why.
The tools available dictated the course we took, it wasn’t due to negligence.
Every configuration management system I know of - including mine - was built to answer one question well: what should this system look like? Declare the desired state, converge to it, keep it there. That was the right question in 2011, and encoding the answer in version-controlled code was a genuine advance over a wiki page and a senior engineer’s memory.
But look at what a state declaration actually records. It records that this service runs with these limits, on this network, with this retention policy. It does not record why the retention policy is what it is, or why a memory limit is oddly specific because some workload got OOM-killed twice and somebody landed on a number that stopped it. The rationale lived in a ticket, a thread, or a conversation. The code inherited the decision without the reasoning.
For fifteen years that was a fair trade, because the systems consuming that configuration didn’t need the reasoning. They needed the value. A converging state machine doesn’t ask why the limit is what it is; it just enforces it.
Agents are the first consumer that needs the why. Ask an agent to right-size that memory limit and it will look at utilization, see enormous headroom, and reduce it - because nothing in the environment tells it the headroom is the entire point. Ask it to clean up unused datasets and it will find the orphaned ones, which is genuinely useful, and it will also find the one that looks orphaned and isn’t. Every judgment call we made and didn’t record is now a landmine in a task we’re increasingly happy to delegate.
The survey data has caught up to this. Teradata and Wakefield Research asked a thousand technology leaders this summer what was stopping their agentic AI work. Missing metadata, context, and relationships was a top barrier for 43% of them. And 77% said that 20% or less of their enterprise data and knowledge was ready for agents to use reliably.
The knowledge we lost was mostly knowledge about arbitrary choices
When I wrote about why ContextOS exists, the core of it was a correction I had to make about my own career. For years I said “if you’ve seen one infrastructure, you’ve seen one infrastructure.” I was wrong. Something like 98% of infrastructures have nearly identical goals.
I’ll take that as read here, because I want to follow through on a consequence I left on the table at the time.
If the goals really are nearly identical, then most of the institutional knowledge we just finished mourning was not deep architectural wisdom. Somebody picked a subnet range. Somebody set a connection pool size. Somebody decided this service gets its own database and that one shares. Each of those was a real judgment made by a competent person under time pressure, and almost none of them were interesting. They mattered only in the sense that getting them wrong hurt.
They had to be made because the platform wouldn’t make them. And they went unrecorded because at the time they didn’t feel like decisions at all.
That reframes the memory problem, and more hopefully than it first looks. The answer isn’t to build a better archive of every choice your engineers ever made. It’s to stop generating choices that shouldn’t have to be made. You don’t need a system of record for a decision that never had to exist.
This is why the pilots die
You’ve probably seen the number claiming 95% of enterprise AI projects fail. I’d leave it alone. It comes from a non-peer-reviewed working paper built on 52 executive interviews recruited at conferences, and its own underlying data shows that the bulk of that 95% never ran a custom pilot at all - the figure counts not-attempting as failing. It moved markets anyway, which tells you something about how badly people wanted a number.
The properly sourced picture is less dramatic and more damning.
BCG surveyed more than 1,250 senior executives across 68 countries and found 5% achieving AI value at scale - and fully 60% achieving no material value at all. McKinsey’s 2025 survey, nearly 2,000 respondents across 105 countries, found only 39% reporting any EBIT impact from AI at the enterprise level, and most of those attributing less than 5% of EBIT to it; nearly two-thirds said their organizations had not yet begun scaling AI across the enterprise. IDC found that just 9% of EMEA organizations had delivered measurable business outcomes from most of their AI projects over the previous two years, and its maturity benchmark of 583 organizations put 63% in the two lowest maturity stages - running pilots without the repeatability needed to scale.
Whichever study you trust, the diagnosis that follows is almost always the same: blame the model. Try a different one. Tune the prompts. Wait for the next release.
Wrong layer.
I watched a generation build infrastructure as code, then bolt Kubernetes and Terraform on top like duct tape on a submarine. The same pattern is running again with AI. Teams prototype on sand - no deployment flexibility, no data gravity, no ops muscle to run what engineering ships - and then act surprised when the prototype won’t survive contact with production.
There’s now careful economic work showing exactly where the leak is. Researchers with access to usage telemetry across more than a hundred thousand developers measured what successive generations of AI coding tools actually did to output. Autocomplete raised coding activity by about 40%. Interactive agents, 140%. Autonomous agents, 180%. And then the gains collapsed on the way out the door: 50% more projects, and only 30% more actual releases.
Writing code got dramatically cheaper. Shipping it barely moved. That gap is not a model problem.
Context is an infrastructure problem, not a prompting problem
There’s a version of this argument that gets made about context windows and retrieval, and it stops one layer too early.
The knowledge and context a model runs on dictates how the model will run. Figuring out how to nail that context is a huge issue for companies using AI today. Even with everything from Claude to Qwen available, you still need to properly explain your needs and your guardrails. Many of those things come naturally when you explain something to a person - the innate understanding of how your workloads are structured, what’s allowed to talk to what, which database is the one that actually matters.
Loading that knowledge into models is an infrastructure problem. We need to be able to access and manage knowledge at a larger scale, from an infrastructure access and control perspective. We cannot do it by simply “better prompting.”
Look at what happens when researchers test agents on organizational work rather than puzzles. TheAgentCompany benchmark puts agents inside a simulated software company - browsing, coding, running programs, messaging colleagues - and the best model tested completed 30.3% of tasks autonomously. But the interesting number is the split by category. Software engineering tasks: 37.7%. Administrative tasks: 13.3%. Finance: 8.3%.
Agents do worst on the work a new hire would find easiest. Not because it’s intellectually harder, but because it’s the work that depends on knowing how this particular organization does things - and that knowledge isn’t anywhere the agent can reach.
Google’s 2025 DORA research, across roughly five thousand technology professionals, lands in the same place from the delivery side. Its central finding is that AI functions as a mirror and an amplifier: it doesn’t fix a team, it magnifies what’s already there. AI adoption now correlates positively with throughput but still negatively with delivery stability. And two of the seven capabilities in DORA’s AI model are, in effect, this blog’s thesis: connect AI to your internal context, and invest in your internal platform.
That’s the metadata audit arriving from the other direction. A company that can’t count its own running APIs cannot hand an agent a reliable picture of its environment, no matter how good the model is or how carefully the prompt is written. The prompt is downstream of a problem the prompt can’t reach.
What fixing the foundation actually means
If the reasoning behind your infrastructure exists only in people’s heads, then every automation built on top of it - including every agent - is operating on a partial picture and guessing at the rest.
The fix isn’t a documentation project. Documentation decays at exactly the rate that makes it dangerous: current enough to be trusted, stale enough to be wrong. The fix is infrastructure that knows what it’s running and why, because the platform is what provisioned it. What exists. What it’s permitted to reach. What was approved, and what’s an exception. Not written down alongside the system - a property of the system.
That’s a large part of the bet behind ContextOS. When the platform provisions the database, the network, the scaling policy, and the security boundary, it also holds the answer to why each of those looks the way it does - and that answer is available to a person or to an agent without either of them having to reconstruct it from institutional folklore. The goal isn’t to remember better than your engineers did. It’s to remove the category of decision that had to be remembered at all.
Fix the foundation
The model was never the bottleneck. It’s the most visible part of the stack and the easiest thing to swap, which is exactly why it absorbs the blame.
I say this with love: I was a sysadmin. This one’s on us. We built the automation. We never built the memory.
Fix the foundation.
Want to see infrastructure that knows why? Sign up for the ContextOS beta.
Sources
- Cloudflare, API Security and Management Report, January 2024 — 30.7% more API endpoints discovered than customers self-reported, “shadow APIs”
- Postman, 2025 State of the API Report (n=5,700+) — 34% of teams unable to find existing APIs within their own organization
- Teradata / Wakefield Research, Why Agentic AI Stalls, June 30, 2026 (n=1,000 technology leaders) — 43% cite missing metadata, context and relationships; 77% say ≤20% of data and knowledge is reliably AI-ready
- BCG, The Widening AI Value Gap, September 2025 (n=1,250+ executives across 68 countries) — 5% achieving value at scale, 60% achieving no material value
- McKinsey, The State of AI in 2025, November 2025 (n=1,993 across 105 nations) — 39% report any enterprise-level EBIT impact, most attribute under 5%
- IDC, AI in EMEA: Why Most Investments Fail to Deliver Value, April 2026, citing Future Enterprise and Resiliency Survey Wave 1, March 2026 — 9% delivered measurable outcomes from most AI projects over two years; IDC MaturityScape Benchmark: AI-Fueled Organizations in EMEA 2026 (n=583) — 63% in the two lowest maturity stages
- Demirer, Musolff & Yang, Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools, NBER Working Paper 35275, May 2026 — coding activity +40% / +140% / +180%, projects +50%, releases +30%
- Xu, Song, Li et al., TheAgentCompany: Benchmarking LLM Agents on Consequential Real World Tasks, NeurIPS 2025 Datasets & Benchmarks — best model 30.3% autonomous completion; software engineering 37.7%, administrative 13.3%, finance 8.3%
- Google Cloud / DORA, State of AI-assisted Software Development 2025, September 2025 (~5,000 respondents) — AI as mirror and amplifier; throughput up, delivery stability still negatively correlated; “connect AI to your internal context” and “invest in your internal platform” among the seven AI capabilities
- On the disputed 95% figure: MIT NANDA, The GenAI Divide: State of AI in Business 2025 (preliminary, v0.1, July 2025, n=52 interviews plus 153 conference-recruited survey responses); criticism from 80,000 Hours, Futuriom and the Marketing AI Institute