Context Is Infrastructure: Keeping Agents Aligned on Long-Running Software

A coding agent can know an extraordinary amount about a repository at 2:00 PM and almost none of it in a fresh session tomorrow.

That is not necessarily a model failure.

It is a property of the environment.

Software projects last months or years. Agent sessions are temporary. Context windows are finite. Conversations get compacted. Models change. Engineers switch tools. Work moves between branches, terminals, machines, and eventually people who were not present when a decision was made.

If important engineering knowledge exists only inside the conversation that produced it, that knowledge is already fragile.

Our response while building StackLiberate has been to treat context differently:

Context is not something we paste into an agent before a task. It is infrastructure the project needs in order to remain understandable.

The objective is not to make an agent remember everything.

It is to make remembering everything unnecessary.

Long-running work exposes the weakness of conversational memory

Short coding tasks can create a misleading impression of how agentic software development works.

Ask an agent to add a small component and the entire problem may fit inside one session:

Request
   ↓
Read code
   ↓
Implement
   ↓
Test
   ↓
Done

Long-running product development looks different.

A feature may depend on architectural decisions made three months ago. Another part of the system may already solve half of the problem. A workaround rejected in an earlier review may look attractive again to a new agent. A constraint that was obvious while designing the subsystem may be invisible from the file currently being edited.

The failure mode is subtle because the new agent can still be competent.

It reads the code it finds.

It sees a reasonable local solution.

It implements it cleanly.

The problem is that it may be missing the history that explains why the system is shaped the way it is.

We have seen versions of this repeatedly: an agent that understood a boundary earlier in the project can later propose a shortcut across that same boundary when the relevant reasoning is no longer present in context.

That taught us an important distinction:

Model intelligence and project memory are different capabilities.

A stronger model helps with reasoning.

It does not automatically recreate decisions that were never made durable.

This is becoming an industry problem

The broader agent-engineering community is converging on the same issue.

Anthropic has described long-running agents as a handoff problem: a new agent session resembles a new engineer arriving for a shift without the previous engineer’s memory. Their solution emphasizes leaving durable progress artifacts and clean repository state so subsequent sessions can understand what happened.

OpenAI has described repository knowledge itself as a system of record for agent-heavy engineering. One of its findings is particularly useful: giving an agent one enormous instruction file is not the answer. Context is scarce, and a thousand-page manual can be nearly as ineffective as no documentation because the relevant information becomes difficult to distinguish from everything else.

Kiro approaches the same problem through persistent steering and specs. Project conventions can live with the workspace, while requirements, design decisions, and task plans become artifacts that survive the conversation in which they were created.

The pattern underneath all three approaches is similar:

Temporary agent
        +
Durable project knowledge
        =
Continuity

We arrived at much the same conclusion from working on StackLiberate.

The conversation is useful working memory.

The repository has to carry the long-term memory.

The repository should remember what the agent cannot

Code already contains a great deal of knowledge.

Types describe possible states.

Tests describe expected behavior.

Module boundaries communicate ownership.

Schemas describe data.

Git records what changed.

But code does not contain every decision needed to safely modify a system.

Consider a perfectly reasonable implementation pattern that was deliberately rejected because it creates two writers for the same state.

Nothing about the syntax of the alternative necessarily tells the next agent:

We evaluated this approach before. Do not reintroduce it.

That knowledge needs somewhere durable to live.

For us, durable context can take several forms:

• Architecture documentation.
• Focused engineering rules.
• Feature contracts.
• Plans and tickets.
• Validation requirements.
• Explicit invariants.
• Decision records when the reason matters later.
• Tests that mechanically encode rules where possible.
• Git history showing how the system reached its current state.

Not every decision deserves permanent documentation.

The important question is:

Would forgetting this make a future implementation plausibly wrong?

If yes, the knowledge probably should not live only in chat.

We prefer maps over encyclopedias

There is an obvious response to context loss:

Write everything down.

That creates another problem.

An agent with too little information guesses.

An agent with too much undifferentiated information also struggles.

If every convention, historical note, future idea, rejected experiment, product requirement, test command, architectural principle, and coding preference is injected into every interaction, important constraints compete with irrelevant ones.

The result can become what we think of as context dilution.

Everything is present.

Nothing has enough weight.

This is why we prefer a layered model.

Small persistent map
        ↓
Relevant project documentation
        ↓
Task-specific plan
        ↓
Relevant code and tests
        ↓
Current implementation work

The persistent layer tells the agent how to navigate.

It should contain high-value principles that apply broadly.

The deeper documentation contains knowledge that matters only to particular parts of the system.

The task then supplies the immediate objective, constraints, and acceptance criteria.

This gives the agent enough context to reason without forcing the entire history of the product into every request.

The distinction matters as StackLiberate grows.

The correct context for authentication work is not identical to the correct context for a visual editing feature. Both may share engineering principles, but loading the full history of both into every session would eventually become counterproductive.

Durable context needs structure, not merely volume.

Tickets are executable context

One of the most useful artifacts in our workflow is the engineering ticket.

A good ticket is not just:

Add this feature.

It captures enough of the problem that a future agent can reconstruct the intended work without needing the original conversation.

Depending on the change, it may describe:

• The current behavior.
• The desired behavior.
• Known architectural boundaries.
• The source of truth.
• Important invariants.
• Expected failure semantics.
• Explicit non-goals.
• Validation requirements.
• Rollback boundaries.

That makes the ticket more than project management.

It becomes portable reasoning.

A different agent can pick it up.

A different model can inspect it.

The work can resume days later.

A human can challenge the assumptions.

And once implementation begins, the ticket becomes a reference against which the result can be reviewed.

This is one reason our Plan First workflow and our context strategy are connected.

A plan that disappears with the conversation has limited long-term value.

A plan that becomes a project artifact can continue constraining the implementation after the agent that wrote it is gone.

Persistent knowledge and current truth are not the same thing

Documentation creates its own danger:

It can become wrong.

Old context delivered confidently is often worse than missing context because the agent has no obvious reason to question it.

So we do not want project documentation to become a museum of every thought we have ever had.

Useful agent context needs an ownership model.

Some information is canonical.

Some is historical.

Some is temporary.

Some is derived.

Some should be deleted when the feature is complete.

This is very similar to state design inside software itself.

If two documents claim different architectures, which one wins?

If an old plan conflicts with production code, is the plan still authoritative?

If a roadmap describes something that was later deferred, will a new agent mistake it for current scope?

Durable context therefore requires the same discipline we apply to other system boundaries:

know which representation is authoritative.

We try to keep permanent rules small, specific, and current. Detailed task reasoning belongs closer to the task. Completed plans can remain useful history without pretending to be the current specification.

Context needs lifecycle management too.

Some knowledge should become code

Documentation is not always the strongest place for an invariant.

If a rule can be mechanically enforced, we prefer to move it closer to the system.

Instead of repeatedly telling an agent:

Never create this dependency.

an architectural check may be better.

Instead of:

Always preserve this schema property.

a validator may be better.

Instead of:

Remember to run these compatibility checks.

CI may be better.

The progression looks like this:

Important observation
        ↓
Documented rule
        ↓
Repeated engineering invariant
        ↓
Mechanical enforcement, when practical

This is where context engineering begins to overlap with ordinary software engineering.

The best instruction is sometimes not an instruction.

It is a system that makes the wrong state difficult or impossible to create.

Persistent text still matters because not every design principle is mechanically enforceable. But the more critical the rule, the less we want correctness to depend entirely on whether the agent happened to pay attention to a paragraph.

Handoffs should leave the system understandable

A long-running agent should not only complete work.

It should leave a clean starting point for whatever comes next.

That means the end of a task matters.

Was the implementation finished or partially explored?

Which validation ran?

What remains unresolved?

Did an assumption change?

Was something deliberately deferred?

Does documentation now contradict reality?

If the next agent must reverse-engineer the previous session before doing useful work, the handoff failed even if the code itself is correct.

Our preferred endpoint is closer to:

Known repository state
        +
Known implementation state
        +
Known validation state
        +
Known remaining work

Then the next session can spend its context on the next problem rather than reconstructing the last one.

This becomes increasingly valuable when work happens in parallel.

A project cannot depend on every agent sharing one enormous continuous conversation because eventually they will not.

The repository becomes the coordination surface.

Context should survive model changes

There is another reason to avoid making the conversation the architecture.

Models change quickly.

The model used for one part of a project may not be the model used for another.

Tools change too.

A workflow might move from an IDE agent to a CLI agent. A planning task might be better handled by one model while another is used for implementation or review.

If the project's intelligence exists primarily as undocumented understanding between one engineer and one particular agent session, changing tools is expensive.

Durable repository knowledge makes the workflow more portable.

A new agent can inspect the same:

• architecture;
• contracts;
• tickets;
• tests;
• plans;
• code;
• history.

It may reason differently.

That can actually be useful.

But it begins from the same project reality.

We want StackLiberate's engineering process to benefit from better models without requiring every new model to rediscover why the system works.

Context is not control

Giving an agent excellent context does not guarantee a correct implementation.

It does something more modest and more useful:

It gives the agent a better problem to solve.

The model still reasons.

It can still misunderstand.

It can still find a shortcut.

It can still propose an abstraction we reject.

That is why context exists alongside planning, review, tests, and explicit boundaries.

Our broader engineering loop looks roughly like:

Durable project knowledge
            ↓
       Task intent
            ↓
        Discovery
            ↓
          Plan
            ↓
         Review
            ↓
     Implementation
            ↓
       Validation
            ↓
   Durable new knowledge

Notice that the loop ends where it began.

A successful task does not only produce code.

When the work reveals something future agents genuinely need to know, the project becomes slightly better at explaining itself.

The goal is not perfect memory

We do not expect an agent to carry the entire history of StackLiberate in its context window.

That would be expensive, noisy, and eventually impossible.

Instead, we want something closer to good infrastructure.

A developer does not memorize every database record. They know where the database is and what its contract means.

An agent does not need every architectural discussion loaded permanently. It needs a reliable way to discover the current architecture, understand the relevant constraints, and distinguish authoritative knowledge from historical noise.

That is the shift.

From:

How do we make the agent remember this?

to:

Where should this knowledge live so nobody has to remember it?

Once we started thinking about the problem that way, context stopped looking like prompting.

It started looking like engineering.

Software outlives the session

AI coding agents will keep getting better at long-horizon work.

Context windows will grow.

Compaction will improve.

Agents will gain stronger memory and better retrieval.

We expect all of that.

But software will still outlive individual sessions.

Teams will still change.

Requirements will still evolve.

Architecture will still accumulate decisions whose significance is not obvious from their final syntax.

So we do not want the reliability of a long-running project to depend on perfect conversational continuity.

The durable parts belong with the project.

The conversation can disappear.

The agent can change.

The model can change.

The work should still be able to explain what it is, what matters, and where the next engineer should begin.

That is why, for us, context is infrastructure.