Context

Description

Context is everything an agent knows at the moment it acts. Unlike a human who accumulates background knowledge passively over years, an agent has no persistent world model between invocations. Every piece of information it needs: project state, task history, conventions, constraints must be explicitly present in its context window at the time of execution. Context is therefore not a convenience; it is the substrate on which reliable reasoning is possible.

The quality of an agent’s output is bounded by the quality of its context. A well-designed system spends as much effort on context as it does on prompting or model selection.

Types of Context

Context can be organized by its scope and source. Three layers are useful as a starting taxonomy:

Local context is the immediate environment of a specific task or execution: the file being modified, the ticket being worked, the current conversation, the outputs of prior steps in the same run. Local context is ephemeral it is assembled fresh for each invocation and discarded afterward.

User context is the accumulated knowledge about the people, teams, or roles interacting with the system: preferences, past decisions, recurring patterns, working styles, and accumulated feedback from prior interactions. User context persists across sessions and should evolve as behavior and preferences are observed.

System context is the stable, shared knowledge base of the project or organization: architecture decisions, coding conventions, service boundaries, domain vocabulary, access rules, and governance policy. System context changes slowly and deliberately. It is authoritative rather than inferential.

These three layers do not compete they compose. A well-formed agent invocation draws selectively from all three.

For a multi-agent system where tasks are dispatched to agents with different existing context states, a more granular scope model is needed. Context Layers expands this into five scopes world, organisation, project, repository, and task and defines how the Orchestrator resolves context gaps at dispatch time.

The Density Constraint

Every model has a finite context window. Every token in that window is a cost against both budget and attention. Poorly curated context creates two related failure modes:

1. Dilution the signal that matters is buried in noise. Redundant, verbose, or loosely relevant material competes with the critical information the model needs to act correctly. Models cannot always identify which parts of a long context are load-bearing.

2. Overflow when context exceeds the window, the system must either truncate or summarize. Both operations are lossy. Important information may be dropped, and the agent has no way to signal that it is operating on an incomplete picture.

Good context is therefore dense context. The goal is maximum relevant information per token, not maximum information overall. This means every piece of context should earn its place: would removing this change the quality of the output? If not, remove it.

This constraint has a runtime dimension the rest of this page does not cover. The density problem is not only about authoring good context it is about keeping the live context window healthy while an agent executes, across horizons that exceed a single window. The advertised window is not a usable working set: recall degrades as tokens accumulate (“context rot”), so context must be actively offloaded, compacted, and retrieved just-in-time during a run. That runtime discipline is covered in Runtime Context Management; this page covers the authoring side that feeds it.

Hierarchical Structure

Context has natural hierarchy, and respecting that structure reduces redundancy. Consider knowledge organized as a tree: top-level nodes hold stable, broad facts; leaf nodes hold narrow, task-specific detail. When an agent needs a leaf, it should pull that leaf and its direct ancestors not the entire tree.

Flat context dumps pasting entire documents, full file contents, or unfiltered conversation history violate this principle. They include ancestor nodes that are not relevant to the current task, and they mix leaf-level detail from unrelated branches.

A hierarchical setup also makes authorship and maintenance tractable. Facts are written once, at the level of abstraction where they belong, and derived contexts reference them rather than repeating them. Repetition creates drift: when a fact changes, it must be updated in every place it appears, or the system holds contradictory beliefs.

Self-Discovery and Search

Dense, hierarchical context is only useful if agents can find the relevant parts without being handed them explicitly. This requires search: the ability to query the knowledge base at runtime and pull only what is needed.

Search transforms context from a static dump into a dynamic retrieval system. Rather than pre-loading everything, the system exposes knowledge in a way that allows agents to ask specific questions and receive targeted answers. Good search support means:

• Semantic search find knowledge by meaning, not just keyword
• Graph traversal follow relationships between entities to surface dependent or related facts
• Temporal awareness return what is currently true, not what was true at some earlier state

Self-discovery is not just a performance optimization. It is also an architectural principle: if an agent can find what it needs on demand, context becomes composable rather than monolithic. Agents specialize in narrow tasks, pull narrow context, and return narrow outputs. The complexity of the whole system does not collapse into each individual invocation.

For self-discovery to work, knowledge must be exposed in a discoverable form. This means writing context with search in mind clear entity names, consistent vocabulary, explicit relationships not just writing context for human readers.

Evolving Context

A codebase changes. Decisions get revisited. People change roles. Context that was accurate six months ago may now be wrong. Stale context is in some ways worse than no context: the agent acts with false confidence.

Evolving context requires three things:

1. Versioning the system must be able to tell what changed, when, and why, so that agents can reason about recency and apply appropriate trust.
2. Invalidation when a fact changes, the old version must be explicitly superseded, not merely updated in place with no trace of the prior state.
3. Feedback loops the system must observe how context performs in practice (see Context Evaluation) and route degradation signals back into the curation pipeline.

The Context Development Lifecycle formalizes this as a continuous loop: generate, evaluate, distribute, observe.

Curation

Context does not curate itself. Someone or some process must be responsible for deciding what belongs, how it is expressed, and when it is retired.

Curation involves:

• Authoring discipline writing context at the right level of abstraction, avoiding over-specification, and avoiding under-specification
• Deduplication one source of truth per fact; references elsewhere, not copies
• Retirement actively removing context that is no longer true, rather than letting old and new facts coexist
• Evaluation measuring whether context changes improve or degrade agent performance (information density, correctness, verbosity) before promoting them to production

Curation is not a one-time activity. It is a maintenance function as ongoing as code review or documentation upkeep. In a system where context quality directly determines output quality, neglected context accumulates the same kind of debt as neglected code.