Memory
Agents without memory are stateless functions. Memory makes them systems that learn.
Overview
What is Memory?
Memory is the persistence layer of BIOS™. It stores conversation history, entity state, vector embeddings and relationship graphs — everything an agent needs to maintain context across interactions and improve over time.
An LLM without memory is a stateless function: it processes each request in isolation, forgetting everything that happened before. This is adequate for simple Q&A but fails for any process that requires continuity — a sales agent that forgets previous conversations, a research agent that cannot build on prior findings, a compliance agent that cannot track changes over time.
Memory provides three types of persistence: episodic (what happened), semantic (what is known) and procedural (how things are done). Together, they allow agents to operate with the continuity and accumulated knowledge that enterprise processes require.
Business Value
Why It Matters
Stateless LLMs forget everything between interactions. Memory exists because enterprise processes require continuity — agents that remember past conversations, accumulate knowledge from past outcomes and understand relationships between entities.
Business Challenges Addressed
Agents that ask for information they already received, repeating mistakes and frustrating users.
No accumulated learning — every pipeline runs as if it were the first, with no benefit from past results.
Inability to connect related entities and understand relationships between people, companies and projects.
No temporal reasoning — the agent cannot compare current state to past state because it has no history.
Business Outcomes
Agents with conversation continuity — customers don't repeat themselves, processes don't restart from zero.
Systems that learn from past outcomes — past results inform future decisions.
Relationship-aware intelligence — agents understand connections between entities across the organisation.
Historical context for every decision, enabling trend analysis and temporal reasoning.
Departments That Benefit
The Problem
The Problem
Stateless LLM calls cannot maintain context across interactions, leading to repetitive, inconsistent and forgetful agent behaviour.
No conversation continuity — each interaction starts from zero. The agent asks for information it already received, repeats mistakes it already made.
No accumulated knowledge — the agent cannot learn from past executions. Every pipeline runs as if it were the first.
No relationship awareness — the agent cannot connect related entities, because it has no graph of relationships.
No temporal reasoning — the agent cannot compare current state to past state, because it has no history.
The Solution
The Solution
Memory provides structured persistence for every type of information an agent needs: conversations, entities, embeddings and relationships.
Episodic memory — conversation history and pipeline execution logs. The agent can recall what happened in any past interaction.
Semantic memory — entity state and knowledge entries. The agent can query what is known about any person, company or concept.
Vector embeddings — semantic search over documents, conversations and knowledge. The agent can find relevant information by meaning, not just by keyword.
Relationship graphs — connections between entities. The agent can traverse relationships: 'which leads are connected to this architect?'
Architecture
Architecture
Memory is structured as four specialised stores, each optimised for a different access pattern. All stores are accessed through a unified Memory API.
Architecture Layers
Memory API
Unified interface for all memory operations — read, write, search, graph traversal
Relationship Graph
Entity relationships, dependencies and connections
Vector Store
Semantic embeddings for similarity search and retrieval
Entity Store
Structured records — leads, companies, contacts, knowledge entries
Event Log
Append-only history of conversations, pipeline executions and state changes
How It Works
How It Works
Process Flow
Write — episodic
When a conversation or pipeline execution occurs, the full interaction is written to the Event Log as an immutable record. This includes the agent's reasoning, the retrieved context and the output.
Write — semantic
When an entity is created or updated (a new lead, a new knowledge entry), it is stored in the Entity Store with its full schema. The record is indexed for fast retrieval.
Embed — vector
When text content is stored (documents, conversation messages, knowledge entries), a vector embedding is generated and stored in the Vector Store. This enables semantic search — finding content by meaning, not by keyword.
Connect — graph
When relationships are identified (a lead is connected to an architect, a company is connected to a project), edges are created in the Relationship Graph. The graph enables traversal queries: 'find all leads connected to architects in Zurich'.
Retrieve — context
When an agent needs context, the Memory API performs hybrid search: keyword match on the Entity Store, semantic match on the Vector Store, and relationship traversal on the Graph. Results are merged and ranked by relevance.
Learn — feedback
When a pipeline completes, the outcome is written back to Memory. Future executions can query past outcomes: 'what approach worked for similar leads?' This is how the system learns from its own results.
Benefits
Why It Matters
Business Benefits
Continuity — agents remember past interactions. Customers don't repeat themselves; processes don't restart from zero.
Accumulated intelligence — the system gets better over time. Past outcomes inform future decisions.
Relationship awareness — agents understand connections between entities, enabling sophisticated queries and insights.
Technical Benefits
Hybrid search — keyword + semantic + graph traversal. The agent finds relevant information regardless of how it's phrased.
Event sourcing — the Event Log is append-only and immutable. Full history is reconstructable for any entity or conversation.
Schema-validated storage — entity records are validated against schemas. Memory is structured, not a blob of unstructured text.
Unified API — one interface for all memory operations. Agents don't need to know which store holds what.
Technical Deep Dive
Technical Deep Dive
01Vector Embeddings
When text is stored in Memory, the AI Runtime generates a vector embedding — a high-dimensional numerical representation of the text's semantic meaning. Similar texts produce similar vectors. The Vector Store uses approximate nearest neighbour (ANN) algorithms to find the most similar vectors in milliseconds, enabling semantic search at scale. This is the foundation of RAG — retrieval-augmented generation.
// Semantic search in Memory
const results = await memory.search({
query: "architect specialising in timber construction",
stores: ["vector", "entity"],
top_k: 10,
min_relevance: 0.75
});
// Returns entities and documents whose
// embeddings are semantically similar02Relationship Graph
Entities in BIOS™ are not isolated records — they are nodes in a relationship graph. A lead is connected to an architect, the architect is connected to a company, the company is connected to other projects. The graph enables traversal queries that would be impossible with flat records: 'find all leads where the architect has worked with this builder before' or 'which companies in this region have not been contacted yet?'
03Event Sourcing
The Event Log uses event sourcing — instead of storing only the current state, it stores every state change as an immutable event. The current state is derived by replaying events. This means full history is always available: you can see what an entity looked like at any point in time, who changed it and why. This is critical for audit, debugging and compliance.
FAQ
Frequently Asked Questions
Retention is configurable per workspace and per data type. Conversation history and pipeline logs can be retained indefinitely or purged on a schedule. Entity records persist until explicitly deleted. Vector embeddings are regenerated when the source content changes.
Keyword search matches exact words. Semantic search matches meaning. A search for 'timber construction' will find documents about 'Holzbau' (German for timber construction) because their vector embeddings are similar, even though no words match. Memory performs both in parallel and merges results.
Yes. All data in Memory is accessible through the Memory API and SDK. Entity records can be exported as JSON or CSV. The Event Log can be streamed for external processing. Data ownership is yours — the platform does not lock you in.
Embeddings are generated by the AI Runtime using embedding models (e.g., text-embedding-3-large). The model is configurable per workspace. Embeddings are regenerated automatically when the source content changes or when a better embedding model becomes available.
Memory is the storage layer. Knowledge Hub is the retrieval layer. Memory stores documents, embeddings and entity records. Knowledge Hub uses Memory's vector store and relationship graph to retrieve relevant context for agents. They are separate modules with distinct responsibilities.
Want to see Memory in action? Explore how enterprises use BIOS™ to build production AI systems.