Engineering · July 11, 2026 · 7 min read

Context engineering for multi-agent systems

For a single agent, context engineering is curation: pick the right tokens, order them, fit the budget. Add a second agent and the inputs are being written by someone else, asynchronously — and the craft turns into a coordination problem.

What context engineering is

Context engineering is the discipline of deciding what actually goes into the model's window on any given call: which retrieved documents, how much history, in what order, compressed how far, within what token budget. It's the recognition that a model is only as good as the context it's handed — so assembling that context well is its own craft, distinct from prompting or fine-tuning.

For a single agent, the craft is tractable because you own the whole pipeline. One agent, one loop, one prompt you can hand-tune: retrieve the top matches, drop the stale bits, order by relevance, leave headroom for the answer. Done.

Where a second agent breaks it

The moment two agents share work, three assumptions behind single-agent context engineering quietly fail.

1. The context isn't yours to curate

Your agent's most important inputs are now produced by other agents, while your agent runs. You can't hand-tune a prompt whose source material is still being written. Context engineering stops being a design-time craft and becomes a runtime negotiation: what has agent A committed, and has it landed yet?

2. Freshness becomes correctness, not polish

For one agent, stale context is suboptimal — a slightly worse answer. Across agents it's a wrong answer: the writer documents v1 because agent A's "moved to v2" write hadn't propagated when the writer's context was assembled. Ordering and reranking don't help; the fact wasn't visible yet. Freshness graduates from a quality knob to a read-your-writes guarantee you either have or don't. (On why scale doesn't paper over this: the fix isn't a bigger model.)

3. Budgets are per-agent and adversarial

Every agent would happily take the entire history. Five agents, five full transcripts — the window can't hold it, and the token bill won't either. Single-agent budgeting optimizes one prompt; team budgeting has to allocate one shared history across many readers, each needing a different, scoped slice. That's not curation anymore. It's scheduling.

Context engineering, reframed as a layer

The way through is to stop asking each agent to engineer its own context and centralize the craft into a shared layer with three moves:

• Write. Agents emit what they learn as events. They don't assemble prompts for each other; they append to a common log.
• Consolidate. The ordering, deduplication, and conflict resolution each agent used to do by hand happens once, centrally, at write time — producing versioned, conflict-resolved facts instead of N private interpretations.
• Pack. Each agent requests a budget-fit, scoped, provenance-tagged context block, with a freshness guarantee attached.

Concretely, "engineer the context" becomes "request a pack":

const pack = await lore.pack({
  query: "current state of auth work",
  scopes: { team: "platform" },   // scope: only what this agent may see
  minSeq: writeSeq,               // freshness: read-your-writes
  tokenBudget: 2000,              // budget: fit the window
});

pack.coveredSeq   // ≥ minSeq → the write is in there, guaranteed
pack.savedTokens  // budgeting, as a number you can report

The scoping, budgeting, ordering, and freshness — the whole of context engineering — moves from something each agent re-improvises into a service every agent calls with the same guarantees.

Which tactics carry over, and which don't

• Carry over: token budgeting, compression, relevance ordering, and provenance are all still essential — they just move into the layer and run once instead of per-agent.
• Breaks: "stuff the whole transcript in" — already a losing move for one agent, actively harmful across many (see why a bigger window doesn't fix it).
• Insufficient: "rerank at read time." Ranking assumes the fact is present to be ranked. Across agents you first need a guarantee it's there — visibility before relevance.

Determinism is the multiplier

There's a payoff the single-agent framing misses. If the packs are deterministic — the same inputs always produce the same context block, byte for byte — then prompt-cache hits compound across every agent and every turn. Context engineering for a team isn't only about correctness; done right, it's the reason the token bill goes down instead of up as you add agents.

The one-line version

For one agent, context engineering is curation. For a team, it's a distributed-systems problem — and the winning move is to engineer the context once, centrally, with guarantees, instead of asking every agent to reinvent it against inputs it can't see.

This is how Lore, an open-source coordination memory layer, approaches context for agent teams. See the write → consolidate → pack loop, or the repo on GitHub.