Context Is Infrastructure

A language model can generate an impressive amount of work within minutes. It can research, structure, decide, write, review, and delegate follow-up tasks. But the longer a project runs, the more clearly a limit appears that has little to do with raw model intelligence: a good result depends not only on what the model can do, but on which state of the project it actually has available at the right moment.

An agent can be technically strong and still continue in the wrong direction because it missed the latest decision. A chat can contain thousands of messages and still carry an outdated project state. A project folder can hold dozens of sources and still fail to make clear which ones are binding for the task at hand. A team can run multiple AI sessions in parallel without having a shared state of knowledge.

That is why context is not a decorative addition to a prompt.

Context is infrastructure.

It must be planned, bounded, updated, handed over, versioned, and cleaned of ballast—just like data, interfaces, or permissions.

The context window is not the project memory

The first misconception begins with the word “context” itself.

A context window is, first of all, the working space available to a language model for the current inference. Depending on the system, it can contain system instructions, the current conversation, parts of earlier messages, files, tool results, retrieved data, and internal working state.

That is useful. But it is not a reliable project archive.

A long chat easily creates the impression that the AI “must know everything by now.” In reality, as the conversation grows, more information competes for attention. Earlier material may be summarized, compressed, weighted less strongly, or simply no longer be available with the level of detail a current decision requires.

The practical consequence is simple:

A project must not store its state only inside the transient working surface of a chat.

The chat is a workspace. The project needs durable state objects beyond it.

Five layers of context

Long-running AI projects benefit from explicit layering.

These layers should not collapse into one another without control.

If every conversation carries the complete project archive, overload follows. If a fresh chat receives only one short prompt, context is lost. If a knowledge base contains everything but nobody defines which entries are currently binding, semantic ambiguity emerges.

The architecture therefore has to answer: What must persist, what must be loaded for this task, and what may disappear again after the work cycle?

Project folders are context boundaries, not magical memories

A good project folder is valuable because it bundles work: instructions, reference files, chats, and recurring project resources can live in one place.

But a project folder does not solve context management automatically.

It is better understood as a context boundary: a defined space within which specific material, rules, and conversations belong to one project.

That makes it possible to separate, for example, a research or methodology space, a concrete client or product project, an experimental prototype, a production workspace, and an archive of completed decisions.

This separation is not bureaucracy. It protects against context contamination.

If general research, personal notes, multiple client projects, and experimental agent prompts all land in the same space, the chance rises that a system will mix valid and invalid information.

A project folder is good when it increases relevance. It is bad when it merely accumulates mass.

The best project folder does not contain the most files

The quality of a project folder cannot be measured by file count.

A robust folder needs a small number of especially clear anchors:

1. Project Charter: Goal, scope, non-scope, success criteria.

2. Current State: What is true now? Which version is active?

3. Decision Register: Which major decisions are currently binding?

4. Constraints: Which rules, rights, budgets, and prohibitions apply?

5. Source Index: Which sources support which claims?

6. Open Issues: What is unresolved, blocked, or disputed?

7. Next Actions: What is actually allowed to happen next?

Specialist sources and work artifacts are added around these anchors.

The difference matters: sources tell us what we might know. A canonical project state tells us what the project currently treats as valid.

Chats are workspaces—not the operating system of the project

A long chat can be extremely productive. It can preserve style, domain language, and local decisions well. But beyond a certain point, its strength becomes its weakness.

The history grows, side topics appear, assumptions change, old instructions remain visible, and the number of implicit dependencies increases.

The question “Should I continue in the same chat?” is therefore not merely a convenience question. It is an architectural decision.

A useful chat should represent a coherent unit of work, for example research on a clearly framed question, architecture of one module, review of a version, development of a particular slice, or implementation of a bounded work package.

When the assignment, role logic, or project phase changes materially, a new chat is often cleaner.

The mistake would only be to start the new chat without a controlled handoff.

A new chat does not mean restarting the project

A fresh chat has one major advantage: it removes local ballast.

But it must not create project amnesia at the same time.

The target is therefore:

fresh working context + stable project state.

That does not mean blindly copying the entire previous chat. Instead, the new workspace receives a compact, explicit startup package: the new chat’s mission, current project state, binding decisions, relevant sources and artifacts, open risks, known counterarguments, non-goals, and clearly defined next steps.

This creates continuity without historical overload.

A handoff is serialized project state

A handoff is more than a summary.

A summary tells what happened.

A handoff must make it possible to continue correctly.

At minimum, it should contain the following fields:

Such a handoff is a state container.

It reduces the probability that a new session invents old decisions, repeats finished work, or continues from an obsolete intermediate state.

Good handoffs do not transfer everything

The temptation is to make a handoff maximally complete. But completeness is not the same as usefulness.

A handoff containing eighty pages of chat history simply moves the problem. The new session must once again determine what is current, important, or binding.

A good handoff therefore follows three rules.

1. State before chronology

Not “first A happened, then B, then C,” but: “The current state is X; X resulted from decisions A and C; B was rejected.”

2. Mark binding status

The system must distinguish between decided, experimental, rejected, open, and historical.

3. Reference sources instead of duplicating them

Large evidence packages are referenced or named. The handoff only needs to explain why they matter and which claim they support.

Canonical state prevents ghost decisions

Long-running AI projects develop a dangerous pattern: decisions exist only inside individual chats.

One session decides not to use API A. Another session does not know this. A third agent discovers API A again and integrates it. Weeks later, nobody remembers why it was rejected in the first place.

These are ghost decisions: project-impacting decisions without stable, discoverable state.

A canonical Current State document helps prevent this.

It should not contain every discussion. It holds only what is currently valid: current scope, current architecture, current versions, active constraints, open risks, latest major decisions, and next approved work.

Chats may be exploratory.

Canonical state may not be.

Canonical does not mean immutable

A canonical state is not dogma.

It is the currently valid baseline.

When new evidence changes a decision, the baseline is updated. The important point is that the transition happens visibly.

A simple state logic may be enough:

PROPOSED – suggested, not yet valid.

ACTIVE – currently binding.

SUPERSEDED – replaced by a newer decision.

REJECTED – deliberately declined.

ARCHIVED – historically preserved, no longer operational.

This lets agents develop new ideas without turning every idea into a new truth immediately.

Context has freshness

Not all information ages at the same rate.

A business goal may remain stable for months. An API specification can change within days. A budget status can be obsolete within hours. A research result may stay valid for years but be relativized by new evidence.

Context therefore needs a freshness model.

For important context objects, it should be visible when they were last checked, what makes them valid, when they need to be checked again, and which downstream objects depend on them.

Without freshness management, stale truths emerge: statements that used to be correct and therefore continue to be treated as present truth.

Context selection matters more than maximum context volume

Large context windows tempt us to load everything.

The intuition is understandable: if the model can see more, it should be able to decide better.

But context has opportunity costs. Irrelevant or conflicting material competes with the information that actually matters for the current decision.

The professional question is therefore not:

How much context can the model fit?

It is:

What is the smallest context set that allows a correct decision for this task?

That is context engineering.

One context packet per work package

For bounded work packages, a small Context Packet is often more effective than dumping an entire project folder into the prompt.

A Context Packet can contain: goal of the work package, definition of done, relevant decisions, required inputs, affected files, active constraints, known risks, expected output format, and handoff destination.

The agent then receives the information it needs without implicitly becoming the interpreter of the whole project.

This builds directly on controlled work packages but adds another layer: work packages need not only scope, but a defined context scope as well.

A shared knowledge space is not a shared context window

A shared knowledge space—a structured knowledge base, vault, document corpus, or project repository—is valuable because multiple chats and agents can draw from the same knowledge foundation.

But “shared knowledge” does not mean every actor needs the same complete context window at all times.

Often, the opposite is better.

The knowledge space is broad and durable.

The working context is narrow and situational.

A good architecture therefore separates:

Knowledge Pool: the broader relevant knowledge.

Canonical State: the currently binding project view.

Retrieval Layer: selection of information relevant to the task.

Working Context: the slice actually passed to the agent.

This prevents knowledge from being confused with context.

Research pool and project knowledge are different things

Large research efforts quickly produce a pool of reports, studies, interviews, and analyses.

That pool is valuable, but it is not yet project state.

It may contain conflicting sources, different time horizons, unverified hypotheses, competing methods, and information relevant only to other niches.

Moving from research to project knowledge therefore requires compression and interpretation:

source → finding → interpretation → decision → canonical state.

Without this transition, the project folder becomes a library without a librarian.

Parallel chats need separate workspaces and shared integration points

Multiple parallel sessions are powerful. One can research, another implement, and a third review.

But this works only if parallelism is not confused with shared awareness.

Two chats do not automatically know the same intermediate steps. Two coding worktrees can share the same repository and still represent different branch states. Two agents can interpret the same assignment differently.

Parallel work therefore needs separate local workspaces, clearly defined inputs, explicit output artifacts, integration points, conflict rules, and a shared baseline.

Software engineering already knows this pattern: multiple worktrees can support parallel work on different branches of the same repository. But a common repository does not eliminate the need for merge discipline.

The same is true for AI work.

A shared origin is not yet a shared state.

Handoff before merge

Before a parallel workstream is integrated, it should deliver not only an output but also a short handoff: What changed? Which assumptions were used? Which files or states are affected? What was tested? Which uncertainties remain? Which conflicts with the baseline are possible? What does the integrator still need to decide?

That turns “here is my output” into an integrable result.

Context drift: when sessions slowly build different projects

Context drift does not require an obvious failure.

It can emerge gradually: one chat uses an older scope, one agent does not know a new restriction, one reviewer checks against different success criteria than the implementer, one handoff still contains a rejected assumption, or the knowledge base stores contradictory versions without status labels.

After several cycles, everyone appears to be working on the same project while actually working from slightly different mental models.

This is dangerous precisely because the local outputs can all look plausible.

Four signals of context drift

1. Reopening closed decisions

The AI repeatedly discusses issues that were already decided.

2. Contradictory status claims

One chat treats version 3 as current, another version 4.

3. Different definitions of done

Agents return formally completed work that is incomplete from the project’s perspective.

4. Surprising repetition

Work is repeated because results from another session were not integrated.