AI agents are entering production at scale. The problem is not capability — it is memory. Context windows are not memory. Retrieval is not recall. And most agent deployments are about to hit the wall where the agent cannot remember what it learned about your business ten minutes ago.
On April 14, Databricks launched Agent Bricks — a governed enterprise agent platform that unifies data, models, and governance under one roof. The announcement was framed as a platform story. But read between the lines and it is really a memory story. Enterprise agents need real context. Real context means durable memory. Durable memory is the hard part.
One week earlier, Microsoft released its Agent Governance Toolkit — an open-source security framework that names memory poisoning as one of the ten critical attack types AI agents face in production. Not prompt injection. Not model leakage. Memory poisoning: the corruption of what an agent has learned about your business, your users, or your operations.
Also in April, OutSystems published research finding that 94% of enterprises deploying agentic AI systems are concerned about sprawl — agents multiplying beyond anyone's ability to track what they know, what they have decided, and what context they are operating in.
Three different angles on the same root problem. AI agents are easy to demo. They are hard to run in production. The gap between demo and production is almost always memory.
This post is about that gap. What memory actually means for a business agent, why most deployments get it wrong, what durable and governed memory requires, and what it costs to fix it later versus design it in from the start.
The term gets used loosely. Every AI product now claims to have memory. But the word covers at least four distinct systems that do different work and have different failure modes.
The context window is the most misunderstood piece of AI agent architecture. It is the amount of information the model can hold in active consideration at any one moment. When people say an agent "has a 200K context," they mean the model can see roughly 150,000 words of recent conversation and attached content while generating a response.
Context windows are not memory. They are workspace. They are the equivalent of a human working memory — useful for what is immediately in front of you, gone the moment the session ends.
The failure mode is obvious: an agent with only a context window has no persistent knowledge. Every conversation starts from scratch. Every handoff between agents loses the thread. Every morning the system wakes up knowing nothing about what happened yesterday.
Above the context window, most agent platforms add a session memory layer. This persists information across turns within a conversation — the agent can reference what the user said three messages ago without you repeating it.
Session memory solves the "I told you this already" problem. It does not solve the "the system forgot everything when the session closed" problem. When the user closes the conversation or the session times out, session memory goes with it.
Task memory tracks the state of work in progress — what the agent has done, what it decided, what it still needs to do, what it handed off to another agent or system. This is the memory that makes multi-step workflows possible without the agent losing its place.
Task memory failure looks like this: the agent starts a quarterly goal review, gets through the first three quarters, then mid-way through Q4 it asks the user to re-explain the company structure because it lost track of which agent was supposed to be doing what.
The layer most deployments are missing is long-term business memory — the durable, structured, governed accumulation of what the business is, what it cares about, how it operates, who its customers are, what has happened historically, and what the system has learned from past executions.
This is the memory that makes an agent useful six months after deployment, not just on day one. It is the difference between an agent that knows your business and an agent that knows how to have a conversation.
Most "agent memory" products solve one or two of these layers. Very few address all four coherently. And none of them are the same problem — context window management is a model infrastructure problem, task memory is a workflow architecture problem, and long-term business memory is an information design problem that the business has to own.
Memory failures in production follow predictable patterns. They are not random bugs. They are the predictable result of specific architectural decisions that feel fine during a pilot and become unbearable at scale.
The most common mistake is treating a large context window as if it solves the memory problem. During a demo, you paste in relevant documents, the agent answers questions about them, and everyone is impressed. Six months later, the agent is getting 50 requests a day, nobody is curating the context window anymore, and the agent is hallucinating answers because the context is a chaotic mixture of unrelated documents and old conversation fragments.
The context window is a work surface. It is not a database. Businesses that treat it as a database end up with systems that work until they do not, and nobody can explain why.
Business memory without structure is just a pile of text. If your agent stores everything it learns in an opaque blob, it cannot reason about what it knows, update specific facts without rewriting everything, or distinguish between a general principle and a one-time exception.
A well-designed memory schema answers questions like: What entities exist in this business (clients, projects, people, products)? What relationships connect them? What policies govern how the business operates? What has happened historically that the system should remember?
Without this schema, memory grows but becomes ungovernable. You cannot audit what the agent knows. You cannot correct it without doing expensive retraining or manual deletion. You cannot migrate it if you change platforms.
The third failure mode is subtler. Most teams treat memory as a technical concern — something the engineering team configures once and the business users never see. The result is memory that serves the agent's needs rather than the business's needs.
Business memory needs to reflect how the business actually operates, not how the agent framework happens to store information. It needs to be understandable by the people who run the business, not just the people who built the agent. And it needs to be governable — the business needs to be able to inspect it, correct it, and control who can add to it.
When memory is purely agent infrastructure, you get systems that know a lot of things that are technically true but organizationally useless. The agent remembers that a client mentioned a concern in an email two months ago but cannot surface it at the right moment because the memory schema does not connect that input to the relevant workflow.
The final production failure is the most damaging to trust. When agents mix what they were explicitly told with what they inferred, what they concluded from context, and what they assume from pattern matching, the resulting memory becomes unreliable.
Users stop trusting the system because they cannot tell when the agent is reporting something that was established fact versus something the agent constructed from a conversation three weeks ago. Without that distinction, the agent becomes unusable for any workflow where accuracy matters — compliance, financial operations, client-facing tasks.
This is the memory poisoning problem Microsoft named in its governance toolkit. It is not always malicious. Most of the time it is just an agent that generalized too broadly from limited context and encoded an incorrect assumption as if it were fact.
Durable memory for business agents is not a feature you enable. It is a set of design decisions that have to be made deliberately, implemented with discipline, and maintained as the business changes.
Durable memory persists when the session closes. It survives across days, weeks, and months. It is stored in a system designed for persistent information, not in a model's context window or a session cache.
The practical implication is that memory must live outside the agent's runtime. It must be addressable, queryable, and updatable independently of any single model's context constraints. When the context window is 200K today and 2M in eighteen months, your memory architecture cannot depend on the model to store it.
Memory that cannot leave your current platform is a liability, not an asset. As the market for AI agents matures, businesses will need to move between providers, mix runtime components from different vendors, or update their infrastructure without losing the accumulated context that makes their agents useful.
Portability means memory is represented in structured formats that are readable by systems other than the one that created them. It means entity definitions, relationship maps, and policy records are not encoded in vendor-specific blob formats. It means you can export, audit, and reload your business memory without a complete reconfiguration.
This is the same argument that applies to data portability in any domain. Your business context should not be hostage to one vendor's storage format. (For a broader view of how portability and vendor lock-in interact across the entire agent stack, see Why Model-Agnostic AI Platforms Matter More Now That Model Vendors Sell Agent Platforms.)
Memory governance answers questions that most teams do not think to ask until they have already created a problem: Who can add new information to the agent's memory? Who can correct incorrect information? How are conflicts between sources resolved? When does the agent update a memory versus add a new memory versus note a disagreement?
Without governance, memory becomes a graveyard of unresolved contradictions. The agent recalls one version of the client engagement from an email in March. It recalls a different version from a CRM update in April. Which one is correct? The system has no way to know because nobody defined who has authority over the memory.
Governance also determines how the agent handles uncertainty. A governed memory system can flag when it is not sure, surface the uncertainty to the right person, and update only after human confirmation. An ungoverned system either picks one arbitrarily or presents both as equally valid, undermining trust in both.
Business knowledge changes. A client's contact changes. A product name changes. A policy is updated. If memory cannot represent change over time, the system either accumulates contradictions or requires expensive manual cleanup.
Versioning means the system knows what it knew when. It can trace the history of a piece of information, understand when it was updated, and reason about whether a given fact is current or historical. This is essential for any workflow where audit trails matter — compliance, financial operations, legal handoffs.
Not every agent in a business should have access to all business memory. A sales agent should not necessarily have access to internal financial projections. An operations agent should not necessarily have access to HR records. A client-specific agent should not have access to memory from other client engagements.
Scoping determines what each agent can read, write, and update. It is the memory equivalent of access control in any other business system. Without it, you have agents that know too much, share information inappropriately, or create liability by recalling client data in the wrong context.
A professional services firm deploys an AI agent to manage client onboarding workflows. The agent is connected to their CRM, email, and project management tool. During the pilot, it works well — the agent can pull client context, track task completion, and send status updates.
Six months in, problems surface. The agent has been adding notes to its session memory that never made it to the CRM. Different team members have had different conversations with the agent about the same client, and the agent has formed conflicting impressions of the client's preferences. When a team member left, their agent context was lost and nobody could reconstruct what the system knew about several active engagements.
The firm cannot audit what the agent knows about any given client because memory is distributed across session caches, context window fragments, and tool call logs with no unified schema. They are essentially flying blind on what their main operational agent has learned about their business.
A manufacturing company runs three agents across procurement, logistics, and client operations. Each agent has a structured long-term memory layer that is governed separately.
When the procurement agent learns that a key supplier is experiencing a production delay, it writes that fact to the shared business memory with source attribution, confidence level, and expiration — this information is current as of April 14, 2026, and should be re-verified if referenced after May 1.
The logistics agent can read that memory and surface it automatically when planning routes for affected shipments. The client operations agent can see it when preparing customer communications. The governance rules determine which agents can write to which memory namespaces, who can override a flagged uncertainty, and how historical changes are tracked.
When a team member asks the procurement agent about a past decision, the agent can reconstruct the context from memory with full provenance — here is what was known, here is when it was learned, here is what has changed since.
The system is not perfect. But it is auditable, correctable, and comprehensible to the people running the business.
The Databricks Agent Bricks announcement, Microsoft's governance toolkit, and the OutSystems sprawl data are not coincidental. They are the same signal arriving from different parts of the enterprise market: companies that deployed agents in 2024 and 2025 are hitting the memory wall in 2026.
The symptoms are consistent across organizations: agents that seemed capable in pilots become unreliable at scale. Configuration that worked for one use case breaks when you add a second. Memory across agents becomes inconsistent in ways nobody can trace. Security teams start asking questions about what the agent knows, where it learned it, and who can change it.
These are not solvable by adding a bigger context window or tweaking a prompt. They are structural problems in how memory was designed — or more often, not designed at all.
The enterprises that saw this earliest are now building around it. Databricks put memory and governance at the center of their agent platform. Microsoft named memory poisoning as a top-tier threat category. The Linux Foundation's Agentic AI Foundation — backed by OpenAI, Anthropic, Google, Microsoft, AWS, and others — is establishing protocol-level standards for how agents share context and memory across systems.
This is not theoretical infrastructure. This is what production readiness actually requires. And the businesses that built it in from the start are not scrambling.
If you are evaluating AI agents or building a deployment, here is what to look for and what to build deliberately.
Before the agent starts operating, define the key entities in your business, the relationships between them, and the categories of information the agent will accumulate. This is the difference between a memory system that grows usefully and one that grows into a mess.
Ask: What does the system need to know about our clients? Our operations? Our policies? Our people? What should it remember from past executions? What should it be able to reason about over time?
Make sure long-term business knowledge lives in a storage layer that is independent of any single model's context window or any single session. The agent should be able to query it, update it, and reason about it without relying on the model's internal context.
Define who can write to memory. Define how conflicts are resolved. Define what happens when the agent is uncertain. Define how memory is audited and corrected. These are not security theater additions — they determine whether the system can be trusted over time.
Map which agents should have access to which memory namespaces. The principle is the same as any access control system: each agent should have exactly the access it needs to do its job, and no more.
Run scenarios where memory is missing, contradictory, or outdated. See how the agent handles each case. If the agent cannot reason clearly about its own uncertainty, it will make confident errors that are harder to catch than obvious failures.
Business knowledge changes. The memory schema and the accumulated content both need maintenance. Build review cycles, correction workflows, and update processes into how the system operates, not as afterthoughts.
Q: Is a large context window enough for AI agent memory? A: No. A context window is workspace — it holds information in active use for the duration of a session. It does not persist when the session closes. Real agent memory has to survive session boundaries, which requires a storage layer that is independent of the model's context constraints.
Q: What is memory poisoning in AI agents? A: Memory poisoning occurs when an agent's accumulated knowledge is corrupted — either through malicious input designed to insert false information, or through normal operation where the agent makes incorrect inferences and encodes them as fact. Microsoft named memory poisoning as one of the top ten security threats for AI agents in production. The risk is that corrupted memory makes the agent unreliable in ways that are hard to detect unless you have governed, auditable memory.
Q: How is agent memory different from a database? A: A database stores facts. Agent memory stores beliefs, context, uncertainty, provenance, and relationships — information that changes as the system learns. A good agent memory system can represent that something was true, is now false, and was updated on a specific date. A database row just shows the current state. Agent memory needs to track the evolution of knowledge, not just its current snapshot.
Q: Why does memory portability matter for small businesses? A: Because your business context — client history, operational knowledge, accumulated decisions — is one of your most valuable assets. If that memory is stored in a vendor-specific format that you cannot export, you are locked in not by contract terms but by the cost of losing what the system has learned. Portability means your business memory remains yours even if you change platforms.
Q: Can AI agents share memory with each other without creating chaos? A: Yes, but only with deliberate design. Shared memory requires governance rules that determine which agents can write what, how conflicts are resolved, and how scoping prevents agents from accessing information they should not see. Without those rules, shared memory becomes inconsistent across agents and creates the sprawl problem OutSystems identified — agents that know different things about the same business with no way to determine which is correct.
If your team is building or evaluating AI agent deployments and needs a platform designed for durable, governed memory across multiple agents and business contexts, Associates AI can help you design the operating layer that keeps your agent system trustworthy over time. You can talk with us here: https://associatesai.team/contact
Written by
Founder, Associates AI
Mike is a self-taught technologist who has spent his career proving that unconventional thinking produces the most powerful solutions. He built Associates AI on the belief that every business — regardless of size — deserves AI that actually works for them: custom-built, fully managed, and getting smarter over time. When he's not building agent systems, he's finding the outside-of-the-box answer to problems that have existed for generations.
More from the blog
Anthropic's Claude Opus 4.7 shipped this week with major gains in agent task execution and long-hori...
The numbers just landed for mid-2026. Fifty-four percent of organizations run AI agents in productio...
On June 12, 2026, the most capable AI model on the market vanished for every customer, worldwide, wi...
Want to go deeper?
Start the free trial. Hire your first Teammate in minutes and put it to work on what you're reading about.
Start Free Trial