CAFE(S) and the Context You Can't Write Down

A group of researchers (including Nicole Forsgren, co-creator of DORA) recently published CAFE(S), a framework for judging the context you hand an agent. It’s widely accepted at this point that an agent is only as good as its context, and what the paper adds is a vocabulary for what good context looks like: clarity, actionability, fidelity, efficiency, and (set slightly apart) security.

The paper defines context broadly, including tool output and retrieved data. But when it gets to fixing context, every fix is about maintaining documents: give each one an owner, review it on a schedule, and treat changes to shared context the way you treat changes to code. That works for a lot of what an agent needs, but not for all of it.

Two kinds of context #

Some things only people know: what the task is for, which constraints matter and why, what finished looks like, which tradeoff the organization already made last quarter. None of that exists anywhere until it’s written down, and CAFE(S) is a good checklist for ensuring someone actually writes it.

Other things the system knows: what a service returns, what the messages on the queue look like, what the staging schema is today, how the service behaves when a dependency slows down. These can be written down, and often are, in AGENTS.md files, READMEs and docs. But each one then becomes a document someone has to own and review on a schedule, describing something the agent could have observed directly if it could reach the live system.

Fidelity has a ceiling #

Fidelity - whether the context is accurate - is where the difference between the two kinds matters most. The paper’s answer is to keep documents current: designate source-of-truth documents, give them owners, and review them regularly. All of that assumes the accurate version can be written down in the first place.

Sometimes it can’t, because the behavior only exists when the pieces run together. A client that reuses connections and a server that closes idle ones after five seconds, each documented correctly in its own repository, produce failures that neither document mentions. A query that returns instantly on a developer’s dataset takes seconds on staging’s. Retries that are reasonable in each service multiply the load on a shared dependency once they stack. Nobody knows to write these down until something breaks.

And the things that can be written down, like response formats, queue payloads and schemas, keep changing. Each change is another document someone has to remember to update, and until they do, the agent is working from a description of a system that no longer exists.

The paper names its hardest precondition plainly: “No amount of context engineering can retrieve what was never captured.” I can see how that holds true for intent, because if nobody wrote down why a decision was made, no tool will recover it. On the other hand, a system behavior never needs to be captured, since the agent can observe it directly.

Efficiency and actionability #

The paper defines efficiency as getting the most signal out of the fewest tokens. If an agent needs to know what a service returns and can’t call it, it has to work it out from the code: the route handler and everything that builds the response. That’s several files to locate and read to arrive at a result, instead of one request to the live service.

Actionability is whether the agent knows what to do and how to tell when it’s done. The paper lists three ways this fails: the agent never starts, never stops, or stops in the wrong place, which it calls “the most expensive, because the work looks like progress.” A definition of done that the agent can only check against mocks of the real services has a high chance of producing the third one. The tests pass, the agent stops, and the code still hasn’t met the services it depends on. We wrote more about this in our response to Anthropic’s AI-native SDLC playbook.

Putting CAFE(S) to work #

If you want to apply CAFE(S) to your own agents, a good first step is to go through your AGENTS.md and sort each line into one of two piles: something a person decided, or something the running system could tell the agent if it could reach it. Keep the first pile and hold it to the paper’s standards. For the second, delete the line and let the agent check the system instead.

That second part is what we build mirrord for. It lets the code an agent is working on run against the real services in your staging cluster, so the agent can see what they return and how they behave instead of reading a description. mirrord is open source, and the docs are the place to start.