Context Is Part of the Runtime

WHAT ACTUALLY CAUGHT MY ATTENTION

The quality of an agent's work does not appear to be determined only by the intelligence of the underlying model. It also depends on the informational environment we construct around the model: the instructions it receives, the history it inherits, the tools it can see, the documents available to it, the terminal output accumulated during execution, and the assumptions carried forward from previous turns.

Those elements collectively form something much closer to a runtime than to a prompt.

This makes me wonder whether we have been locating agent intelligence too narrowly inside the model. The model certainly matters, but the model always encounters a constructed world before it encounters the problem itself. If that world is full of contradictory instructions, obsolete decisions, irrelevant capabilities, noisy output, and historical residue, then some portion of the model's reasoning capacity must be spent reconstructing what the current problem actually is.

The practical recommendations suddenly become more consequential under this interpretation. Starting a new thread is no longer merely housekeeping. Restricting MCP servers is no longer merely about token usage. A handoff is no longer merely a summary, and a skill is no longer merely a convenient reusable prompt.

They are all mechanisms for shaping the runtime.

THE THREAD IS NOT THE MEMORY

One assumption I want to challenge is the idea that a long-running conversation necessarily represents valuable continuity.

When an agent and I have been working together for hours, it can feel reassuring that the thread contains everything we have discussed. We explored several approaches, found bugs, changed architecture, rejected alternatives, corrected terminology, ran tests, and eventually reached a better understanding of the system. Continuing in the same thread appears to preserve all that intelligence.

But the thread preserves something else as well: every dead branch that led to it.

The durable memory of an engineering system should probably live elsewhere. Source code, architecture documents, canonical models, decisions, invariants, tests, specifications, and verification results are the places where conclusions become institutional state. The conversation serves a different purpose. It is where uncertainty can be explored and where reasoning can temporarily expand beyond what has already been codified.

That suggests a cleaner distinction:

The important movement is bidirectional. Durable knowledge initializes working memory, while discoveries made during the reasoning episode can eventually be promoted back into durable state. What should not happen automatically is for every piece of ephemeral reasoning to become permanent simply because it occurred earlier in the conversation.

This makes restarting an agent look different to me. A fresh thread does not necessarily destroy continuity if the system has already externalized what matters. It may instead be the equivalent of restarting a process from a trustworthy checkpoint.

CONTEXT ACCUMULATES ENTROPY

The word I keep returning to is entropy.

As a thread grows, information accumulates at different temperatures. Some statements remain authoritative. Some were tentative from the beginning. Some have been superseded by later decisions. Some are simply records of failed debugging paths, verbose logs, temporary workarounds, accidental assumptions, or tools that happened to be useful three hours ago.

The agent has to distinguish among them.

Nothing in a long context window guarantees that newer information is more authoritative than older information, that an abandoned theory should no longer influence reasoning, or that a correction has fully displaced the assumption it corrected. The thread contains sequence, but sequence is not the same thing as semantic authority.

Software systems already have mechanisms for managing analogous problems. We garbage-collect unreachable objects, expire caches, rotate logs, compact storage, rebuild containers, checkpoint state, invalidate stale replicas, and restart processes whose internal state can no longer be trusted. Those systems do not regard unlimited accumulation as evidence of robustness.

Agent systems may eventually require the same instinct.

The interesting engineering question is therefore not simply how much context a model can support. It is how much of that context still deserves to participate in the current decision.

A HANDOFF MAY BE A FORM OF COMPILATION

This is where the recommendation to create clean handoffs became more interesting to me.

A useful handoff should not be a transcript summary. If the objective is merely to shrink the previous conversation, then compression can preserve exactly the wrong things. The real task is to identify which state remains executable: the current objective, authoritative sources, decisions already made, constraints that now hold, known failures, verification commands, and the exact next boundary of work.

That begins to resemble compilation.

Exploration produces a large, irregular body of reasoning containing possibilities, corrections, evidence, and abandoned branches. The handoff transforms that history into a smaller representation optimized for the next execution phase. Information is not merely shortened; its role changes.

This also clarifies why exploration and implementation may deserve separate threads.

During architecture formation, ambiguity is productive. I want to compare alternatives, test vocabulary, expose contradictions, follow implications, and sometimes revisit an earlier assumption. During implementation, that same ambiguity can become expensive. Once an architectural choice has been made and properly codified, the implementation agent should not need to rediscover every discarded alternative before acting on it.

The lifecycle may therefore have a deliberate context boundary inside it.

The boundary matters because the first half optimizes for exploration while the second half optimizes for faithful execution. Carrying the entire exploratory environment across that boundary may preserve history at the expense of precision.

`AGENTS.md` AS AN ORIENTATION LAYER

The recommendation to keep AGENTS.md lean exposed the same pattern at repository scale.

It is tempting to turn the file into a comprehensive manual because comprehensive instructions appear safer. Architecture decisions, development conventions, deployment procedures, troubleshooting notes, schema rules, test commands, project history, and domain explanations gradually accumulate until the file contains nearly everything an agent might conceivably need.

The result can be informationally correct and operationally poor.

An agent beginning a small task does not need to carry the entire architecture of the system into working memory. It needs enough orientation to identify what authority governs the task and where that authority can be found. This suggests that AGENTS.md may work better as a routing layer than as a knowledge repository.

This feels like progressive disclosure applied to agent reasoning. The agent begins with enough information to navigate and loads deeper context when the problem actually crosses into that domain.

The distinction becomes important as repositories grow. A small codebase can tolerate a large universal instruction surface. A complex system eventually needs topology: a way for the agent to understand where it is, what governs the local territory, and where deeper authority can be obtained.

TOOL ACCESS CHANGES THE DECISION SURFACE

I had previously thought about tool restriction primarily as a security principle. An agent should receive only the permissions required to perform the work because unnecessary authority creates unnecessary risk.

The Codex recommendations exposed another dimension.

Every visible tool creates another possible action. A connector, MCP server, database interface, browser, deployment system, or filesystem capability does not merely extend what the agent can do. It expands the decision surface over which the agent must reason. Even unused capabilities participate indirectly because the system must consider whether they might be relevant.

That suggests something adjacent to least privilege that I would call least-context privilege.

Security asks whether the agent is permitted to use a capability. Context engineering adds another question: should the capability even be present in the agent's decision environment for this particular task?

This connects directly to agent architecture. A mature system may not construct one permanently omnipotent agent. It may construct an execution environment around the task, resolving the minimum useful knowledge, authority, tools, and verification mechanisms before the model begins reasoning.

The runtime becomes assembled rather than assumed.

REPEATED PROMPTS MAY BE UNCOMPILED CAPABILITIES

The recommendation to convert repeated workflows into skills revealed another transition.

When I find myself explaining the same procedure repeatedly—where to inspect files, which validations to run, how to make a particular change, what must never be altered, and how success should be verified—I am carrying procedural knowledge conversationally. That is appropriate while the procedure is still being discovered, but repetition is evidence that the procedure may have become stable enough to deserve another representation.

A possible maturation path looks like this:

Each transition reduces the amount of procedural knowledge that has to be reconstructed during execution. The prompt expresses intent once. Repetition reveals a pattern. The procedure makes the pattern explicit. A skill packages the procedure for reuse, while a governed operator adds stronger contracts around authority, inputs, outputs, provenance, and allowed state transitions.

The important change is not automation for its own sake. It is the movement of stable knowledge out of ephemeral conversation and into inspectable system machinery.

This also gives me a better way to think about the relationship among prompts, skills, and governed actions. They may not be competing abstractions. They may represent different maturity states of the same operational knowledge.

CORRECTIONS SHOULD EVENTUALLY LEAVE THE THREAD

The recommendation to edit a weak original prompt rather than stacking correction after correction points toward a broader engineering principle.

Exploration naturally generates statements that become wrong. We discover that an interface belongs somewhere else, a provider needs to be pluggable, a schema assumption was incomplete, or a term no longer means what we originally thought it meant. Conversation is a good place for that movement because the cost of changing direction is low.

The problem appears when the correction remains trapped there.

An implementation agent encountering the complete history may effectively see:

A was true.

A needs an exception.

The exception should become the default.

Replace the default with B.

B has now been generalized into C.

The final truth may be perfectly understandable to the people who participated in the evolution, because we remember why the transitions occurred. The agent is being asked to perform historical interpretation before it can determine the present specification.

There should therefore be a point at which correction becomes canonicalization. The conversation remains a useful record of how the decision emerged, while the authoritative artifact is revised so that the next agent encounters the conclusion rather than having to reconstruct it.

The conversation is where a decision can be discovered.

The repository is where the decision should become true.

AGENT GARBAGE COLLECTION

By this point the individual practices begin to look like parts of one missing subsystem.

Agent runtimes need garbage collection.

The term is imperfect because not everything removed from working context is worthless. An abandoned hypothesis may still be historically interesting, a debugging transcript may remain useful for forensic reconstruction, and a prior architecture may deserve archival preservation. The important distinction is not whether information continues to exist somewhere, but whether it continues to participate in the current reasoning environment.

The operations are familiar even if we have not yet named them as one discipline. Old thread state can be checkpointed and released. Stable architectural decisions can be moved into canonical documents. Repeated procedures can become skills. Large terminal output can be reduced to evidence-bearing fragments. Irrelevant tools can be detached, and disproven assumptions can be removed from the active execution state.

None of those operations increases the intelligence of the model.

They reduce the amount of ambiguity intelligence must overcome.

THE ENGINEERING UNIT MAY BE THE WHOLE REASONING ENVIRONMENT

This is where the observation becomes larger for me.

We often compare agent systems by model, context-window size, reasoning mode, latency, tool support, or benchmark performance. Those attributes matter, but perhaps the more durable engineering unit is the reasoning environment assembled for a task.

That environment has several layers:

Seen this way, prompting is only one part of runtime construction. We are also deciding which knowledge becomes active, which authority is visible, which tools exist, which rules dominate, how completion will be tested, what execution evidence must survive, and where the resulting learning will be stored.

The agent does not merely receive a prompt.

It enters a world.

FROM PROMPT ENGINEERING TO CONTEXT ENGINEERING

This gives me a better vocabulary for something I have been noticing in our own use of Codex.

The strongest implementation prompts increasingly resemble engineering work orders. They establish the objective, current state, authoritative sources, scope, non-goals, architectural constraints, required work, verification conditions, and explicit stopping boundary. Their effectiveness does not come from rhetorical cleverness. It comes from removing ambiguity about what reality the agent should inhabit while performing the task.

The next step may be to stop treating that structure as a prompting convention and begin treating it as runtime initialization.

A mature agent environment could construct much of this automatically. Given an intended task, it could resolve the relevant canonical resources, assemble the smallest useful working set, provision appropriate capabilities, establish authority boundaries, supply verification procedures, and produce a clean checkpoint when the run completes.

At that point context engineering stops being something the human performs manually before invoking the agent. It becomes part of the agent platform itself.

That possibility feels considerably more important than learning how to write a better prompt.

HUNCH

My hunch is that we are still thinking about context windows too much as large containers into which useful information should be poured. The more durable abstraction may be an ephemeral reasoning runtime whose contents should be intentionally assembled, governed, monitored, compacted, and eventually released.

If that interpretation holds, larger context windows do not eliminate the context-engineering problem. They may actually conceal it for longer. A system capable of carrying enormous amounts of information can still suffer from stale assumptions, ambiguous authority, irrelevant capability surfaces, contradictory corrections, and accumulated execution noise.

The scarce resource may not ultimately be context capacity.

It may be context coherence.

This would make context management a first-class part of agent engineering rather than an optimization applied after the agent has already been designed. Memory, tools, authority, execution, and learning would all need explicit lifecycle semantics.

The context window would become only one implementation mechanism inside that larger system.

SEEDCORNS

Context is runtime state. The active context surrounding an agent is not simply background information. It participates directly in reasoning and therefore deserves to be engineered as part of the execution environment.

Conversation is working memory, not institutional memory. Threads are productive places for exploration, but durable conclusions should migrate into canonical artifacts. Restarting a thread can preserve rather than destroy continuity when the important state has already been externalized.

Context entropy is an engineering concern. Old assumptions, dead branches, verbose outputs, unused capabilities, and stacked corrections increase the work required to reconstruct current truth. Agent systems may need explicit mechanisms for compacting and pruning active state.

A handoff is a compiled execution representation. The useful handoff is not a shorter transcript but a deliberately constructed state package containing the objective, current authority, relevant evidence, constraints, known failures, and next executable boundary.

`AGENTS.md` is an orientation layer. Universal agent instructions may work better when they provide rules and routing rather than trying to contain the entire knowledge of a repository. Progressive disclosure may be a more scalable architecture than universal context.

Least-context privilege complements least privilege. Capabilities can create cognitive surface area even when they are never invoked. Tool and connector exposure may therefore need to be scoped for reasoning quality as well as security.

Repeated prompts reveal uncompiled capabilities. Procedures that must be explained repeatedly may be candidates for codification as skills and eventually governed operators. Stable operational knowledge should progressively move from conversation into inspectable machinery.

Corrections require canonicalization. Conversational history records how truth changed, but the next agent should not have to reconstruct present authority from that history. Decisions need a place where their current form becomes explicit.

Agent runtimes need garbage collection. Some information should remain active, some should become durable knowledge, some should compile into reusable capabilities, some should be archived, and some should leave the reasoning environment entirely. Retention and participation are not the same thing.

Context coherence may become scarcer than context capacity. Larger context windows solve the problem of fitting more information, but they do not determine which information deserves influence. The deeper engineering problem may be keeping the active reasoning environment coherent as available memory becomes abundant.

I do not want to elevate these observations into settled architecture yet. They have emerged from operating experience with current agents, and the implementations are still moving quickly enough that some of today's constraints may disappear. What feels more durable is the underlying pattern: intelligence performs differently depending on the environment through which the problem is presented.

That is the signal I want to keep.

WHAT I WANT TO KEEP WATCHING

I want to watch whether fresh, deliberately constructed agent runs consistently outperform long-lived conversations even when both technically contain enough information to solve the problem. If they do, the interesting variable will not simply be token count but the semantic quality of the working set: how much of it remains relevant, authoritative, and internally coherent.

I also want to watch what happens as agent platforms acquire persistent memory, larger context windows, automatic summarization, skills, sub-agents, and increasingly broad tool access. Those capabilities could reduce context friction, but they could also make hidden accumulation easier by allowing more stale state to survive without obvious failure. The critical question will be whether the platform merely remembers more or becomes capable of governing what should remain cognitively active.

I want to watch handoffs in particular. If a well-constructed handoff reliably allows a fresh agent to continue complex engineering work without the original conversation, then we may have found an important intermediate representation between institutional memory and ephemeral reasoning. That would make context boundaries explicit rather than accidental.

I also want to watch repeated prompts. Whenever the same procedural instruction appears across several runs, I want to ask whether I am looking at conversational convenience or at an organizational capability that has not yet been compiled. The difference matters because one belongs in working memory while the other may belong in the architecture.

Most of all, I want to watch whether context management begins moving out of human operating practice and into the agent infrastructure itself. The important threshold will arrive when the system can determine what knowledge to load, what capability to expose, what authority to grant, what state to externalize, what history to release, and when the current reasoning environment has become stale enough to reconstruct.

At that point we may stop talking primarily about prompting an intelligent model.

We may begin talking about engineering the conditions under which intelligence is allowed to think.