We keep hearing the same advice:
Give the AI more context.
Add the README.
Add AGENTS.md.
Add architecture docs.
Add logs.
Add previous decisions.
Add the whole repository.
Add memory from previous sessions.
Sounds reasonable.
But there is a problem:
More context does not always mean better understanding.
Sometimes it means more noise.
More stale assumptions.
More conflicting instructions.
More irrelevant files.
And more chances for the agent to focus on the wrong thing.
That is the part I think developers need to pay more attention to.
The Assumption: More Context = Better AI
It makes sense at first.
If the agent knows more about the codebase, it should make better decisions.
Right?
Sometimes.
But imagine giving a developer:
- 400 files
- 12 architecture documents
- 8 old incident reports
- 3 outdated migration plans
- 6 instruction files
- 40 pages of logs
- previous agent memory
- the current task
and then asking:
“Fix this bug.”
That is not automatically helpful.
That is a lot of information to sort through.
The same problem can happen with AI agents.
Context Has Quality, Not Just Quantity
Not all context is equally useful.
Some context is:
Relevant
Some is:
Outdated
Some is:
Conflicting
Some is:
Wrong
Some is:
Technically correct but irrelevant to the current task
If you give all of it equal weight, the agent has to figure out what matters.
And that is where mistakes start.
Example: The Old Architecture Doc
Suppose your current system uses:
```text id="ixn1f3"
Controller
↓
Service
↓
Repository
But an old architecture document still says:
```text id="8ylsl1"
Controller
↓
Data Layer
You ask the agent to add a feature.
Now the agent has two sources of truth.
Which one should it trust?
Maybe it follows the code.
Maybe it follows the documentation.
Maybe it blends both.
And now you get a new pattern that never existed before.
The problem was not lack of context.
The problem was bad context hygiene.
Stale Context Is Worse Than Missing Context
Missing context usually creates uncertainty.
Stale context can create confidence in the wrong direction.
That is more dangerous.
For example:
Three months ago:
“All payments go through Provider A.”
Today:
Half the system has moved to Provider B.
But the agent still carries the old rule in memory.
Now it confidently implements the wrong integration.
That is why persistent memory can be useful and dangerous at the same time.
Conflicting Instructions Create Quiet Problems
Imagine the agent reads:
```text id="hp3on9"
AGENTS.md:
Use service classes for all business logic.
Then another file says:
```text id="x68ti8"
README:
Keep business logic inside route handlers.
Then an old task note says:
```text id="14479z"
Avoid adding new service layers.
All three may have been correct at different times.
Now they coexist.
The agent has to resolve the conflict.
That is not a safe default.
---
# More Tokens Do Not Mean More Attention
This is another important point.
A bigger context window gives the agent access to more information.
It does not guarantee equal attention to every piece of information.
If you include:
- hundreds of files
- long logs
- old discussions
- huge docs
the important detail may become harder to surface.
The real problem becomes:
> **Can the agent find the right context at the right moment?**
That is different from:
> **Can the agent fit everything into the prompt?**
---
# The Goal Should Not Be Maximum Context
I think the better goal is:
> **Minimum sufficient context.**
Give the agent enough information to make the right decision.
Not everything you have.
For example, if the task is:
> “Fix a validation bug in checkout.”
The agent probably needs:
- checkout flow
- validation rules
- related tests
- relevant data model
- current architecture constraints
It probably does not need:
- email service docs
- analytics history
- unrelated migration logs
- old design discussions
- every frontend component
More is not automatically better.
---
# Use Progressive Context
A better pattern is:
```text id="k7ov9i"
Start small
↓
Give relevant files
↓
Let the agent inspect
↓
Add more only when needed
Instead of:
```text id="dxypv0"
Dump everything
↓
Hope the agent finds what matters
This is basically progressive disclosure for coding agents.
Let the agent earn more context as the task requires it.
---
# Ask the Agent What It Needs
This is surprisingly useful.
Instead of giving the whole repo immediately, ask:
```text id="wd8gzg"
Before changing anything:
1. What information do you need?
2. Which files are likely relevant?
3. What assumptions are you currently making?
4. What context would reduce uncertainty?
Now the agent tells you what it is missing.
That is much better than blindly adding more.
Separate Permanent Context From Task Context
I think teams should split context into two categories.
Permanent
Things that should almost always be true:
- coding standards
- architecture boundaries
- security rules
- naming conventions
- ownership rules
Task-specific
Things relevant only to the current job:
- one bug report
- one feature requirement
- one set of logs
- one module
- one incident
Mixing both into one giant blob makes reasoning harder.
Keep Permanent Rules Short
This is important.
Your agent instructions should not become a novel.
If your AGENTS.md is 5,000 lines long, developers probably do not read it carefully either.
The best permanent rules are usually simple.
For example:
```text id="w7h7wu"
- Business logic stays in services.
- Repositories only handle persistence.
- Do not add dependencies without approval.
- Do not modify auth rules without explicit request.
- Tests must cover changed behavior. ```
Clear.
Short.
Hard to misinterpret.
Context Should Have an Expiration Date
Some context should not live forever.
For example:
- temporary migration rules
- incident-specific workarounds
- old feature flags
- deprecated API behavior
- one-off implementation notes
If the agent can remember something forever, someone needs to decide when that memory stops being valid.
This is why I think agent memory needs something humans already understand:
Lifecycle management.
Context should be:
created
reviewed
updated
expired
deleted
Just like code and documentation.
Make Sources Visible
Another good habit:
Do not let context appear as one anonymous blob.
The agent should know where information came from.
For example:
```text id="l6tqad"
Source: current code
Source: AGENTS.md
Source: architecture decision record
Source: incident from June
Source: previous agent memory
Why?
Because source matters.
Current production code should probably outweigh a two-year-old planning document.
Without provenance, everything can look equally trustworthy.
---
# Ask the Agent to Surface Conflicts
Before implementation, try:
```text id="gprxfr"
Review the available context.
Identify:
- conflicting instructions
- outdated assumptions
- duplicated rules
- unclear sources of truth
- anything that may no longer be valid
Do not change code yet.
This is a very useful step for large codebases.
You want context conflicts visible before they become code.
More Context Can Increase Hallucination Too
This sounds backwards.
But imagine the agent sees 10 partial references to a system behavior.
None gives the complete picture.
It may combine them into a plausible explanation.
That explanation can sound very confident.
And still be wrong.
The issue is not always missing information.
Sometimes it is too many incomplete signals.
Context Is Part of the Architecture Now
We usually think architecture means:
- services
- databases
- queues
- APIs
- boundaries
But in AI-assisted development, context becomes part of the system too.
Because context influences:
- what the agent believes
- what it changes
- which patterns it follows
- which assumptions it preserves
That means context needs engineering discipline too.
A Simple Context Checklist
Before giving an AI agent more information, ask:
Is this relevant?
If not, leave it out.
Is this still true?
If you are not sure, verify it.
Does it conflict with another source?
Resolve that first.
Is there a newer source?
Prefer the newer one.
Does the agent need this now?
Maybe later is better.
Will this context still be valid next month?
If not, do not treat it as permanent memory.
My Preferred Workflow
Instead of:
```text id="5axqqf"
Load entire repo
↓
Load all docs
↓
Load memory
↓
Ask agent to work
I prefer:
```text id="d6w46d"
Define task
↓
Give core constraints
↓
Agent identifies needed context
↓
Load only relevant files
↓
Check for conflicts
↓
Implement
↓
Verify
The difference is simple:
Context becomes intentional.
The Bigger Lesson
AI coding agents do not just need more information.
They need:
the right information
from the right source
at the right time
That is a much harder problem.
But it is also where developers can add real value.
Final Thought
We keep trying to make AI coding agents smarter by giving them more context.
Sometimes that works.
Sometimes it makes things worse.
Because:
More context can mean more noise.
More memory can mean more stale assumptions.
More instructions can mean more conflicts.
The goal should not be:
Give the agent everything.
The goal should be:
Give the agent exactly what it needs to make the right decision.
Because the best context window is not the biggest one.
It is the one with the least irrelevant information and the clearest source of truth.
Top comments (5)
The expiration point is the one I'd push hardest. Two habits that have worked for us. Memory notes are one fact per file with an absolute date written in ("since 2026-09-19", never "last week"), so staleness is visible at a glance. And a note that names a file, function or flag is treated as a pointer to check, not a fact to act on: the agent confirms the thing still exists before relying on it. That second rule catches your Provider A / Provider B case even when nobody remembered to expire the note.
That’s a really practical way to handle it.
I especially like the rule that memory notes are treated as pointers to verify, not facts to blindly trust. That makes stale context much less dangerous because the agent has to confirm the current state before acting on old information.
Using absolute dates is smart too — it makes aging visible instead of hiding behind phrases like “recently” or “last week.”
Really useful addition.
This is why I think context management is becoming an actual engineering skill, not just a prompting technique. I don't want an AI agent to know everything about a project at once. I want it to know what matters for the decision it's making right now.
For example, if I'm changing an authentication flow, giving the agent the entire repository, old migration notes, unrelated feature discussions, and every historical decision can actually make the reasoning worse. I'd rather give it the current auth architecture, the relevant files, the constraints, and let it pull more context when it hits an unknown.
There's also another layer here: "context has a lifecycle."
A decision that was correct six months ago can become technical debt when it stays in the agent's memory forever. So I think context should be treated more like code: versioned, reviewed, updated, and eventually removed.
The goal isn't maximum context.
It's "maximum signal with minimum noise."
Exactly — “maximum signal with minimum noise” is a great way to put it.
I agree that context management is becoming an engineering skill on its own. The goal shouldn’t be to give the agent everything, but to give it the right information for the current decision and let it pull more when needed.
And the lifecycle point is important too. Context should not live forever just because it was once correct.
Versioning, reviewing, updating, and removing context feels like the natural next step for serious AI-assisted development.
"Stale context creates confidence in the wrong direction" is the sentence I'd put on a wall. Missing context produces a question, which is visible. Stale context produces an answer, which ships.
Two additions.
The failure mode nobody plans for is that instruction files grow monotonically. Every incident adds a rule, nothing removes one, and after a year AGENTS.md is an archive of every mistake the team ever made rather than a description of the system. Curation isn't a cleanup, it's a recurring job with an owner.
And conflicting instructions don't get resolved, they get averaged. The agent produces something matching neither source, which is worse than following either, because the result is a pattern that exists nowhere in the codebase and now has to be reviewed as though it were intentional.
The structural fix is generating the instruction file from the repo rather than maintaining it by hand , or at minimum date-stamping sections so staleness is visible. Anything a human has to remember to update will eventually be wrong with confidence.