Why context beats prompts

The plateau everyone hits

Every company we work with arrives at roughly the same place. The first agent is thrilling. It drafts the RFI response, it reconciles the campaign data, it answers the question nobody had time to answer. Then the second one is harder. The fifth one is a slog. By the tenth, someone senior is quietly asking whether this was worth it.

The instinct at that point is to blame the model, and then to blame the prompt. So the team rewrites the prompt. They add examples. They try a bigger model. The improvement is real and small, and the plateau arrives again two weeks later.

What is actually happening is simpler and less flattering. The agent is not underpowered. It is under-informed, and it is under-informed in a way that no amount of prompt craft can repair, because the information it needs does not exist in a form anything can consume.

What context actually is

Context is not the paragraph you paste above the question. That is framing. Context is the accumulated, specific, frequently contradictory set of facts that makes your company different from the one across the street.

It is the fact that this customer is on the legacy contract. That this product name means something different in the German market. That the approval threshold changed in March and the old number is still in the handbook. That the person who knew why is no longer at the company.

A model with perfect reasoning and no context will confidently produce an answer that is wrong in a way only your team can detect.

Most of this lives in three places: someone's head, a Slack thread nobody can find, and a document that was accurate eighteen months ago. None of those are queryable. All of them are load-bearing.

The versioning problem

Here is where most context projects quietly fail. A team builds a knowledge base, fills it, connects it to the agents, and declares victory. Six months later it is wrong, and worse, nobody can tell which parts are wrong.

The document store has no notion of when a fact became true, who asserted it, what it superseded, or whether anyone still stands behind it. It is a pile, and a pile degrades silently.

Code solved this decades ago. Every change has an author, a timestamp, a reason, and a diff. You can ask what this file looked like in March and get an exact answer. You can see who changed the threshold and read why in the commit message.

There is no principled reason company knowledge should be held to a lower standard than a configuration file, and every practical reason it should be held to a higher one.

Who owns the truth

The uncomfortable organisational question underneath all of this is ownership. When an agent gives a customer the wrong number, who was responsible for the number being right?

In most companies the honest answer is nobody. The number lived in four systems with four owners and no one was accountable for reconciliation. The agent did not create that problem, it just made it visible and fast.

• Unowned facts decay. If no named person is accountable for a fact, assume it is stale.
• Reconciliation is a job, not a project. It does not finish.
• Visibility is the deliverable. Knowing which facts are unowned is more valuable than pretending they are all fine.

What we built instead

We built a context layer that behaves like a repository rather than a pile. Every fact has an author, a history, and a validation state. Changes are proposed, reviewed and merged. Agents read from it the way a service reads from a config store, and when something is wrong you can see exactly when it became wrong and who to ask.

The unglamorous consequence is that the tenth agent is cheaper than the first, because it inherits everything the previous nine established rather than rediscovering it. That inversion is the whole point.

What to do on Monday

If you are at the plateau, resist the urge to rewrite the prompt again. Instead, take the last three agent outputs your team rejected and ask, for each one, what the agent would have needed to know to get it right.

You will find the same six or seven facts. Write them down. Give each one an owner. That list, boring as it looks, is the beginning of your context layer, and it will do more for output quality this quarter than any model upgrade.

Demo page. This post exists to exercise the analytics. Each section above is tagged for attention measurement, the contents list anchors to them, and the button fires a custom cta_contact event. Scroll around, click it, then open the dashboard and filter to this page.