Long-running agents have a context problem that does not disappear when the model’s context window gets larger.
An agent has a conversation history, system instructions, tools, permissions, project state, files, environment data, retrieved documents, and notes from previous work. Those facts have different owners, different refresh rates, and different consequences when they change. Putting all of them into “the chat history” is convenient at first. It is also how a system gradually loses track of what the model was actually told, why it was told it, and whether that information is still current.
Virillio Code Editorial proposes a context epoch: a bounded period during which an agent operates from one explicit baseline of system context, plus chronological updates that become effective at safe points. “Context epoch” is our architectural term, not an established protocol or industry standard.
Context is more than a prompt
Anthropic defines context engineering as the ongoing curation of information that goes into an LLM inference, not merely the wording of a prompt. That distinction matters in long-horizon work: a large context window does not remove the need to select, order, and refresh information deliberately.
Two adjacent patterns inform this proposal without establishing the term itself. LangGraph documents checkpoints for recovery, memory, and human-in-the-loop workflows, and Anthropic’s long-running harness account uses structured artifacts to carry work across sessions. A context epoch is our way of reasoning about which model-visible baseline applies while such durable state evolves.
For an agent runtime, the design problem is therefore not “how do we keep every message?” It is “how do we decide which state belongs in a durable history, which state belongs in the next system baseline, and which state must be re-observed before the next model call?”
A proposed four-part context model
Within the Virillio Code Editorial framework, the following separation can make the model’s view easier to reconstruct. The four parts are design categories, not standardized agent-context planes.
- Plane: Chronological history — What it contains: Durable messages and tool outcomes that happened in sequence — How it changes: Append-only, then compacted — Example: A user request or completed tool result
- Plane: Baseline system context — What it contains: The current, assembled instructions and environment facts — How it changes: Rebuilt only when a new epoch starts — Example: Project instructions, effective capabilities, current date
- Plane: Context snapshot — What it contains: Model-hidden record of what the runtime last admitted — How it changes: Reconciled before a safe provider turn — Example: The last observed permission set or workspace metadata
- Plane: External memory — What it contains: Facts stored outside the active context window — How it changes: Retrieved deliberately — Example: A structured project note or research index
None of these is a substitute for the others.
History gives an agent a chronological audit trail. A baseline gives it a coherent starting model of the current world. A snapshot tells the runtime whether a live source has changed since it was last made model-visible. External memory prevents the active context from becoming a landfill for everything the system has ever learned.
The payoff is clarity: a changed permission is not a new user message; a reloaded repository instruction is not retroactive history; a durable note is not automatically relevant to the next turn.
What makes an epoch useful
In this model, an epoch begins when the runtime has assembled a complete baseline system context. The first provider turn in that epoch receives the baseline and the selected chronological history. From that point on, the baseline is treated as stable for the epoch.
Before later provider turns, the runtime can re-observe live context sources—such as effective instructions, capabilities, location, or project metadata. If something meaningful changes, the runtime admits a chronological system update at a safe provider-turn boundary. That update says what is newly effective without rewriting prior history or silently mutating a message the model has already seen.
An epoch ends when the baseline itself must be replaced. Common examples include:
- compaction, which starts a fresh context window from a distilled history;
- moving work to a substantially different environment;
- an incompatible transition that changes the whole model-facing baseline;
- a deliberate reset after recovery.
The system then builds a new baseline from fresh observations. Old updates remain useful audit history, but they no longer have to occupy the active context forever.
Why “live system prompt” is a trap
It is tempting to describe this as a system prompt that changes whenever the environment changes. That label hides two important questions:
- When did the change become effective for the model?
- Can a future replay reconstruct that exact transition?
If a runtime simply substitutes a new instruction blob before the next call, it may be impossible to tell whether the model saw the old or new version at a particular decision point. It also makes model caching and debugging harder: the prefix may appear stable in logs while changing invisibly underneath.
In a runtime built this way, admitting a combined update at a safe boundary addresses both problems. The model sees a chronological fact: *the effective state is now this.* The runtime advances its snapshot atomically with that admission. A retry can use the same durable history instead of sampling a slightly different environment midstream.
Compaction is a semantic boundary, not housekeeping
Anthropic’s guidance on long-horizon agents treats compaction as a central lever: summarize relevant details, discard redundant material, and continue from a smaller high-fidelity context. In the context-epoch proposal, that operation also creates a new semantic starting point.
Treating compaction as the start of a new epoch makes that explicit:
- Select and compact the relevant history.
- Re-observe the full system context.
- Create a fresh baseline and snapshot.
- Continue only when the baseline is complete enough to act correctly.
This design avoids a subtle failure mode: continuing a freshly compacted history with a stale snapshot of project instructions, permissions, or tools. A good summary cannot compensate for an incorrect current environment.
The five rules
For a runtime that needs to operate for hours rather than one response, we propose these rules as practical guardrails. They should be adapted to the runtime’s persistence and safety model rather than treated as universal requirements.
1. Give every source a stable identity
If the runtime cannot name a source consistently, it cannot compare the previous observation to the next one. Stable keys make it possible to load different typed values, render them in a deterministic order, and generate a meaningful update when one changes.
2. Separate observation from rendering
The observed value might be structured configuration, a set of tools, or project metadata. The renderer decides how that value becomes concise model-visible text. Keeping those concerns separate makes it easier to compare state accurately while changing prose without losing the semantic identity of the source.
3. Update only at safe boundaries
Do not modify a model’s environment halfway through a provider turn. Gather changes, settle tools, promote eligible user input, then present the effective update immediately before the next model call. This preserves a comprehensible order of events.
4. Treat temporary unavailability as different from absence
An unavailable source does not necessarily mean the source has been removed. A filesystem watcher, remote service, or credentials provider may simply be temporarily inaccessible. Replacing the last good state with an empty value can create harmful, noisy changes. Preserve the effective value until the runtime can distinguish an actual absence from a failed observation.
5. Retrieve memory; do not auto-inject it
Structured notes and long-term memory are valuable, but they still consume attention. Retrieve them when the current task needs them. An agent should not carry every historical note into every turn merely because it can.
What we are learning building Virillio Code
Virillio Code’s system-context architecture remains in development. The current design direction treats system context as a structured collection of facts rather than a monolithic prompt, separating the projected conversation a model sees chronologically from the baseline environment that makes the current turn meaningful. Context epochs are the editorial model we use to reason about that distinction; they are not a product-compatibility guarantee.
This is deliberately a high-level architecture lesson, not a product claim or an implementation disclosure. The transferable idea is simple: treat current context as a versioned runtime concern, not a string that happens to be prepended to every request.
Sources and further reading
- Effective context engineering for AI agents — Context is a finite resource and long-horizon work benefits from compaction and structured notes.
- LangGraph persistence — Agent persistence can serve recovery and memory beyond one graph run.
- Harness design for long-running application development — Structured artifacts can preserve continuity across long-running work.
Editorial disclosure
This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.