Agent Memory Platform

One memory layer for every agent

Agents need to durably stash two kinds of state: the running ledger of a conversation (sessions, events, checkpoints) and the tasks that track an agent run. Without a shared service, every framework reinvents that wiring with its own retry rules, tenant boundaries, and failure semantics. This is the one service that owns the wire contract, the storage layout, and the validation, so the whole agent stack behaves the same way.

A dual-transport Rust service

The core is a single Rust binary, backed by Postgres.

• The API is a set of unary RPCs exposed over both gRPC and a matching REST surface from the same handlers, so a caller picks the transport that fits and gets identical behavior either way. gRPC is the fast default, HTTP is there for anything that cannot speak it.
• The wire contract is defined in protobuf and shared with every client, so the server and the clients never drift apart.
• It is modular: separate memory and task modules, each a build feature plus a runtime flag, so a deployment can ship memory-only, tasks-only, or both from the same codebase.
• One place owns scoping, validation, and failure semantics, so tenant boundaries and error handling stay consistent across every agent.

Drop-in clients for agent frameworks

The service is only useful if agents can reach it without ceremony, so it ships with Python client libraries for the major frameworks.

• Durable sessions and tasks for Google ADK, A2A, and LangGraph agents, so a conversation survives a restart, a retry, or a handoff between agents.
• The clients are transport-agnostic: gRPC by default, HTTP fallback, with the same typed errors and scoping on both paths.
• A one-call helper turns an agent into a durable, A2A-exposed endpoint with its sessions and tasks already wired to the platform, so no team has to stand up its own database.

Why it matters

Agents stop losing their state on a restart, and every framework gets the same retry rules, tenant boundaries, and failure semantics from one shared contract instead of reinventing them.

What’s next: long-term memory

The same modular shape leaves room for a long-term memory module beside the short-term sessions and tasks.

• Durable, searchable memory that persists across runs, not just within a single conversation.
• An extensible storage backend, so a module can sit on Postgres today and swap in a vector store or another engine for semantic recall later, all without changing the wire contract the clients depend on.