TL;DR
- AI agents need current, structural context that’s connected to the systems they are supposed to change.
- A new software engineering study calls this failure mode “context rot”: the drift between what an AI is told about a system and how that system actually works.
- In enterprise platforms like Salesforce, context rot is not a side issue. It is the difference between an AI agent that can answer questions and one that can safely act.
————
How much context do you need? Most enterprise AI conversations still treat context like a quantity problem.
More documents. More records. More FAQs. More data. More prompts. More instructions. More stuff poured into the model until, somehow, the agent becomes perfectly reliable.
But a new study points to a more uncomfortable problem:
AI is getting context, but it’s still breaking because a lot of that context may not still be true.
The paper calls this failure mode context rot. In AI-assisted software development, devs are increasingly give coding assistants persistent configuration files: CLAUDE.md, AGENTS.md, .cursorrules, Copilot instruction files, and other artifacts that explain how a project works. These files tell the assistant where logic lives, what conventions to follow, what dependencies exist, which commands to run, and how the codebase is structured.
That sounds useful because it is useful.
Until, of course, the codebase changes.
A function gets renamed. A file moves. The architecture shifts. The team changes a convention. The AI’s instruction file still confidently explains the old world.
Nothing necessarily breaks at the moment the context goes stale. No alarm goes off. The model does not say, “Excuse me, I appear to be operating from an expired map of reality.”
It just keeps going.
And that is the dangerous part.
Stale Context Makes AI Confidently Wrong
Though the study focuses on AI coding tools, this pattern is immediately familiar. Anyone who has worked inside any sort of mature enterprise system has seen it. A coding assistant reads a file that says authentication logic lives in one place, but it has moved. The assistant imports a module that no longer exists. It follows a convention the team abandoned months ago. It references a function that was removed during a refactor.
From the AI’s perspective, it is doing exactly what it was told.
From the system’s perspective, it is totally wrong.
This is the difference between a simple AI mistake and a context failure. The model may be perfectly capable of reasoning. The instruction may have been perfectly accurate when it was written. The failure happens because the system evolved but the context did not.
That is context rot.
The study’s findings make the problem fairly concrete: Researchers applied an existing documentation consistency checker to AI configuration files across hundreds of repositories. They found stale code element references in nearly a quarter of the repositories analyzed.
That does not mean every AI-assisted development workflow is broken. It does mean, though, stale AI context is far from theoretical.
If this happens in codebases, where artifacts are versioned, reviewed, tested, and relatively structured, imagine what happens in the enterprise systems where business logic has been building up for years.
Actually, you do not have to imagine.
You can open almost any mature Salesforce org and experience it for yourself.
Salesforce Has Context Rot Everywhere
Salesforce teams already live with their own version of this problem.
A field description says one thing. The flow does another. A validation rule encodes a business process nobody remembers approving. A permission set creates access the documentation says should not exist.
The official explanation of the org and the actual behavior of the org slowly drift apart.
That drift is annoying when humans are the only ones making changes. It creates long discovery cycles, slow impact analysis, brittle deployments, and the familiar archaeology of “why does this field exist?”
But once AI agents start acting inside that environment, context rot becomes much more serious.
Because agents do not just need to know what Salesforce is supposed to be.
They need to know what this Salesforce org actually is.
The real one.
The one with seven automations touching the same field.
That is the org an AI agent has to operate inside.
The Problem: Unmapped Complexity
This is where the study’s framing becomes especially useful.
Context rot happens because, get this… systems change.
Healthy systems, in fact, change constantly. Teams ship new products. Sales motions evolve. Compliance rules shift. RevOps adjusts process. Finance changes revenue rules. Support updates escalation paths. Admins add fields, flows, validation rules, permission sets, objects, integrations, and exceptions.
The failure is allowing the map of the system to fall out of sync with the system itself.
In software dev terms, that map might be an AI instruction file. In Salesforce, the map might be documentation, tribal knowledge, field descriptions, Lucid diagrams, and so on.
AI agents are only as good as the operational context they can access. A stale map does not become trustworthy because a better model reads it. A wrong dependency graph does not become safer because the agent sounds more confident. A missing permission relationship does not stop mattering because the prompt was beautifully written.
These are the victims of invisible complexity.
Structural Context Lets AI Act.
Enterprise AI efforts still over-index on knowledge context.
Knowledge context is the stuff an AI can read: docs, FAQs, policies, tickets, meeting notes, help articles, and support records. That context is useful. It lets an agent answer questions, summarize information, and retrieve known facts.
But acting inside Salesforce requires a different kind of context.
It requires structural context.
Structural context is the live understanding of how the system is actually configured: objects, fields, relationships, flows, Apex, validation rules, permissions, packages, dependencies, and downstream impact.
Knowledge context can tell an agent, “We use this field for partner deals.”
Structural context can tell the agent, “Changing this field will affect three flows, one validation rule, a CPQ dependency, two reports, a permission set, and a downstream revenue process.”
Those are not the same thing.
The first helps the agent sound informed.
The second helps the agent avoid breaking things.
That is the Sweep universe.
Sweep gives teams a continuously updated model of the structure underneath Salesforce: the metadata, dependencies, automations, permissions, business logic, and implementation reality that static documentation cannot reliably preserve.
In other words, Sweep is not trying to flatten complexity into a fake “clean” org.
Sweep makes complexity usable as context.
The Cleanup Trap
There is a common reaction to this problem: before we trust AI agents, we need to clean everything up.
That sounds responsible.
It is also where AI transformation goes to die.
Because mature enterprise systems are never perfectly clean. There is always another field to rationalize, another flow to consolidate, another permission model to rethink, another integration to document, another business exception to unwind.
If AI requires a pristine org before it can be useful, AI will remain stuck in pilots, demos, and carefully controlled side quests.
A real agent does not need the org to be normal. It needs to understand why the org is weird and it needs to know which weirdness is accidental tech debt and which weirdness is business-critical contex.
Context Rot Turns AI Into Another Risk Surface
Context rot is more than a software quality problem and stale AI context is not just an inconvenience.
It is not just a documentation issue. It is part of the reliability and governance layer for agentic systems.
If an AI agent is allowed to recommend, generate, or execute changes based on stale context, then stale context becomes a risk surface.
In Salesforce, that risk can show up in very practical ways: an agent, say, updates a field without seeing the automation that rewrites it later.
That doesn’t require the model to be dumb.
It only needs the model to be under-contexted. Or worse: confidently mis-contexted.
The Need for a Living Map
A static instruction file can help a coding assistant. A stale instruction file can mislead it. The same is true for enterprise AI. A static org diagram, a half-updated data dictionary, or a wiki page from the last transformation project may help for a while. Eventually, the system moves on.
The map has to move with it.
For Salesforce teams, AI readiness comes down to whether the agent has access to a current, connected representation of the system it is being asked to change.
The flows.
The fields.
The permissions.
The validation rules.
The managed-package behavior.
The dependencies.
That is the context agents need.
Or said another way: Your complexity is where the truth hides.
