A developer builds a client intake workflow using an AI agent. The brief is clear. The agent produces clean code. Then it starts making decisions about error handling, field validation, and edge cases, and most of those decisions are wrong. Not technically wrong. Wrong for this client, this system, this codebase with its particular quirks and constraints. The agent had no way to know the difference.
This is the memory wall. It is not a model capability problem. It is a context gap. The agent is working from general knowledge. The developer has specific knowledge, built from months of actual work, that was never written down and never passed in.
The Problem Isn't What Agents Can't Do
Researchers at METR and others studying real-world agentic performance have documented failure rates above 90% on practical, multi-step tasks. The number that appears most in applied research is 97.5% on authentic freelance project briefs. That is not a hallucination rate. It is not a code-quality rate. It is the rate at which agents reach a decision point they cannot resolve because they lack the working context of the person who owns the project.
The agents can write code, generate copy, structure workflows, and call APIs. What they cannot do is know what you know from three years of building in a particular domain, with a particular client, against a particular set of constraints no one ever documented because everyone who needed to know them already knew them.
That gap is the memory wall.
What Lives on the Other Side of the Wall
Institutional context is not documentation. It is the judgment layer beneath documentation. It includes things like: which requirements are real and which are aspirational, which clients change their minds late in projects, which integrations are officially supported but practically unreliable, which technical decisions are settled and which are still up for debate among the team.
Senior engineers and experienced operators carry this constantly. It is not explicit. It is embedded in how they review code, how they scope work, what they push back on, and what they let go. When someone says a colleague "has good judgment," they almost always mean that person has internalized a dense, accurate model of the system they work in.
This is exactly what agents lack. They have broad capabilities and narrow context. The capability side is expanding fast. The context side does not improve automatically with model size. It requires active work from the operator.
How Contextual Stewardship Works
Contextual stewardship is the practice of encoding institutional judgment in ways agents can use. It has two parts: the mental model, and the evaluation layer.
The mental model is the operator's internal map of the system. It covers what the system is trying to do, what constraints are non-negotiable, what patterns recur, and where the system breaks down under pressure. Most operators have this model. Almost none have externalized it in a form that agents can consume.
The evaluation layer is where that model becomes operational. Automated evaluations are tests that encode specific judgment calls rather than generic correctness criteria. Instead of checking whether output compiles, they check whether output matches the decisions this system makes in this context. An evaluation might verify that the agent respects a particular rate-limiting pattern, uses a specific error taxonomy, or stays within a defined set of approved dependencies. These are not generic best practices. They are encoded context.
Building these evaluations is the work of contextual stewardship. It requires the operator to surface the judgment they apply implicitly and convert it into explicit, testable criteria. That is hard. It is also the only way to scale agentic work beyond low-stakes, low-specificity tasks.
The Tradeoffs at Each Level
There are three approaches to the context gap, and each has real costs.
Rely on general model knowledge. The agent operates with whatever context the model brings from training plus whatever you include in the prompt. Fast to start, produces reasonable output on generic tasks. Breaks down the moment the task requires system-specific knowledge. Works for throwaway scripts and boilerplate generation. Does not work for anything with real production stakes.
Document context manually and pass it in. Write the institutional knowledge down and provide it as context each session. This helps significantly and is the right baseline for any serious agentic workflow. The cost is the maintenance burden. Context documents go stale. The system changes, the document does not, and the agent learns the wrong thing. Someone has to own the context documents and keep them current. Most teams do not account for this as ongoing work.
Build automated evaluations that encode judgment. This is the highest investment and the highest return. Once an evaluation suite captures the critical judgment calls in a system, it becomes portable. New agents can be tested against it. New operators can learn from it. The evaluation becomes the institutional memory rather than any individual person's head. The cost is the upfront design work, which requires a senior operator who knows the system well enough to externalize the non-obvious criteria.
None of these eliminates the memory wall entirely. The third approach shrinks it the most, but it requires someone who can do the design work, and that is exactly the senior skill this moment demands.
Seniority Looks Different Now
The definition of seniority in technical work is shifting. It used to mean: knows the most, writes the fastest, debugs the hardest problems. That still matters. But the operators who get the most leverage from agentic systems are not the ones who write the most code. They are the ones who build the feedback loops that make agents reliable.
Two things follow from this. First, the ability to externalize judgment, to take the implicit model of a system and convert it into explicit, testable criteria, is now a core technical skill, not a documentation nicety. Second, the ability to design evaluations, not just review agent output manually, is what separates an operator who can scale from one who stays bottlenecked.
A senior operator reviewing agent output manually is doing triage. A senior operator building evaluation harnesses is building leverage. The first is a cost. The second compounds.
Where to Start
If you are running agentic workflows now without an evaluation layer, start with the three or four judgment calls you make most often when reviewing agent output. Not the generic checks. The specific ones. "This agent always tries to use library X but we use library Y in this codebase." "This agent writes error messages in the wrong format for our logging system." "This agent scopes tasks too broadly and needs to stop at the boundary we've defined."
Write those down as testable assertions. Run your next batch of agent output against them. Refine from there.
You are not building a test suite. You are externalizing the part of your judgment that matters most in this system. Once it is external, it is no longer trapped in your head. Agents can use it. Other operators can use it. You can iterate on it instead of re-applying it manually every session.
Contextual stewardship is not a framework. It is a practice. Start narrow, stay specific, and build toward the evaluation layer that makes your agents reliable in the system you are running.