Agent Memory vs Agent Learning

Agent memory vs agent learning is not a marketing distinction. Per-agent memory is largely solved, while shared learning across agents remains open, and treating them as one problem produces expensive retrieval pipelines that answer worse. Karthik Ranganathan, co-founder and co-CEO of Yugabyte, described the failure inside his own company and the specific pipeline changes that moved retrieval from 14% to 82% faithfulness.

Agent memory vs agent learning: what the distinction actually means

Agent memory vs agent learning separates storing what one agent has seen from letting a group of agents inherit verified conclusions. Per-agent memory is largely a solved problem: agents extract memories from conversations and reuse them. Learning is different, because it happens only when several agents must work with each other and share what they concluded.

Karthik Ranganathan, co-founder and co-CEO of Yugabyte, made that argument at the AI Engineer World's Fair 2026 in San Francisco. His framing is that infrastructure built for a single agent to remember is often not the infrastructure a group needs in order to learn.

The mechanism of the failure is specific. When agent A finishes work and hands it to agent B, only the output travels: a file, a PDF, a document. The reasoning behind the output does not travel, and neither do the dead ends. Agent B then re-derives the reasoning, which costs tokens and produces a second, possibly different, answer.

Humans avoid this by transferring history on purpose. A new hire is told what the project considered and rejected weeks earlier. Ranganathan's point is that agents get the artifact and none of that history, so the group never accumulates knowledge, it only accumulates files.

That gives three requirements any shared-learning layer has to meet:

The same context must be reachable by agent A and agent B, so a handoff does not start from zero.
Stored context must be able to degrade. Not everything an agent produces belongs in the shared pool, so contributions need a review and promotion step.
Every stored item must be traceable back to its source, whether that is a data source, a person, or a conversation. Ranganathan calls traceability the first step to improving context at all.

A useful summary of the argument: agent memory works today per agent, but the infrastructure that makes one agent remember is not the infrastructure a group needs in order to learn.

Five misconceptions about agent memory and context

The talk listed five beliefs that look like fixes and are not, each of which Ranganathan describes as an architecture gap rather than a tuning problem. Three of the five are measurable in the failure they cause; two are structural. He gives a plain-language gloss for each: "more memory is just more memory," "just because you can share something doesn't mean you have shared knowledge," and "rag everything is not equal to learning and quality."

More memory is not learning. Adding stored memories makes retrieval more expensive without making the agent better informed.

Shared state is not shared knowledge. Passing a Markdown file to another agent shares bytes, not verified conclusions.

RAG over transcripts is not quality. Indexing everything gives the model more material to search and more chances to retrieve the wrong passage, so LLMs burn more tokens for worse results.

Fine-tuning does not scale as a knowledge store. Lessons learned by agents cannot be persisted that way and reused across agents.

A bigger context window is the quickest route to expensive failure. Ranganathan's claim is that filling a large window degrades the result, which matches published long-context research rather than contradicting it.

That last point needs scope. Research on long-context models shows accuracy degradation that varies by model, task, and configuration; it does not support a single universal token threshold at which every model fails. The practical takeaway from the talk is narrower: adding context without selection is not a strategy.

What building four agents at Yugabyte revealed

Yugabyte ran four agents: two internal, Hagen for customer support and Growth Vector for coordinated go-to-market between sales and marketing, and two external, Perf Advisor as an agentic database administrator and Voyager for database migration. Ranganathan said the team failed to ship anything that worked for almost a year before recognizing the problem as a data problem.

The confession carries weight because of who made it. A database company struggling with its own data layer is a useful signal that the difficulty sits in context architecture rather than in raw storage or vector scale. Customers were asking for more scale, more performance, and lower cost on vectors, graph, and relational workloads, and Ranganathan's conclusion was that this alone could not explain the failures. As he put it, at some point the requests were "breaking the laws of physics," so the real failure had to be somewhere else.

The company's response was to build an agent-native persistence layer it calls Meko, which it positions as storing context rather than as a database. Meko is not a public open-source project; Yugabyte's Meko page presents it as a product with a free tier and a login, and the demo describes connecting it to agents through a Model Context Protocol server. The naming is deliberate: as a database company, Yugabyte avoids calling a data pack a database because it holds several kinds of storage at once, including vector, graph, relational, and NoSQL.

Meko organizes stored context into data packs. Each data pack can hold memory, conversation history, a knowledge base, and observability data. Agents write into a private space and a human promotes selected pieces into a shared space, so other agents and people can retrieve the promoted context. The team sums up the goal as turning durable, repeatable workflows into infrastructure.

Four failed architecture attempts before Meko

Before settling on that design, the team tried four architectures that Ranganathan describes as wrong for the job. Each one failed in a way that points at a requirement the final design keeps.

One shared knowledge base. Everything went into a single store, backed by a distributed RAG pipeline that scaled and stayed elastic. It produced nothing useful, because a shared bucket of documents is not a shared understanding.

A tiny database per agent. Each agent got its own small Postgres instance, which the team assumed would be efficient given its database expertise. Repeatable workflows were reinvented on the fly by each agent, so nothing compounded.

Backend processing with no interface. The team removed the human-facing layer because agents do not need a user interface. The result was that nobody could tell what was happening, and without a human in the loop the outputs were bad.

Best components from the literature. The RAG pipeline was assembled from strong published components. It still scored poorly on the team's own evaluation.

The pattern across all four attempts is that the missing ingredient was selection and review, not storage capacity. Meko's private-then-shared promotion flow is a direct response to attempts two and three, which failed because no one curated what moved between agents.

The RAG tuning result: 14% to 82% with less context

Tuning the RAG pipeline one variable at a time moved faithfulness from 14% to 82% and cut the retrieved context from more than 7,000 chunks to roughly 1,000, which is about one-seventh the context size. Ranganathan reported those numbers on stage from the team's own traces, so they are first-hand measurements rather than an independent benchmark.

The starting numbers matter as much as the ending ones. The initial pipeline scored 14% faithfulness on a public Markdown benchmark, 20% on PDF input, and 57% context precision, while using components chosen for their reputation in research. The path between the two endpoints was not a single jump: improvement passed through intermediate faithfulness scores of 65 and 74 before reaching 82. The gains came from tracing what retrieval actually returned and changing one variable at a time, not from swapping in a new model.

An important caveat on the arithmetic: a reduction from over 7,000 chunks to roughly 1,000 chunks is a reduction in the number of retrieved chunks, and Ranganathan describes it as roughly one-seventh the context size. That ratio holds only if average chunk size stayed constant. It also says nothing about storage volume or per-vector overhead, which are separate figures.

Treat the result as a measurement of one pipeline on the team's own data with their own evaluation setup. It is evidence that retrieval tuning can raise precision while shrinking what the model reads. It is not evidence that any particular retrieval architecture always wins.

The demo showed a session started in one agent, killed, and resumed in the same agent through a data pack, then the same memory promoted so a second agent could retrieve it. Claude Code, Anthropic terminal-based coding agent, and OpenAI's Codex served as the two agents in the walkthrough.

Resumability is the narrower half of the demo: start a session, kill it, restart it with the same agent or the same account. Ranganathan notes that IDE agents like Claude Code already ship projects and a memory feature for this, and he turned all of his own IDE memory off. The reason is portability. He wants to pick up a topic later from a mobile app or from ChatGPT, which is a different agent on the same account, and Claude projects do not travel that far.

The cost argument for shared memory is straightforward. The first agent spends tokens working out a conclusion through trial and error. Later agents retrieve the stored conclusion through one call instead of repeating the exploration. Ranganathan and Developer Advocate Heather Downing both describe the saving as a reduction in tokens burned on re-derivation, not as a promise of a fixed percentage. Mechanically, the difference between re-deriving and retrieving is one Model Context Protocol tool call.

The demo also showed the permission boundary clearly. A second agent could see that a data pack existed but could not read a private memory inside it until a human promoted that specific item into a shared space. Promotion is deliberately granular: a maintainer can OpenAI entire data pack, but the demo promoted one incident fact at a time.

Resumability itself is not unique to Meko. Other tools have their own equivalents. The distinction the talk makes is cross-agent transfer with an explicit promotion step, which is the part that turns a personal memory into a team asset.

The demo ran on a real incident rather than a toy example. During the early-access launch of Meko, signup emails failed because the service had used an SCS sandbox instead of production and hit the sandbox limit. The agent stored that fact in a data pack called early access launch. A search days later surfaced it from May, and a second agent in a different IDE could see the data pack but not its contents until the memory was promoted.

Why promotion is the learning signal

Human promotion is the mechanism that separates a memory store from a learning loop. Every time a person decides a piece of context is worth keeping, that decision is a labeled example of what good context looks like for that team. Downing describes this as the training signal for future self-improving orchestration.

That framing matters for how you read the product's claims. The current shipped behavior is human-in-the-loop promotion. Any trained promotion agent is described as a future direction, not a current capability, and the talk does not claim it exists yet.

The talk also names a concrete operational pattern that shared memory fixes: a failing service. Without shared context, every agent independently calls the same broken server, each one burns tokens, and the team learns nothing until a human notices. With a shared data pack, the first agent records the failure and the rest retrieve it instead of repeating the call.

The design is traceable rather than reversible. Meko keeps the original conversations and tool-call traces in storage, and the stored memory is a compact representation extracted from them. Language traces come free with a data pack, so you can follow the decision trace down to the individual tool call and check how many tokens were spent. You can drill back to the source because the source is kept separately, not because a summary can be mathematically reconstructed from the compact form alone.

What data packs do and do not guarantee

A data pack is a named container in Meko that holds context for a workflow. It is not a drop-in replacement for an agent framework or a vector database, and adopting it means changing how agents write and retrieve context, including an MCP server connection and, in the demo, a skill that tells the agent when to call it. Teams can also choose how often the agent calls the server, from every turn to a judicious subset.

On locality, the demo describes Meko as a hosted service with a free tier and a login; it does not describe a fully offline deployment. Local storage, local retrieval, and local inference are three different things, and none of them should be inferred from a product being easy to connect.

On security, promotion and allowlist-style control over what a given agent can read support careful separation between private and shared context. That is not the same as compliance. Local execution, filtering, and granular promotion do not by themselves prove HIPAA suitability, tenant isolation, or safe deployment in regulated industries; those depend on the controls an organization builds around the tool.

Yugabyte's own dogfooding is the strongest available evidence for the workflow. The slide deck Ranganathan presented was built by sharing a data pack between two people who never met, and he notes explicitly that his description is first-hand experience rather than a controlled study. The same pattern shows up inside the company: an engineering team loads a Meko troubleshooting data pack straight into its coding agents, and Ranganathan keeps a data pack that captures how he writes so that drafts in his own voice, including LinkedIn posts, do not have to be re-explained each time. New team members get the shared context on day one and can contribute back to it.

FAQ

What is the difference between agent memory and agent learning?

Agent memory stores what one agent has seen and lets that agent reuse it. Agent learning requires multiple agents to inherit verified conclusions, including the reasoning and failed attempts behind an output. Memory is largely solved per agent; shared learning across agents is not.

Why does context get lost when one agent hands work to another?

The handoff carries an artifact such as a Markdown file, PDF, or document, and not the reasoning, dead ends, or history behind it. The receiving agent re-derives that reasoning, which costs tokens and can produce a different conclusion.

Does a bigger context window solve shared agent context?

No. Filling a larger window with unfiltered material increases cost without improving selection. Long-context research shows degradation that depends on model, task, and configuration rather than one universal token limit.

What retrieval numbers did Yugabyte report?

In the AI Engineer World's Fair 2026 talk, Karthik Ranganathan reported faithfulness rising from 14% to 82%, passing through 65 and 74, with retrieved context dropping from over 7,000 chunks to about 1,000. These are first-hand measurements from Yugabyte's own pipeline, not an independent benchmark.

Is the 7x context reduction a storage saving?

No. The measured change is in retrieved chunks per query, described as roughly one-seventh the context size. It says nothing about total storage volume, vector dimensions, or per-vector metadata overhead.

What is a Meko data pack?

It is a named container that holds memory, conversation history, knowledge base content, and observability data for a workflow. Agents write into a private space, and a human promotes selected items into a shared space that other agents can read.

Can memory be shared between Claude Code and Codex?

The demo promoted one memory from a private space into a shared data pack, then retrieved it from a different agent. Cross-agent access depends on the promotion step and on which data pack each agent is connected to.

Is Meko open source?

Meko is presented as a hosted product with a free tier and a login; the talk does not describe it as an open-source project. YugabyteDB, the company's distributed SQL database, is a separate product with its own distribution terms, so the two should not be conflated.

Does human promotion mean the agents are self-improving now?

No. Promotion is human-in-the-loop today, and each approval acts as a labeled example. Training a promotion agent on those signals is described as a future direction, not a shipped capability.

Why run four agents instead of one?

Yugabyte runs Hagen for customer support, Growth Vector for sales and marketing coordination, Perf Advisor as an agentic database administrator, and Voyager for database migration. The four-agent setup is what exposed the handoff problem, because each pair of agents had to pass work without passing reasoning.

What happens when a service goes down and every agent keeps calling it?

Each agent independently retries the same broken server, burns tokens, and learns nothing. A shared data pack fixes this because the first agent records the failure and the other agents retrieve that record instead of repeating the call.

Turn a video you already recorded into an article

Ranganathan's whole argument is that knowledge trapped in one place is knowledge nobody else can retrieve, and the same is true of the explanations sitting inside your own videos. If you have a workflow walkthrough, a debugging session, or a decision you made months ago recorded on YouTube, that footage already contains the reasoning and the dead ends that a written post usually loses.

Skala Blog turns that video into a written article: paste the YouTube URL, transcribe the video, and generate the draft.

Agent Memory vs Agent Learning: What the Distinction Actually Means