Pete Johnson, Field CTO for AI at MongoDB, emphasizes that while the database industry has been building for roughly 60 years, the kind of AI agents people discuss today have only existed in their current form for about 18 months. That gap — six decades versus a year and a half — explains why agent development is still at a very early stage.
The context window is the scarce resource
Based on more than 100 customer conversations across 15 cities in six countries during the first half of 2026, Johnson reports organizations converging on one view: the context window is the constrained resource. The challenge is not packing more data into each prompt but deciding what belongs in that limited space.
His proposed answer is memory — not merely the context window itself, but a separate, persistent, queryable memory system that deliberately feeds models.
What a good agent memory provides that a context window alone cannot
Johnson outlines three key capabilities of a mature agent memory:
- It preserves what generative models produced in prior loops and sessions, so expensive reasoning isn't lost when a session ends.
- It enforces role-based access control over saved content, allowing a memory created by one team to be shared safely across an enterprise without leaking sensitive data.
- It supports retrieval of relevant prior content through semantic search rather than exact-match lookups, because agents query by meaning, not by keys.
This last point ties back to the six-decade history of databases: traditional systems excel at storing and retrieving structured data by exact criteria. Agentic memory requires storing unstructured generative outputs and finding them again by similarity — a different problem that benefits from native semantic search and integrated access control rather than stitching multiple systems together.
Emerging enterprise pattern
When such a memory exists, a practical and economical architecture emerges. Johnson sees enterprises adopting a pattern where the memory is paired with a leaner model — often an open-weight model — whose role is to judge rather than to originate elaborate outputs. The flow looks like this:
- A new query arrives.
- The agent performs a semantic search over memory, reranks results, and asks the lean model a single question: is this candidate good enough to return as-is?
- If yes: the system returns the memory answer and avoids invoking the expensive generative model.
- If no: the system escalates to the costly generative model, obtains an original solution, returns it, and then saves that output back into the memory for future reuse.
Economically, this means every original expensive answer becomes a cheap answer next time a similar request appears. The system becomes cheaper and faster with use, opposite to a token-maxxing approach where cost scales linearly with usage.
Memory types and human curation
Johnson argues mature agent memories will not be a flat short-term vs. long-term bucket but will have types similar to human memory. Examples include:
- Taxonomic memory: controlled vocabulary and definitions the organization relies on, ensuring consistent term usage (for example, ensuring “chargeback” matches the finance team's meaning).
- Procedural memory: task lists and sequences capturing «how we do this here» knowledge that turns a capable model into a useful colleague.
Not every generated memory should be kept, and not every kept memory should be surfaced first. Human curation will be crucial: people will inject high-value memories for frequent reuse, prune noise, and promote the procedural sequences that consistently work. This mirrors prior practices for knowledge bases and documentation.
Conclusion: memory is likely to become the first stable layer
There is still no settled, boring LAMP-like stack for agents. Johnson suggests that if one layer is likely to become the unremarkable, default choice first — the component teams stop arguing about so they can focus on building — it will be memory: semantic-search-backed, access-controlled, typed, and human-curated memory that saves expensive outputs and serves them cheaply thereafter.
As context, Pete Johnson is Field CTO, AI at MongoDB, and the essay appears as sponsored content.
