AI agentsetups I see at work rely on the "vector store and pray" method. You embed everything, run a similarity search, and hope the LLM doesn't hallucinate based on a chunk of text that was semantically close but logically irrelevant. We've seen this firsthand—it leads to bloated prompts and high token costs because you have to stuff in five "maybe" relevant chunks just to get one "actually" relevant answer.
I've been looking into how Cobrainer handled this for their skills-intelligence platform, and their approach to agent memory is a great case study for anyone trying to move beyond basic RAG. Instead of a flat vector list, they're using a graph-based memory where the agent actually builds relationships between nodes as it operates.
The most interesting part is that they didn't add a dedicated graph DB or a separate search engine to their stack. They shifted everything to SurrealDB, which handles vectors, full-text search, and graph relations in one place using SurrealQL. This is a massive win for deployment because you aren't managing a fragmented pipeline of S3, OpenSearch, and a vector plugin.
The shift from flat to structured memory #
The problem with standard vector retrieval is that it's "flat." If you're querying for a specific skill and a person, a vector search might give you everyone who mentions that skill, but it won't necessarily give you the specific organizational relationship between them. Cobrainer needed grounded answers, not approximations.
By using a graph structure, they achieved a few specific technical wins:
- Token Efficiency: Instead of a broad similarity sweep that pulls in irrelevant noise, they pull a specific subgraph. This keeps the prompt lean and reduces the cost per call.
- Self-Building Memory: The agent doesn't just read from a static graph; it writes to it. As the agent works, it creates relations between nodes. This means the memory graph evolves organically based on the agent's interactions.
- Unified Querying: Since they use SurrealQL, they can query documents, graphs, and vectors without switching contexts or languages.
How the implementation looks in practice #
For those of us doing a deep dive into LLM agent architecture, the "single engine" philosophy is the real takeaway. When you have your session checkpoints and memory living in the same store as your graph, you eliminate the latency and complexity of syncing data between a primary database and a vector index. In their setup, they kept their existing RDS Postgres for standard workloads but offloaded the agentic graph RAG to SurrealDB. This allows the agent to traverse real connections—following a path from a "Role" node to a "Skill" node—rather than just guessing based on cosine similarity.
If you're building an AI workflow from scratch, I'd suggest looking at a multi-layered memory model. Having a place where the agent can store "checkpoints" and "relational memories" in a graph format makes the agent significantly more reliable. It transforms the memory from a simple search index into a structured knowledge base that the agent actually manages. It's a much cleaner deployment pattern. No more fighting with pgvector versions or managing OpenSearch clusters just to get a decent retrieval rate. Just one engine, one query language, and a memory graph that actually makes sense.