Enterprise Platform
Agent Memory That Lasts
An agent holds state between steps, facts between sessions, and knowledge unique to your business. Design all three into data infrastructure you already run.
Memory is a design decision
An LLM answers your request and forgets the exchange. What your agent appears to remember is what your app stored and handed back. MariaDB gives two types of memory on one platform: working memory in the ultra-fast cache with TTL and semantic memory alongside the operational data in the database.
Benefits
Why store agent memory here?
State that survives a crash
A run that crashes, scales down or waits for human approval resumes from its last checkpoint hours later, even on a different worker.
Facts that outlive the session
The next conversation opens with preferences and account details already known, so nobody asks the customer the same question twice.
Knowledge your business owns
Your prices, policies and product documentation reach the agent as it answers, ranked by meaning and stored alongside the data they describe.
One platform, one contract
Both stores are version-certified together and covered by one support contract, so you don’t add another vendor to your production agent stack.
Capabilities
Two stores, one platform
Short-term working memory
Checkpoints and conversation history sit in MariaDB GridGain with sub-millisecond responses and a TTL, so a task survives a restart and resumes where it stopped.
Cross-session memory
Preferences and account details outlive one session, stored by namespace and key, with a server enforcing time-to-live (TTL) automatically.
Semantic memory in a database
MariaDB Enterprise Server holds embeddings in a VECTOR column alongside the rows they describe, so one statement filters and ranks inside one transaction.
LangChain and LangGraph packages
Three integration packages implement the checkpointer, store, chat history and vector store interfaces, so the backend is a configuration choice in your code.
Also included:
Metadata filters in SQL
Sub-millisecond key lookups
Resume across workers
Server enforced TTL
Looking for Enterprise Platform pricing?
Recommended resources
Get started
Start building with MariaDB
One real-time database platform you can trust, for everything you run today and everything you build next.
Frequently asked questions
Agent memory is the state, facts and knowledge an AI agent keeps outside the language model. The model forgets each exchange, so your application stores what the agent should recall and hands it back on the next call.
Agent memory is shared. Many users, many sessions and several agents read and write it at once. A database keeps those writes consistent, outlives the agent process, and returns only the rows a request needs.
A checkpointer saves the state of a graph run so it can resume. With langgraph-checkpoint-gridgain, checkpoints live in MariaDB GridGain, so a job that pauses for approval resumes later on a different worker.
Short-term memory holds the run state for the job in flight. Cross-session memory holds the facts that outlive one conversation. Semantic memory holds business knowledge the agent can search by meaning rather than by key.
Yes. Three packages implement the framework interfaces: langchain-gridgain and langgraph-checkpoint-gridgain for MariaDB GridGain, and langchain-mariadb for MariaDB Enterprise Server.
In MariaDB Enterprise Server, vector embeddings live alongside the rows they describe. One statement filters by metadata and ranks by meaning, with no separate vector store to keep in sync.