\u201cIt is the state. It is very difficult to manage the state and keep it on point and actually transfer everything.\u201d<\/p>\n
For all the noise around models, prompts, and orchestration frameworks, Karthik Ranganathan<\/a>, co-founder and co-CEO of Yugabyte, tells The New Stack that most teams building AI agents are tripping over something far more mundane. <\/p>\n \u201cIt is the state,\u201d he says. \u201cIt is very difficult to manage the state and keep it on point and actually transfer everything.\u201d<\/p>\n It\u2019s not the part people get excited about. But once you\u2019re running this stuff for real, the cracks tend to show up in the data layer, not the models.<\/p>\n When the DIY stack stops being cute<\/p>\n Most teams working on agentic AI right now are doing what developers usually do, pulling together a stack from tools they already know. A relational database, a vector store, and some object storage. It works for a while. Until it doesn\u2019t.<\/p>\n \u201cWhat happens is your experimentation loop gets completely slowed down and sidetracked by the implementation behind it,\u201d Ranganathan says. \u201cAnd even worse, the research behind the implementation.\u201d<\/p>\n At the start, it\u2019s all about moving fast and trying things out. But as the system grows, more and more time gets pulled into wiring things together and keeping the data infrastructure from falling apart. Before long, teams that set out to build intelligent systems are stuck chasing issues in their pipelines.<\/p>\n There\u2019s also a quieter shift. Not long ago, most teams only needed to reason about one data system. Today, that\u2019s no longer true. \u201cBefore, we used to just take a Postgres database and try to figure out the optimal way to lay out data,\u201d Ranganathan says. \u201cNow we have a Postgres database and a graph database and a vector database\u2026 the problem complexity has gone up by a few orders of magnitude.\u201d<\/p>\n The DIY approach hasn\u2019t just become messy; it\u2019s become a mess.\u00a0<\/p>\n Agents don\u2019t fail like apps<\/p>\n Agent systems don\u2019t behave like traditional applications.<\/p>\n An app has defined inputs and outputs. AI agents, especially in multi-agent setups, are far looser. They continuously generate and consume context, build memory over time, and collaborate across tools and users.<\/p>\n That introduces a new class of problems.<\/p>\n \u201cMulti-agent systems\u2026 \u201d It\u2019s just teams,\u201d Ranganathan says. \u201cUltimately, you have to work as a team, whether you\u2019re an agent or human.\u201d<\/p>\n And the hardest part of teamwork isn\u2019t computation. It\u2019s coordination. It\u2019s a shared understanding. It\u2019s knowing what\u2019s already been done and why.<\/p>\n In today\u2019s stacks, that context is fragile. It gets lost between steps. And when something breaks, reconstructing what happened is difficult.<\/p>\n Which makes the question of what to keep \u2013 and what to throw away \u2013 harder than it sounds.<\/p>\n Memory, knowledge, and the mess in between<\/p>\n Much of Meko\u2019s design revolves around memory and knowledge.<\/p>\n Not everything an agent encounters is useful. Some information is relevant, some is broadly helpful, and some is just noise. The challenge is filtering and structuring that data so it remains useful over time.<\/p>\n The system\u2019s job is to extract what matters and make it reusable across agents and humans.<\/p>\n This is where Meko leans into collective memory.<\/p>\n In most setups, agents operate in silos. Context isn\u2019t easily shared, so teams repeat work and lose learning. Meko introduces \u201cdatapacks\u201d \u2013 scoped containers for direct data (conversations, decisions, and outputs) and indirectly extracted data (learnings that fuel collective memory and shared knowledge) tied to a project.<\/p>\n \u201cYou\u2019d be able to share this datapack and say, \u2018Why don\u2019t you look for yourself what I did?\u2019\u201d Ranganathan says.<\/p>\n Instead of passing context fragments, teams can work from a shared record.<\/p>\n From logs to decision traces<\/p>\n Meko treats that problem \u2014 not just deciding what matters, but preserving it in a usable way \u2013 as a core challenge.<\/p>\n Instead of just logging events, it captures what Ranganathan calls \u201cdecision traces\u201d \u2014 what an agent planned to do, how it executed, and what happened.<\/p>\n \u201cIf you don\u2019t agree with the plan, what\u2019s the point of doing the whole thing?\u201d he says.<\/p>\n This also ties into cost and accountability. If a workflow burns through resources, teams need to understand why. \u201cSomebody comes and says, \u2018Why did you spend $1,000 yesterday?\u2019\u201d he says. Without context, there\u2019s no clear answer.<\/p>\n For CTOs, that level of visibility isn\u2019t optional.<\/p>\n While it\u2019s still early, patterns are emerging<\/p>\n Ranganathan is candid about where things stand.<\/p>\n \u201cI think they\u2019re still figuring it out,\u201d he says. \u201cWe need repeatable use cases to mature this into a general-purpose data infrastructure for agents.\u201d<\/p>\n Much of today\u2019s agent work is still experimental. Still, Ranganathan is already seeing several patterns, such as collective learning across runs, an auditable record of what was learned, and resumability for long-running agents.\u00a0<\/p>\n For example, in the collective learning pattern, when Agent A updates a shared fact and Agent B reads a stale state, the question becomes: what consistency model do you want? Yugabyte took the position that this is a memory consistency problem in the computer architecture sense, and built around it.<\/p>\n Internally, Yugabyte already uses agents for tasks such as issue triage and code analysis. The common thread is persistence \u2013 letting agents run longer, accumulate context, and produce useful outputs.<\/p>\n \u201cCan I make my agent work longer without me?\u201d he asks. That\u2019s where the state becomes critical again.<\/p>\n A shift from models to infrastructure<\/p>\n Meko builds on Yugabyte\u2019s roots in distributed PostgreSQL, extending that foundation into an open source, agent-native architecture for AI agents.<\/p>\n In the next year, every agent framework will have a memory layer \u2014 its effectiveness will be determined by whether that memory infrastructure enables agents and humans to function as a team by learning continuously.<\/p>\n It signals a broader shift. The focus is shifting from models to infrastructure \u2013 specifically, the data layer that determines whether systems are usable and scalable.<\/p>\n Yugabyte bets that this layer needs to be redesigned for agents, not adapted from existing tools.<\/p>\n As Ranganathan puts it, \u201cIt\u2019s not what models can do\u2026 It\u2019s not the orchestration\u2026 It\u2019s the state. In the next year, every agent framework will have a memory layer \u2014 its effectiveness will be determined by whether that memory infrastructure enables agents and humans to function as a team by learning continuously. This requires purpose-designed agentic infrastructure designed for it from day one.\u201d<\/p>\n And right now, that\u2019s exactly where things are starting to break.<\/p>\n
![](\"https:\/\/www.europesays.com\/ai\/wp-content\/uploads\/2026\/05\/1cf43e50-cropped-bc46c9c3-headshot-disrupt-600x600.png\"\/)
<\/p>\n