An AI agent is only as useful as what it can remember - and how well it can connect the things it remembers. Most teams hand their agent a memory by reaching for a vector store: embed everything, retrieve by similarity, hope the relevant context comes back. It works, until you notice the agent keeps surfacing things that are near the question but not actually connected to it.
Cobrainer, a skills-intelligence company based in Munich, took a different route. They gave their AI agent a memory that lives in the database as a graph, where the agent builds the relationships between nodes as it goes. They did it without adding a graph database, a vector engine, or a search engine to their stack. It all runs on SurrealDB, alongside a Rust-native agentic graph RAG built on the same store.
Here's how, and why a single engine made the difference.
The problem with flat memory
Cobrainer runs a skills-intelligence platform - the kind of system that reasons about how people, roles, skills, and capabilities relate to one another. That's an inherently graph-shaped problem. But their first retrieval setup wasn't graph-shaped at all.
It pulled context through flat vector retrieval over an S3-and-OpenSearch pipeline, which carried two recurring costs:
Accuracy. Flat vector matches returned context that was loosely related - semantically near, but not necessarily connected in any meaningful way. The team wanted the agent to follow real relationships between entities, so its answers were grounded rather than approximate.
Tokens. Broad vector matches meant stuffing a lot of marginally relevant context into every prompt - expensive, and more so with every call. The team wanted to fetch only the context that mattered.
The obvious fix - adding a graph database on top of the vector and search systems they already ran - would have meant more infrastructure to operate. For a startup moving fast, that fragmentation was the thing to avoid, not embrace.
What they wanted instead
Cobrainer's requirements were less about any single feature and more about not paying a tax for combining them.
An agent and a graph RAG on one store: an AI agent whose memory lives in the database as a graph, plus an agentic graph RAG. Both are backed by a single engine for graph, vector, and full-text.
A self-building memory graph: rather than hand-modelling every relationship up front, the agent should make use of the relations between nodes that it builds automatically as it works.
Grounding through structure: retrieval that traverses real relationships, so answers are anchored in how things actually connect.
Token efficiency by design: pull the relevant subgraph, not a broad similarity sweep.
Pace: stand up new storage patterns quickly, without long migrations slowing the team down.
Why did Cobrainer choose SurrealDB?
SurrealDB gave Cobrainer graph, vector, and full-text in a single engine, all queried through SurrealQL - so the agentic use case didn't need pgvector or OpenSearch sitting alongside their database. (Their existing RDS Postgres stayed exactly where it was, doing the job it already did well.)
A few things made the build land the way they wanted:
One engine, queried one way. Documents, graphs, vectors, and full-text all live in one store - schemaless and schemafull side by side - and all reachable through SurrealQL. The agentic case added no new systems to operate.
Graph-based agent memory that builds itself. SurrealDB stores the agent's memory and its session checkpoints. As the agent works, it automatically creates the relations between the nodes it writes - so the memory graph forms on its own, and the agent can later traverse those connections instead of re-deriving them. The team described a multi-layered, graph-based memory model, and the thing that surprised them was how fast it came together.
A Rust-native agentic graph RAG. Cobrainer built the graph RAG natively in Rust on SurrealDB's Rust SDK, combining graph traversal and vector similarity in a single query. That's the piece that replaced the old S3-and-OpenSearch RAG - letting the agent walk relationships and rank by similarity in one round trip instead of orchestrating across services.
Managed, and inside the EU boundary. Because this is HR data, residency isn't optional. SurrealDB Cloud let a lean team run the engine as a managed service with EU-region data residency, keeping everything inside the boundary they're required to maintain.
The results
Cobrainer went from evaluation to a customer-facing production deployment in roughly three months. As of August 2026, that deployment is live. Measured against their previous S3-and-OpenSearch pipeline, the team reports three changes.
Better accuracy: grounding the agent in real graph relationships, rather than loose vector matches, made its responses more reliable.
Lower token cost per call: fetching only graph-relevant context - instead of a broad vector sweep - trimmed the tokens going into each prompt.
A flexible platform for what's next: graph-based agent memory and a Rust-native agentic graph RAG, both on one engine, ready to absorb new use cases without another round of stack expansion.
"As a startup, we didn't want to fragment our stack every time we add a capability. For our agentic graph RAG, the alternative was weighing Postgres with pgvector and search extensions against bolting on OpenSearch - instead we got graph, vector, and full-text from one engine. What surprised us was how quickly we stood up a multi-layered, graph-based memory model for our AI agent, with SurrealDB handling its memory and session checkpoints. And SurrealDB Cloud kept all of it inside our EU data boundary."
Daniel Alker, Senior Cloud Platform Engineer, Cobrainer
The takeaway
Giving an agent a memory doesn't have to mean giving it another database. Cobrainer's story is a small proof of a larger idea. When one engine handles graph, vector, and full-text together, and the agent can build its own memory graph on top of it, the "right" architecture stops being a collection of specialised services. It starts being a single query.
Start with SurrealDB Cloud or explore the docs.
