Why multi-agent AI breaks in production — and how Yugabyte's Meko is trying to fix it

"You can build a working prototype by stitching together memory, vector databases, and LangChain," says Karthik Ranganathan, co-founder and co-CEO of open-source database company Yugabyte. "[But] it won't get you to production, and it won't enable a team to improve the product with any velocity."

That's the problem Yugabyte is trying to solve with Meko, a new platform that acts as a shared memory and coordination layer for AI agents. The challenge it addresses is one most engineering teams building multi-agent systems will recognise: agents that work fine in isolation, but which start to break down once they need to share state, memory, and context across teams and workflows.

In truth, this has become one of the central engineering problems in agentic AI: how to maintain a consistent shared state across systems that were never really designed to operate as collective memory layers for autonomous software.

Companies across the stack are trying to tackle different parts of that problem. Tessl, for example, builds around a reusable source of truth for agent context and skills — the layer that determines what agents know how to do. Yugabyte's argument is that the answer lies deeper still — not in better orchestration frameworks or retrieval tooling bolted on top, but in a purpose-built coordination layer underneath.

Multi-agent systems fail when state falls out of sync

Ranganathan spent years working on distributed systems infrastructure at Facebook before co-founding Yugabyte, whose PostgreSQL-compatible database now runs inside companies including General Motors, Kroger, and Paramount Global. And he has seen what happens when large-scale systems fall out of sync.

According to Ranganathan, many of today's multi-agent systems work well enough in controlled demos and smaller pilots. The larger operational problems begin appearing once agents accumulate shared state over time and start coordinating across multiple workflows, datasets, and systems simultaneously.

One issue is state divergence — situations where different agents begin operating from different versions of the same information.

"Agent A updates a fact, Agent B is reading the pre-update version, and Agent C inherits Agent B's now-wrong context," Ranganathan said. "There's no consistency model anywhere in a stitched stack."

Another issue is cost. As more agents interact with the same systems, they often repeatedly retrieve and process overlapping information independently, driving token consumption and infrastructure costs sharply higher.

"Most of that gap is redundant retrieval," Ranganathan added. "Agents are re-fetching information that other agents already have, re-explaining context that should exist as a shared state."

The final issue is traceability. Existing observability tools can typically show prompts, tool calls, API usage, and latency, but struggle to explain how knowledge propagated between agents over time or how particular decisions emerged from shared memory systems.

"Existing tools trace what agents did — they don't trace what agents learned, or how that learning propagated between agents," Ranganathan said. "None of these [failure modes] are fixable with better prompts or more retrieval," he continued. "They're infrastructure problems that need infrastructure solutions."

Why multi-agent AI needs a shared memory layer

The idea of AI systems retaining memory across interactions isn’t unique to Yugabyte.

Companies including OpenAI and Anthropic have increasingly introduced memory and context features designed to help chatbots remember user preferences, prior conversations, and ongoing tasks across sessions. And smaller players such as LanceDB, Augment, and Letta Code have also pushed further into persistent context, attempting to give agents a longer-term understanding of projects, codebases, and developer workflows.

Yugabyte’s argument, however, is that many of these systems still stop short of solving the underlying coordination problem that emerges once multiple agents begin sharing state, memory, and organisational knowledge across larger environments.

The distinction is between memory as a feature and memory as infrastructure. For engineering teams deploying multiple agents simultaneously, that’s important as models, tools, and vendors begin changing underneath production systems. Memory tied to a single application or model can help personalise an interaction, but it does little to help separate agents share organisational knowledge, coordinate decisions, or maintain a consistent view of what has happened across a larger workflow.

“If you're building a multi-agent system where models will change, vendors will change, and you need an audit trail across the whole thing,” Ranganathan continued, “that’s an infrastructure decision, and it shouldn't be locked to whichever model you happened to start with.”

Agents need different kinds of memory to operate reliably

At the centre of Meko are four core primitives: knowledge, memory, conversations, and traces.

The knowledge layer acts as a shared and queryable pool of organisational information that different agents can reason over simultaneously. Without it, agents repeatedly retrieve, duplicate, or reinterpret the same information independently — the redundant retrieval problem that drives token costs higher.

Memory, meanwhile, is designed to persist state across sessions and tasks, allowing agents to retain information over longer periods of time rather than operating as isolated transactional systems. Meko separates per-agent memory from broader shared memory, so teams can control what stays local to a specific agent and what gets promoted into collective organisational knowledge — rather than everything bleeding into a single undifferentiated pool.

Conversations act as the persistent interaction history between users and agents, while traces answer the question existing observability tools can't: not just what an agent did, but how decisions were formed, how information propagated between agents, and which systems contributed to particular outcomes.

On top of all that, Meko also introduces "datapacks" — reusable collections of structured information that agents can access across workflows, teams, and applications, without each team rebuilding the same context from scratch.

Zoom

Persistent memory creates new governance and evaluation problems

Persistent memory creates another challenge for companies deploying AI agents in production: once incorrect information enters a shared system, it can begin spreading between agents, workflows, and datasets. A mistaken customer record, flawed recommendation, or inaccurate internal assumption can gradually shape how other agents reason and act, particularly in systems where memory and retrieval layers continuously feed back into future decisions.

That creates a difficult operational question for engineering teams building long-running agentic systems: how do you stop agents from reinforcing bad information once it enters shared memory?

“The honest answer first – you don't entirely prevent it,” Ranganathan said. “Any system that learns from interaction can absorb bad inputs. What you can do, and what we've designed Meko around, is make bad learning recoverable instead of permanent.”

Meko approaches that problem through a combination of provenance tracking, scoped memory, access controls, and retention policies. Every memory write can be traced back to the conversation, reasoning path, and execution history that produced it, allowing teams to investigate where incorrect assumptions first entered the system.

Shared organisational knowledge also requires explicit promotion, rather than automatically absorbing everything agents encounter, while permissions determine which agents can modify particular knowledge layers.

Configurable retention controls prevent outdated or low-value memory from accumulating indefinitely. Temporary working memory can expire once tasks complete, while older information can age out according to policy.

But none of that prevents wrong information from entering the system in the first place.

“What we don't claim to do [is] judge truth,” Ranganathan continued. “Meko isn't a fact-checker. If a wrong piece of information comes in with full provenance and proper privileges, it gets stored. The architectural promise is narrower: when bad learning does happen, you can find it, trace it, scope its blast radius, and remove it. That's the property the existing toolchain doesn't give you.”

That is also where other parts of the emerging agent tooling stack begin to intersect. Tess is building evaluation systems) designed to measure how skills and context affect agent behaviour across real engineering tasks and repositories, including “task evals” and “repo evals” that run against production-style codebases rather than static benchmarks

Skills and context are also becoming versioned engineering assets that can be distributed, reviewed, and governed across teams, with tooling emerging for skill reviews, evaluation history, and reusable context registries

Once agents begin sharing memory and organisational knowledge across workflows, enterprises face a broader governance problem: who approved a particular skill, which context shaped an agent’s behaviour, how changes were evaluated, and whether degraded behaviour can be traced back through the system over time. Those concerns are becoming part of the engineering layer itself rather than separate operational processes around it.