I02 · Context systems · 7 min read
Context is a runtime system
Prompt craft still matters. Production reliability now depends on the full state made visible, trusted, current, and actionable at each decision.
By AISDLC Editorial · Published 2026-08-08 · Reviewed 2026-08-09
A production agent does not act on a prompt alone. It acts on instructions, retrieved knowledge, tool descriptions, files, memory, conversation history, environment state, examples, and the residue of prior actions. Together these inputs form a runtime system. They determine what the model believes is relevant, what it treats as authoritative, and what actions appear possible.
From prompt writing to context assembly
A prompt is authored text. A context system is a decision about inclusion. It decides which policies outrank user content, which repository files are relevant, which memory is fresh enough to reuse, which tools are exposed, and how much history remains visible. Those decisions can change behavior without changing a single word in the user’s request.
That makes context assembly an architectural and security boundary. Retrieved text may contain instructions that conflict with policy. Memory may preserve a once-correct conclusion after the environment has changed. Tool descriptions may imply authority that the caller does not possess. A context pipeline must therefore do more than retrieve: it must classify, attribute, prioritize, redact, expire, and test.
A governed context assembly loop
- 01 · Declare Bind the run to a versioned objective, risk tier, data boundary, and context policy.
- 02 · Resolve Select the smallest sufficient instructions, knowledge, tools, state, and examples.
- 03 · Validate Check provenance, freshness, permissions, conflicts, injection risk, and budget.
- 04 · Manifest Record what entered context, what was excluded, and which version was used.
- 05 · Evaluate Test whether context leads to correct decisions and resists known poisoning patterns.
Memory is infrastructure, not truth
Durable memory is essential for work that spans sessions, agents, or model changes. It carries decisions, progress, failures, and operating state forward. Yet persistence creates a new failure mode: a corrupted or stale item can influence many future runs long after its origin has disappeared from view.
The minimum context manifest
- Identity
- Which agent, delegator, and accountable owner initiated the run.
- Composition
- Instruction, policy, retrieval, memory, tool, example, and environment versions.
- Provenance
- Origin, trust class, permissions, freshness, and integrity status for included state.
- Disposition
- What was used, rejected, compacted, superseded, or written back to durable memory.
Context quality must be testable
Teams commonly test model outputs while leaving retrieval and context assembly untested. That misses the mechanism that supplied the model’s evidence and action surface. A context evaluation should test both inclusion and exclusion: whether required policy and domain facts appear, whether irrelevant or unauthorized material stays out, and whether conflicting instructions are resolved in the intended order.
Context-system release evidence
- Versioned context policy and precedence rules
- Context manifest for representative runs
- Retrieval relevance and freshness evaluation
- Injection and memory-poisoning challenge set
- Redaction and data-boundary results
- Compaction and cross-session handoff tests
Primary sources
AISDLC Insights publishes source-informed editorial synthesis and implementation positions. It is reference material, not a standard, certification, legal opinion, or authorization to deploy an agent.