Most agent failures in software teams will not look like a spectacular model collapse.
They will look like an ordinary task completed from the wrong context.
A repository still contains an old compatibility layer. A ticket says a billing API is supported. A Slack thread from three weeks later says the team decided to remove it after migration. A design document was never updated. An incident note changed the rollout order.
An agent can retrieve all of this.
That is the problem.
Retrieval does not decide which source should win.
Context conflicts are normal
Human teams live with conflicting context every day.
- code says one thing
- tickets say another
- chat contains the real decision
- docs are half stale
- incidents create temporary exceptions
- access rules differ between teams and environments
Humans resolve this through social and operational knowledge. They know who owns the service, which document is dead, which Slack thread was the actual decision, and when to ask before touching production code.
Agents do not get that judgment for free.
If the context layer only returns similar text, the model has to infer authority from fragments. It may pick the newest sentence. It may pick the most specific sentence. It may pick the sentence that looks easiest to act on.
None of those is a governance rule.
Memory is not authority
A memory item can say: use billing API v1 for enterprise customers.
That may have been true when it was stored. It may still be true for one customer segment. It may be false after a migration. It may be true for read paths but false for new writes. It may be something an agent is allowed to mention but not allowed to act on.
The memory is useful only if it carries operational shape:
- source
- owner
- timestamp
- scope
- confidence
- supersession path
- permission to influence action
Without that, memory is remembered authority with no audit trail.
The missing primitive is precedence
The question I care about is practical:
When sources disagree, which one is allowed to control the next action?
That means precedence has to be represented explicitly.
A production incident may override a stale design document. A code owner decision may override a generated summary. A security policy may override a user preference. A current ticket may override a memory from last month. A private document may match the query but still be out of scope for the agent.
This is not a prompt-format problem. It is a control-surface problem.
The agent needs context that is:
- source-backed
- time-aware
- permission-aware
- scoped to the task and actor
- able to mark older claims as superseded
- visible in the trace after the agent acts
Bigger context windows make this sharper
Large context windows help the model see more.
They do not tell it what should matter.
As agents get access to more repositories, tickets, docs, chat history, deployment records, incidents, and observability data, the central problem shifts. It is no longer only: can the model find context? It becomes: can the system govern which context the model is allowed to use?
That is where I think reliable agent infrastructure will be built.
Not around memory as a pile of notes.
Around context as a governed operational layer.