Most agent failures in software teams will not look dramatic.
They will look like an ordinary task completed from the wrong context.
A repository still contains an old compatibility layer. A ticket says the 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.
The agent can retrieve all of this.
That is the problem.
Retrieval does not decide which source should win.
Context has conflicts
Human teams live with conflicting context all the time:
- code says one thing
- tickets say another
- Slack contains the real decision
- docs are half stale
- incidents create temporary exceptions
- access rules differ between teams
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 most recent 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 the agent is allowed to mention but not allowed to act on.
The memory is useful only if it carries enough operational shape:
- source
- owner
- timestamp
- scope
- confidence
- supersession path
- permission to influence action
Without that, memory is just remembered authority with no audit trail.
The missing primitive is precedence
Software teams need a context layer that can answer a more practical question:
When sources disagree, which one is allowed to control the next action?
That means representing precedence 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 Linear ticket may override a memory from last month. A private HR 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 more important
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, Slack history, deployment records, incidents, and observability data, the central problem shifts from “can the model find context?” to “can the system govern which context the model is allowed to use?”
That is where reliable agent infrastructure will be built.
Not around memory as a pile of notes.
Around context as a governed operational layer.