In short: An agent is a loop. The engineering that matters has moved from what you ask to what the loop knows when it asks, and the most valuable context almost nobody supplies is prior judgment on comparable cases.
Key points
- Context pipelines index policies, research and filings but rarely index past decisions.
- A precedent slot holds the three to five most comparable prior decisions, each with reason, outcome and any dissent.
- Judge comparability by applicability fields such as segment, stage and jurisdiction, not by text similarity.
- Keep each precedent to a few hundred tokens, summarised from the source record with a link back.
- Guard against anchoring by including a case that went badly and making the loop state how the current case differs.
An agent has been described, memorably, as a for-loop with better PR. The joke carries a design rule. If the loop is a commodity, the work is in what enters it.
Public accounts from teams building on financial data show where that work goes. Workflows that started small grew many times longer. Million-token context windows were tried and found to degrade as documents grew, and to cost too much. PDF parsing was still, in their words, a fight. The lesson every serious team reaches is the same: you cannot pour everything in. You have to choose.
That shift, from prompt engineering to context engineering, has a corollary few teams act on.
Documents tell the loop what is true. Decisions tell it what we do.
Most context pipelines carefully index policies, research, filings, reference data and product documentation. They index decisions not at all. The loop is then asked to reason like a senior analyst while seeing only what a capable new hire would see on day one: the facts, without the house view of what the facts usually mean.
A senior analyst's edge is rarely that they know more facts. It is that they remember the three similar cases, what was decided, what went wrong in one of them, and which signal turned out to matter. That is retrievable, if anyone wrote it down.
Designing a precedent slot
The practical design is a reserved section of every agent's context, a precedent slot, filled before the task runs.
What goes in: the three to five most comparable prior decisions in the same class, each with the decision, the one-sentence reason, the outcome if known, and any recorded dissent.
How comparability is judged: not by text similarity, which matches cases that are described alike, but by applicability fields that describe the situation. Segment, size band, stage, jurisdiction, deal type, the trigger that started the decision. Records need those fields at capture time, or similarity search degrades into keyword matching.
How much budget: small. A few hundred tokens per precedent, summarised from the source record, with a link back. Precedent should be dense, not long.
The failure mode to design against
Precedent creates anchoring. Give a model three prior approvals and it will find reasons to approve. Two guards help.
First, always include outcomes, and deliberately include at least one comparable case that went badly, when one exists. A precedent set made only of successes is a pitch.
Second, instruct the loop to state how the current case differs from each precedent before it uses them. The differences are often where the judgment lies.
In practice
- Pick one agent workflow and add a precedent slot: three comparable prior decisions with outcome and dissent.
- Add four or five applicability fields to the decision records it draws from, so comparability is about situation, not wording.
- Run it side by side with the current version on twenty cases and have the usual reviewer judge which preparation was more useful, blind.
What would prove this wrong. A blind comparison in which adding precedent makes no difference to reviewer-judged quality, or makes it worse through anchoring that the guards do not fix.
Common questions
What is a precedent slot in an AI agent?
A reserved section of an agent's context, filled before the task runs, holding the three to five most comparable prior decisions with the decision, the one-sentence reason, the outcome if known and any recorded dissent.
How do you pick comparable past cases for an AI agent?
Use applicability fields that describe the situation, such as segment, size band, stage, jurisdiction, deal type and the trigger for the decision. Text similarity matches cases described alike, which degrades into keyword matching.
Does giving an AI agent past decisions cause anchoring?
It can: given three prior approvals, a model will find reasons to approve. Include outcomes and at least one comparable case that went badly, and have the loop state how the current case differs from each precedent.
How should I test whether adding precedent helps an agent?
Run the precedent version side by side with the current one on twenty cases and have the usual reviewer judge, blind, which preparation was more useful.