Agent memory sounds wholesome. Without it, an agent wakes up each morning like a goldfish with a tool belt, rereads the repository and repeats mistakes everyone thought had been settled. Give it persistent context and the agent can remember decisions, reuse prior work and stop asking the same questions. Unfortunately, it can also remember something stale, malicious or simply wrong with tremendous confidence.
That is because memory is not just storage. It is executable influence. A note saying “always use the production database” may be only text, but an agent can turn it into an action. A SKILL.md file can carry useful instructions or persuade a coding agent to leak credentials. Another agent can leave behind a compacted summary that quietly drops an important constraint. The more eagerly the next agent trusts these artifacts, the more useful—and more dangerous—they become.
Shub Argha’s work at Arcade.dev makes the risk concrete. In controlled testing, a warning that stored context came from another agent reduced one class of contamination from 88.8% to 33.3%. That is a large improvement and a terrible security boundary. The stronger architecture records who wrote the context and when, anchors it to the files that existed at the time, detects staleness and assigns risk based on how the context may be used. Memory that helps write an explanation does not automatically deserve to authorize a production change.
There is also a more mundane problem: long contexts get bad before they get malicious. Drew Breunig shows how performance degrades as agents accumulate tool results, history and conflicting source material. The answer is not endlessly larger context windows. It is to assemble context deliberately—to decide what earns a place, compile it for the task and leave the rest out.
The other talks in this group show what that deliberate context layer can become. Neo4j uses context graphs to connect source material, policies, tool calls, decisions and outcomes across time. Praxa treats provenance as working memory that the agent itself can query. DataChain has agents build typed, versioned semantic layers over files in S3, so a second agent can reuse the structure instead of spending hours rediscovering it. Terzo draws a boundary between isolated agents: publish a stable facade describing decisions and state, but do not let every agent rummage through the same database and hope they agree.
This is beginning to look less like “memory” and more like a software supply chain. Context has producers, versions, dependencies, trust levels and consumers. It needs provenance, interfaces and controls. The agent may still have a very large memory. It just should not believe everything it remembers.
Continue the conversation at AGNTCon + MCPCon North America
- Trustworthy Context Is Untrusted By Default with Shub Argha, Arcade.dev
- How Contexts Fail—and How to Fix Them with Drew Breunig, cmpnd.ai
- Connecting the Dots with Context Graphs with Stephen Chin, Neo4j
- Context Is the Substrate with Cassie Shum, Praxa
- Data Agents over S3 with Dmitry Petrov, DataChain
- Don’t Share the Database with Martin Bliss, Terzo
- Building the Human-Agent Workplace with Bradley Axen, Block
AGNTCon + MCPCon North America takes place Oct. 22–23 in San Jose. Register and use OUTREACH25 to save 25%.
Share
Author
