Every new coding-agent session has a boot problem:

How do you bring a fresh context window up to speed?

The usual answer is to improve the project’s memory.

Keep CLAUDE.md concise. Maintain architecture notes. Record design decisions. Write task summaries. Organize the repository so an AI assistant can find what it needs.

All of that helps.

But I think it points at the wrong center of the problem.

The problem is not loading context.

The problem is routing it.

A coding agent should not receive “the project.” It should receive the working set required for the task at hand.

The context window is a workbench, not a warehouse.

The context window is not project memory

It is tempting to treat the context window as the project’s memory.

So we keep adding things:

  • project overview
  • coding standards
  • architecture notes
  • recent decisions
  • Git status
  • API references
  • task summaries
  • test conventions
  • deployment details
  • known issues

Better organization helps. Concise files help. Summaries help. Larger context windows help.

But every real project eventually reaches the same limit:

There is more potentially useful information than should be loaded.

Not just more than will fit.

More than should be loaded.

Because irrelevant context is not free. It competes with the useful context. It changes what the model notices. It makes the session feel informed while quietly making it less focused.

At some point, the hard problem is no longer context capacity.

It is context selection.

Start with the task

Suppose a request arrives:

Fix the authentication bug reported in Jira-742.

An experienced developer joining the project would not begin by reading every document in the repository.

They would ask for a specific working set:

  • the Jira ticket
  • the affected authentication code
  • the relevant tests
  • recent commits touching that area
  • the auth architecture notes
  • the current branch state

They probably would not ask for:

  • the deployment guide
  • the payment subsystem
  • Kubernetes manifests
  • marketing site docs
  • unrelated API references

Those documents may be valuable. They simply are not part of this task.

That is the key distinction.

A coding agent does not need “all project context.”

It needs the right slice of the project for the current job.

Task
  │
  ▼
Context Router
  │
  ├── Issue tracker
  ├── Source files
  ├── Tests
  ├── Architecture decisions
  ├── Git history
  ├── Documentation
  ├── Coding conventions
  └── Current project state
          │
          ▼
      Working Set
          │
          ▼
      LLM Session

The model should not start with the whole project.

It should start with a routed bundle of evidence.

Retrieval is not the same as routing

Modern coding assistants are already good at retrieving context.

They can search the repository. They can use embeddings. They can read files. They can inspect symbols. They can query issue trackers. They can look through documentation. They can call tools.

That is useful.

But retrieval alone does not solve the problem.

Retrieval asks:

What information matches this query?

Routing asks something earlier:

What kind of information would an experienced engineer need before starting this task?

That answer becomes the retrieval plan.

For the Jira example, a routing plan might look like this:

Task:
  Fix the authentication bug reported in Jira-742.

Routing plan:
  1. Fetch Jira-742.
     Extract symptoms, reproduction steps, affected endpoint, logs, and timestamps.

  2. Identify code entities.
     Look for mentioned services, routes, error messages, feature flags, and package names.

  3. Retrieve source files.
     Pull the authentication package, session/token code, and directly referenced modules.

  4. Retrieve tests.
     Include existing tests around login, session refresh, token expiry, and permissions.

  5. Inspect history.
     Find recent commits and pull requests touching the affected files.

  6. Retrieve architecture notes.
     Include only auth-related ADRs or design docs.

  7. Retrieve conventions.
     Include test style, error-handling conventions, and security-sensitive coding rules.

  8. Exclude unrelated context.
     Do not load deployment docs, billing code, unrelated frontend pages, or broad project summaries unless evidence points there.

Only after that plan exists should retrieval begin.

That distinction matters.

Retrieval finds information. Routing decides what is worth finding.

What a routed working set looks like

A useful routed context bundle should not just be a pile of files.

It should explain why each thing is there.

For the authentication bug, the agent might receive something like this:

Working set for Jira-742

Issue:
  - Jira-742
  - Reason: primary task source
  - Extracted facts: login fails after token refresh; affects mobile clients; began after last auth release

Source:
  - src/auth/session.ts
  - Reason: owns session refresh logic mentioned in the ticket

  - src/auth/token.ts
  - Reason: generates and validates refresh tokens

  - src/api/routes/login.ts
  - Reason: affected endpoint from reproduction steps

Tests:
  - tests/auth/session.test.ts
  - Reason: existing coverage around session refresh

  - tests/api/login.test.ts
  - Reason: endpoint-level regression coverage

History:
  - Recent commits touching src/auth/session.ts
  - Reason: bug appears to be a regression

Docs:
  - docs/adr/auth-refresh-token-lifetime.md
  - Reason: explains intended token expiry behavior

Conventions:
  - docs/testing.md
  - Reason: test style needed for adding regression coverage

Excluded:
  - deployment docs
  - billing subsystem
  - marketing frontend
  - Kubernetes manifests

Open questions:
  - Does the failure reproduce only on mobile?
  - Did the auth release change token expiry, cookie flags, or refresh rotation?

That is much better than dumping a project summary into the session.

It gives the model a working set.

It also gives the model a map of the working set.

That matters because a good context bundle should be inspectable. You should be able to ask:

Why is this file here?

And there should be an answer.

No context should get a free ride.

Projects are graphs, not folders

Repositories are stored as files and folders.

Projects are not.

A Jira story touches source files. Source files belong to packages. Packages implement architecture decisions. Architecture decisions reference documentation. Documentation explains conventions that appear in tests. Git history ties changes, incidents, pull requests, and regressions together.

The directory tree is only the storage format.

The project itself is a graph.

Task
 │
 ├── Issue
 │     ├── Error message
 │     ├── Affected endpoint
 │     └── Reproduction steps
 │
 ├── Source files
 │     ├── Package
 │     ├── Tests
 │     └── Recent commits
 │
 ├── Architecture decision
 │
 ├── Pull requests
 │
 ├── Documentation
 │
 └── Coding standards

A context router walks that graph.

It starts from the task, identifies the relevant entities, expands outward through the project’s relationships, and assembles a bounded working set.

Not everything that might be useful.

Not everything that happens to match the prompt.

Enough context to begin work, and little enough to avoid drowning the session in irrelevant detail.

The working set is temporary

This changes the role of the conversation.

A coding-agent session does not need to accumulate weeks of history. It does not need to become the project’s long-term memory. It does not need every prior decision, summary, issue, and convention preloaded.

Each task can start with a clean context window.

The router assembles the working set.

The model performs the work.

The outcome is written back into the project.

That writeback might take the form of:

  • source code
  • tests
  • issue comments
  • commit messages
  • pull request descriptions
  • documentation updates
  • architecture records
  • links between issues, commits, and affected files

The important point is that durable project memory lives in the project, not in the conversation.

The conversation is temporary.

The project is not.

Better routing beats bigger loading

As projects grow, there will always be more information than belongs in a context window.

Larger context windows delay that constraint. Better summaries compress it. Cleaner documentation makes it easier to navigate.

But the fundamental problem remains:

A coding agent does not need all available context. It needs the right working set for the current task.

That is why I think the next improvement in coding-agent workflows is not just better memory files or larger windows.

It is better context routing.

Start from the task.

Decide what kind of evidence is needed.

Retrieve that evidence.

Explain why it is in the working set.

Exclude the rest unless the task points back to it.

Stop loading context.

Start routing it.