How it works
Context assembly turns the harness's available information into the bounded input for one model invocation. It is a runtime operation, not a one-time prompt-writing exercise. The correct context depends on the current step, authoritative workflow state, permitted tools, and the decision the model must make next.
A typical assembly path is:
- Identify the step's objective and output contract.
- Load authoritative state, such as the current task, checkpoint, or approved plan.
- Retrieve relevant evidence, prior results, and operator instructions.
- Filter material by relevance, freshness, provenance, and permission scope.
- Render tool descriptions, policies, and evidence into clearly separated sections.
- Fit the result within a defined context budget without removing required controls.
- Record what was included, excluded, transformed, or compacted.
Ordering matters because instructions, evidence, and historical messages play different roles. Untrusted retrieved text should not look like harness policy. Old conclusions should not override current state. Tool output should retain enough attribution for the model and operator to distinguish observation from inference.
The resulting context should be treated as an assembly artifact. If the harness cannot explain which inputs produced a consequential action, debugging becomes guesswork.
Why it matters in an agent harness
Model behavior depends on more than the model and its top-level instructions. The harness determines what the model can see at each decision point. Context assembly is therefore part of the control surface.
Good assembly improves control by giving the model the current objective, explicit boundaries, and only the tools relevant to the step. It reduces accidental authority expansion. A model asked to summarize evidence does not need deployment credentials, broad write tools, or unrelated operator notes in its context. Context does not grant permission by itself, but exposed secrets, misleading tool descriptions, and authority-shaped instructions can still influence unsafe actions.
Assembly also affects observability. A transcript may show what the model said without showing why it said it. For consequential calls, the trace should identify the state version, retrieved sources, tool definitions, policies, and transformations supplied to the model. That record lets an operator separate a reasoning failure from a retrieval failure, stale state, missing instruction, or malformed tool surface.
Reversibility and evaluation depend on the same record. Replaying only the visible conversation is insufficient when hidden state, retrieval results, or generated summaries affected the call. Exact replay may still be limited by model non-determinism, but preserving the assembled input makes comparisons defensible. It also supports regression checks: you can test whether a harness change drops required policy, promotes untrusted text, or overloads the model with irrelevant history.
Context assembly has a failure-containment role as well. Step-specific context limits how far corrupted evidence, prompt injection, or an obsolete decision can propagate. The boundary is imperfect, but it is stronger than repeatedly forwarding the entire session.
Context assembly vs context propagation
These mechanisms are related, but they answer different engineering questions.
| Mechanism | Primary question | Main risk |
|---|---|---|
| Context assembly | What should this model call receive now? | Missing, excessive, stale, or badly labeled input |
| Context propagation | What information should move between steps, agents, or sessions? | Corruption or authority spreading across boundaries |
Propagation supplies candidate information to a later boundary. Assembly decides whether and how that information enters a specific invocation. A worker result may be propagated to an orchestrator, for example, while the assembler includes only its verified findings and provenance rather than the worker's full transcript. Keeping the decisions separate makes filtering, permissions, and attribution easier to enforce.
The Rifty take
We treat context assembly as executable control logic, not prompt decoration. We optimize for the smallest context that preserves the task contract, authoritative state, evidence, and safety boundaries, accepting some assembly complexity in exchange for clearer failures. If an input can change an action, the harness should be able to show where it came from and why it was included.
Implementation checks
- Define required and optional context inputs for every model-call type.
- Read workflow state from an authoritative store, not from the transcript alone.
- Separate harness instructions, operator direction, evidence, and untrusted content.
- Attach provenance and freshness information to retrieved material.
- Exclude tools and credentials outside the current permission scope.
- Set explicit budgets for history, retrieval, tool descriptions, and generated summaries.
- Record compaction, truncation, filtering, and fallback decisions visibly.
- Trace the assembled input or a stable reference to it for consequential calls.
- Test missing state, stale evidence, prompt injection, and oversized-context cases.
Frequently asked questions
Should an agent receive its entire conversation history at every step?
Usually no. Assemble the history needed for the current decision, plus authoritative state and any required audit references. Forwarding everything increases context load and lets stale conclusions or injected instructions persist. Preserve the full transcript separately when needed for inspection, but do not confuse storage with model input.
Is context assembly the same as prompt engineering?
No. Prompt engineering shapes instructions and examples, while context assembly selects the complete runtime input for a particular call. That input can include prompts, workflow state, retrieved evidence, tool descriptions, prior results, and policies. Prompt design is one component of the broader assembly mechanism.
How should a harness handle context that exceeds the model budget?
Apply an explicit, recorded reduction policy. Preserve the task contract, current authoritative state, safety controls, and evidence required for the decision before compressing history or optional background. If required material still cannot fit, fail or split the step visibly instead of silently truncating critical context.
What should be logged about assembled context?
Log enough to reconstruct the input boundary: the state version, source identifiers, tool definitions, policy versions, ordering, and any filtering, transformation, compaction, or truncation. Sensitive values may require protected storage or references, but their omission from ordinary logs should not erase the fact that they were supplied.