Context Engineering: Beyond Traditional RAG

What is context engineering?

Every agent answers from the context it is given. Context engineering is the work of preparing that context deliberately, instead of hoping that a similarity search returns the right passages.

It covers where information comes from, how long it stays valid, who may read it and how much of it fits in the model's window.

How is it different from traditional RAG?

Traditional RAG is a good answer to a narrow problem: find text related to a question and let the model write from it. Context engineering starts from a different question: what does this agent need to know to do this task safely?

I am not arguing against retrieval. Hybrid search, sensible chunking and reranking remain the foundation, and the DILA work shows how much careful engineering they deserve. The point is that retrieval is necessary but not sufficient once agents act on behalf of people, over documents that change and carry different levels of confidentiality.

The table compares the two on the dimensions that decide whether an agent can be trusted in an organisation.

Why do agents fail even when retrieval works?

In my experience agents rarely fail for lack of a better model. They fail on four situations that similarity search cannot see:

Each of these is a governance problem, not a ranking problem. A better embedding model improves how close a passage is to a question, but it cannot know that a decision was reversed, or that the person asking is an intern. That knowledge lives in the lifecycle of the data and in the access model, so it must be modelled explicitly and applied at assembly time.

• A decision was replaced last month, but the old document is still the closest match.
• Two versions of a specification disagree, and both reach the prompt.
• A constraint, such as an accessibility requirement, sits in a document that was never retrieved.
• The reader is not allowed to see a document, yet it was retrieved because it was relevant.

What does a governed memory item look like?

ORBIT, the platform I built to explore this, treats decisions, needs, constraints, risks and preferences as memory items rather than loose chunks. Each one carries versions and provenance down to the source paragraph.

The lifecycle is what makes memory governable. An item is not simply stored: it is proposed, reviewed and eventually replaced or forgotten.

How is a context assembled for one task?

ORBIT assembles context per task, not per question. Sources are first ingested with personal-data detection and redaction, then indexed for hybrid search. At request time the assembly follows a fixed sequence. I care that it stays explainable: when an agent gives a surprising answer, you can open the context it received and read why each item was in or out, instead of guessing from a similarity score.

• Understand the intent of the task and who is asking.
• Search the memory and the documents, then merge the ranked results.
• Apply freshness, resolve conflicts and remove duplicates.
• Apply permissions and classification, so a reader never receives what they may not see.
• Select within the token budget and compress what remains.
• Return the context with a reason code for every item kept or excluded.

How do you measure context quality?

A context you cannot measure is a context you cannot improve. ORBIT is designed to record latency, tokens, estimated cost, exclusions by reason and the sources that proved most useful, and to export traces for evaluation. Versioned snapshots let several agents share the same context and compare it over time.

ORBIT is a public beta and is not validated for production use. I do not claim measured gains for it. The figures I can stand behind come from the DILA platform, which serves the services of the Prime Minister: the retrieval chain was measured at 0.94 faithfulness, 0.91 answer relevancy, 0.89 context precision and 0.92 context recall, with 85% of priority RAG scenarios covered.

The same pipeline work contributed to a 30% lower cost per AI request, and reusable components cut delivery of a RAG application from 10 weeks to 4. Those results come from engineering the chain around the model, which is the same argument as this article.

Can several agents share the same context, and where does this approach stop?

Versioned snapshots let agents work from the same assembled context and compare it with a later one, so a disagreement between two agents can be traced to a difference in what they were given. Each snapshot states the classification of what it delivers, and ORBIT is reachable through a REST API and an MCP server.

The approach has limits. Governed memory costs review effort, someone must arbitrate contradictions, and extraction by a language model is optional and needs verification. It also reflects my design choices, exercised on a demonstration project rather than in production, which is why I call ORBIT a public beta.

Where should you start?

You do not need a new platform on the first day. The order that has worked for me is to make the problems visible before fixing them.

• List the sources an agent relies on and name an owner for each.
• Add permissions and classification to the retrieval path, not only to the index.
• Track which decisions replace which, even in a simple table.
• Log what was kept and what was excluded for every request.
• Evaluate the retrieval step separately from the generated answer.