--- title: "How Cobrainer built graph-based agent memory on one engine" description: "Cobrainer runs graph-based agent memory and a Rust-native agentic graph RAG on SurrealDB, replacing a separate vector store and search engine." url: https://surrealdb.com/blog/how-cobrainer-built-graph-based-agent-memory-on-one-engine date: 2026-08-25 authors: "Ignacio Paz" --- # How Cobrainer built graph-based agent memory on one engine ![How Cobrainer built graph-based agent memory on one engine](https://cdn.surrealdb.com/jap94xlft9t9h91iiiq701mv.auto) 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](https://www.cobrainer.com/), 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](https://surrealdb.com/cloud)** or explore **[the docs](https://surrealdb.com/docs)**.