Karthik Ranganathan, Co-Founder & Co-CEO, YugabyteDB

An agent needs a Postgres database for perhaps twenty minutes. A payments platform needs one that never goes down across three regions. Most teams cover that range with different products, several vendors, and scores of on-call operators. Yugabyte delivers it as a single stack on AWS. YugabyteDB is distributed PostgreSQL built for global scale and resilience that also scales down to fractional instances. YugabyteDB AMP puts agents in charge of the fleet, handling provisioning, migration, and on-demand tuning. Meko gives agent teams the shared context they run on. See what it takes to run every Postgres workload on one foundation.

Hari Krishna Sunder, Principal Engineer, YugabyteDB

Multi-agent systems have a data problem nobody warns you about. Agent B sees Agent A's final output and nothing else; the reasoning, the dead ends, and whatever Agent A figured out three steps in all get thrown away. So teams of agents re-learn the same lessons every run, and when something breaks, your observability stack tells you what an agent did without telling you what it learned or how that learning spread.

My team spent the past year building a shared memory and knowledge layer for production multi-agent systems, and we made most of the available mistakes. We wired a vector database to a graph database to a relational store and watched the seams leak: entity extraction running twice on the same conversation, a knowledge graph that quietly went stale every time a memory updated, serialization bugs living at the boundaries between stores. "Just share a Postgres table" sounded reasonable too, right up until agents needed isolation and selective sharing at the same time.

I'll walk through what survived. How we ended up with one query surface across vector, relational, and graph data. Why per-agent memory and shared knowledge have to be separate constructs, not one table with a scope column. What conversation-history tiering actually costs and saves, and how to keep an audit trail of what agents learned rather than only what they ran. The patterns transfer whether your stack is Postgres, a dedicated vector store, or something you already regret.

Hari Krishna Sunder, Principal Engineer, YugabyteDB

AI agents are bursty, mostly idle, and unpredictable at scale. Traditional databases charge you for idle capacity and buckle when one runaway agent hogs shared resources. Yet AI agents still need high availability, resilience, and constant tuning, and the ones that reach production often outgrow a single node.

YugabyteDB AMP (Agentic Multitenant Postgres) is built for that journey. It manages large database fleets, each growing from a fraction of a core to a distributed, multi-continent deployment, with no migration or re-architecture along the way.

Join the YugabyteDB team for a first look at AMP. You’ll learn:

• How to spin up PostgreSQL clusters with an agent, MCP, the API, or the UI, and branch onto independent compute with zero-copy thin cloning

• How AMP’s idle databases scale to zero, so small and early-stage workloads don't pay for idle capacity

• How four agents (Architect, Voyager, Perf Advisor, and Nexus) automate setup, migration, integrations, and performance tuning

David Roberts, Senior Solutions Architect, YugabyteDB