Context patterns for agents

An agent can only reason over what reaches its context. Context is the material placed in front of the model while it works on a task. A context pattern is a tested way to choose and shape that material. We ran our own experiments to get this right for our own agents. Each test compared an idea with a plain alternative on public document collections. Nine patterns came out of that work. Patterns one to three give most of the value, and you can adopt them on their own. The rest help only under narrower conditions.

These patterns sit inside knowledge and memory, the part of an agent platform that decides what agents know. The agent data engineering layer (R14) puts them into practice. It works on documents held in the data platform layer (R02). The data-to-memory pipeline shows the stages they touch. For the wider picture, see step 2 of the intelligence ladder: context. A coordination platform does not supply these patterns, as the Agentic OS page explains.

The nine patterns

Where a pattern is marked measured, we ran it. That means five rounds on public collections, with human relevance judgements where they exist. Every run was seeded and can be reproduced. Where a pattern is marked published work, the evidence is someone else's, and it is cited. The reading list has about thirty-five papers and what each shows.

These pages report our own experiments. Read each comparison with its data, its baseline and its limits. Nobody else has repeated them yet. What changed our advice shows where the results narrowed what we recommend.

---

1. Give a document several vectors

One vector per document averages everything the document says. Several vectors give a question something specific to match.

A vector is a list of numbers that stands for the meaning of a text. An encoder is the model that makes it. A pooled vectorPooled (single-vector) embedding. One numeric fingerprint for a whole document. Cheap and standard, but for a document about several things it is an average of all of them, so it matches each of them weakly. for a document about several topicsAspect (of a document). One of the distinct things a document is about. An email that confirms a delivery date, flags a billing error, and asks for a contract change has three aspects; a question usually targets one of them. is roughly the average of those topics. So a question about one of them matches weakly. Splitting the document restores the signal. A card is one searchable piece of a document, with its own vector.

We built a test collection where documents grow from one topic to ten. On it, the pooled index fell from 0.815 to 0.294. The score is nDCG@10nDCG@10. A 0 to 1 score of how good the first ten search results are. It rewards putting the right documents near the top and counts every relevant document the judges marked. A difference of 0.03 is small but real on a few hundred queries; 0.2 is large., a 0 to 1 measure of the top ten results. Any multi-vector design held above 0.63. On LIMIT, a public test built to break one-vector search, the pooled vector scored 0.314. Cards with one vector per attribute scored 0.988.

Apply it when items cover several topics. Examples are emails that carry a request and a complaint, and tickets with a symptom and a workaround. Contracts with obligations and termination terms are another. So is a utility work order that records a fault, the parts used and a safety note.

Do not bother when items are short and about one thing. There is nothing to dilute.

The limit behind this is a mathematical proof, not just an observation. For a vector of fixed size, some result sets are out of reach of any one-vector index. The proof is in Weller et al., arXiv:2508.21038, 2025. See the measurement.

2. Make every design beat plain chunks of the same count

Most of the multi-vector gain comes from having more pieces. So compare any clever design with the same number of plain chunks before believing it.

Splitting by purpose and splitting into fixed windows both add vectors. On LIMIT, a three-word window that ignores meaning recovered 0.610 of the 0.674 that purpose cards gained. So most of the benefit was piece count, not cleverness. On scientific abstracts judged by people, purpose cards scored 0.032 to 0.042 below matched chunks. The questions there concerned whole findings, not one topic.

The rule: start with plain chunks at the same count. Adopt purpose cards only where they beat those chunks on your own questions. Where questions do target one topic, the gain is real. It was +0.188 at ten topics per document, with a quarter fewer vectors.

Apply it to every design choice, not only this one. A control that is not matched measures the handicap, not the idea. See where cards win and lose.

3. Keep keyword search

Meaning-based search misses exact names, codes and quotations. Adding keyword search is cheap and removes a silent failure.

On LIMIT, where queries name a specific attribute, keyword search (BM25BM25 (keyword search). The classic keyword ranking formula behind most search engines. It matches exact words, so it wins on names, codes, and quotations, where meaning-based search is weak.) scored 0.997. The pooled vector scored 0.314. On SciFact, abstracts full of gene names and measured quantities, cards fused with BM25 gave the best result at 0.685. Fusing merges the two ranked lists by rank, using reciprocal rank fusion. It is cheap, and the result does not depend on which list comes first.

Use it by default unless your own tests show no benefit. Exact names, IDs and quotations are common. Meaning-only search can return something plausible instead of the record you named. An asset ID on a utility network is a typical case.

4. Build card types from the documents, not the goal

Show the designer a sample of the documents, not a statement of your goal.

A card type is one kind of card, such as fault logs or contracts. A model can design the card types well. What you show it decides whether it helps. Showing it a sample of the documents, spread across topics, was worth +0.224 over generic card types. Adding the research goal cost 0.068. Adding business context cost 0.047. Adding schema metadata as well brought the total cost to 0.068. The harm grew with the amount of context supplied. On real news collections judged by people, goal-picked card types were the worst of five setups. They scored about 0.06 below card types built from the documents.

The card types themselves show why. From the documents, the designer produced six types that followed the data. Given the business story, it produced four tidy types organised around the business. Those covered the documents less well.

Apply it when you design any set of card types, facets or labels over a collection. See the five rounds behind this.

5. Apply the instruction at question time, not in the index

When the goal really changes what is relevant, use a retriever trained to follow instructions. Do not rebuild the index.

Pattern 4 keeps the goal out of the index design. The goal still matters, because one document can be relevant to one request and not another. The established place for it is the question side. Some retrievers are trained so that a stated instruction changes their ranking. Examples are INSTRUCTOR (ACL Findings 2023), FollowIR (EMNLP 2024) and Promptriever (ICLR 2025). Recent work reshapes the vectors per instruction without re-encoding the documents (GSTransform, 2025).

Our own results support this split. Re-picking card types per instruction did not follow the instruction at all. Its instruction-following score, p-MRRp-MRR (instruction following score). A FollowIR benchmark score of whether a search system changes its ranking the right way when the instruction changes. Zero means the system ignores the instruction., was about zero. Even an untrained encoder with the instruction added to the query was the best setup on one collection.

Apply it when one collection serves requests whose relevance really differs. Keep it out of the indexing step.

6. Let the model design, and cheap tools do the bulk work

Spend the model on designing the topic list and naming the topics. Let vectors, clustering and ranking touch every document.

Tie model cost to the number of topics found, not the number of documents. That is about two hundred times cheaper at similar topic detail. Treat it as a constant factor, not a saving that grows with size. At a fixed useful level of detail, the advantage shrinks as the collection grows. We once claimed it widened. That came from clusters getting coarser as the collection grew.

Published work agrees from several directions.

• A model-designed topic list plus small classifiers matched a frontier model used directly as the classifier (TnT-LLM, KDD 2024).
• A vector shortlist plus a small model cost about one hundredth per document, with higher accuracy (Databricks, Jul 2026 [vendor]).
• Models that write extraction code from a sample cut token cost by two orders of magnitude (EVAPORATE, VLDB 2023).

Apply it when the collection is bigger than your budget for reading it. Use established topic-modelling tools rather than a home-made version. See the measured bill.

7. Use a cheap filter to set material aside, not to save money

A cheap first pass is worth building. It is not where the money is saved.

A filter built on vectors separated on-purpose from off-purpose material at ROC-AUC 0.933. It scores each item against a few anchor phrases, short descriptions of the purpose. ROC-AUC is a 0 to 1 score where 0.5 is a coin toss. But at the recall a production filter must hold, it discarded only a third of the documents. Recall is the share of relevant items the filter keeps. At 0.99 recall it discarded an eighth. That is a saving factor of one to two, paid for with recall. The large saving comes from pattern 6, not from the filter.

Two refinements came from null controls, versions built so they should not work. Fitting the anchor weights was worth only 0.002 over equal weights. Where a labelled sample exists, plain logistic regression on the same vectors reached 0.995. If you can label a few thousand items, train a classifier instead of tuning anchors.

Apply it with a recall target. Set material aside rather than deleting it.

8. Choose varied results inside a filtered pool

Coverage is worth buying when a question has several answers. Buy it inside a pool already filtered for relevance.

Within a filtered pool, we kept the most relevant results and filled the rest with the least similar ones. We call this the harvest. It bought sub-topic coverage about twice as cheaply as maximal marginal relevance (MMR), the standard rule. The harvest gained +0.315 coverage for 0.046 relevance. MMR gained +0.314 for 0.098. The harvest also let in fewer answerless documents than MMR or a determinantal point process (DPP). It reduced unsupported content in generated summaries by 0.067. We did not predict that, and it needed no judge to measure.

Apply it when the question needs coverage and has several answers. Variety adds nothing to single-answer lookups. Answerless passages close to the topic are the most damaging thing you can add (the Distracting Effect, ACL 2025). That is why the pool is filtered first and the distractor rate is measured.

Do not tune the amount of variety to who reads the results. We tested that, and the effect vanished under a judge from a different company. See the measured trade-off.

9. Measure against a matched control

This pattern makes the other eight true for your documents, not just ours.

Use nDCG@10 with paired tests for relevance. A paired test compares setups question by question. Use coverage scores for coverage, because plain recall cannot see variety. Fix the decision rules before reading any number. Require a headline result to hold across random seeds and machines. Report every setup, including those that beat your method.

We learned this the hard way. Five of our headline results reversed at least once. Every reversal traced to one of two causes. A control did not get the same budget, or a measurement could not come out negative. How to test a context design has the checks and the reversals behind them.

---

The nine patterns as one pipeline

Put together, the patterns make one design.

1. Parse and chunk per collection. Test the chunking on that collection's own questions, as the data-to-memory pipeline requires.
2. Embed once. Version the vectors. Cache them by content and by device.
3. Index three ways. Use keyword search and chunk vectors. Add purpose cards only where pattern 2's test shows a win.
4. Filter by recall into one pool per purpose. Train a classifier as soon as a labelled sample exists.
5. Find topics once, with no seeding. A model names and merges them from keyword lists.
6. Search by question type. Use keyword plus meaning search for names and IDs. Use meaning search for open questions. Use an instruction-following retriever where the stated goal changes relevance.
7. Select inside the filtered pool with the variety rule your coverage score favours. Guard against distractors.
8. Assign new documents to existing topics. Find topics again only for what does not fit.
9. Evaluate all the time against a matched control on your own questions. Retire what stops winning.

What is still open

These nine patterns cover search over text only. The open questions, including other kinds of data and agent loops, are on questions to investigate.

Evidence and limits

The encoders were small. The collections ran to twenty thousand documents. Everything was in English, and no production data was used. Prices are as of 2026-08-19, and local compute is priced at zero.

A larger instruction-tuned encoder would strengthen pattern 5, not weaken it. The next test that matters most is a real collection with single-topic questions judged by people. It would test pattern 1's one positive finding outside synthetic data.

Next step

Start with one vector blurs a document about many topics, the evidence for pattern 1. Or see what we got wrong.

Explore this topic

• The experiment pages linked from each pattern, and the reading list.
• The agent data engineering layer (R14) and the data-to-memory pipeline, where these patterns sit in the architecture.
• The decision on purpose cards and chunks records the decision.
• The experiments ran in August 2026. Prices are as of 2026-08-19.