Most AI tools forget everything when you close the window. Curia does not. All state — conversation history, facts about people, decisions made, and relationships between entities — lives in Postgres and survives process restarts, server reboots, and upgrades. When you come back to a topic days or weeks later, Curia picks up where it left off. It also knows which facts it should trust less as time passes, so stale information doesn’t mislead it.Documentation Index
Fetch the complete documentation index at: https://curia.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
Four memory tiers
Curia’s memory system has four distinct tiers, each serving a different purpose and operating at a different timescale.Working memory
Working memory holds the active context for an ongoing conversation or task. Every turn in a conversation, every intermediate tool result, and every in-progress calculation lives here, scoped to a task ID. When a conversation goes quiet, working memory expires after a configurable TTL (default: one hour of inactivity). For long-running persistent tasks, it is kept alive across execution bursts. Working memory is stored in Postgres — not in the process. If the server restarts mid-task, the agent reloads exactly where it left off. Context summarization — when a conversation exceeds 20 turns, the oldest turns are summarized into a condensed narrative and archived. The originals remain in Postgres but are not loaded into the LLM’s context window. The summary preserves key decisions, entities discussed, and any commitments or action items.The Bullpen
The Bullpen is a structured, threaded discussion space for inter-agent coordination and CEO participation. Any agent can open a thread addressed to other agents. Every exchange flows through the bus with the same security model as any other event.- You can observe all threads via the dashboard or HTTP API SSE stream
- You can intervene by sending a message to any thread from any channel — it arrives as a user-typed
agent.discussevent withsender: "user" - You can start threads — ask a question that multiple agents contribute answers to
Entity memory
Entity memory is a specialized query pattern over the knowledge graph, optimized for answering “what do I know about this person or thing?” An agent asks for the entity by name and gets back connected facts with confidence scores and freshness indicators. Facts are stored asfact nodes in the knowledge graph, linked to their subject entity by edges. The query layer assembles the most relevant, highest-confidence facts and surfaces them in priority order. “The CEO prefers morning meetings” and “the CEO’s current focus is Q3 fundraising” are both entity memory facts — one permanent, one that should fade if it isn’t recently confirmed.
Knowledge graph
The knowledge graph is Curia’s long-term memory: a network of nodes and edges stored in Postgres, traversable across arbitrary relationship chains.Nodes
People, organizations, projects, events, decisions, and concepts — each with a label, properties, and an embedding for semantic search.
Edges
Typed relationships between nodes —
works_on, attended, decided, relates_to, and others that Curia infers from context.Entity facts
Configurable facts about nodes — “prefers morning meetings”, “board meetings are quarterly, first Thursday” — with confidence scores and decay classes.
Decisions
Explicit decision nodes linked to the people who made them, the projects they concern, and the events where they occurred.
| Relationship type | Meaning |
|---|---|
works_on | A person is working on a project |
decided | A person or group made a decision |
attended | A person attended an event |
relates_to | A general association between two nodes |
reports_to | Organizational hierarchy |
invested_in | An organization or person invested in another |
query-relationships skill to look up all stored relationships for any entity by name.
Temporal awareness
Not all facts age the same way. Curia assigns every node and edge adecay_class that controls how confidence should evolve over time:
| Decay class | Half-life | Examples |
|---|---|---|
permanent | Never decays | Legal name, date of birth, birth city |
slow_decay | ~180 days | Employer, job title, city of residence |
fast_decay | ~21 days | Coffee preference, current project focus, travel schedule |
created_at— when it was first recordedlast_confirmed_at— the last time evidence reinforced this factconfidence— a 0–1 float that decreases over time based on decay classsource— which agent, channel, or interaction created it
last_confirmed_at updates and confidence rises again. Stale facts lose confidence over time rather than being trusted indefinitely.
How Curia populates the graph
The knowledge graph grows automatically from several sources:- Emails: Participant extraction from From/To/CC headers auto-creates contact nodes and infers organizational relationships
- Conversation context: When you mention people, projects, or decisions in conversation, Curia extracts and stores structured facts
- Explicit corrections: You can tell Curia new facts directly — “Mark Chen is now our CFO” — and it updates the graph with proper source attribution
- Calendar events: Attendees and events create and reinforce relationship nodes
Memory validation
Agents writing to memory pass through validation gates designed to prevent pollution of the knowledge graph. Deduplication — before creating a new fact node, the system checks for existing nodes about the same entity with a similar label (cosine similarity > 0.92). If a near-duplicate exists, the system updateslast_confirmed_at and merges properties instead of creating a duplicate.
Contradiction detection — if a new fact contradicts an existing one (for example, “the CEO lives in Toronto” when “the CEO lives in Kitchener” already exists), the system compares confidence scores:
- New fact has lower confidence → write rejected, conflict logged
- New fact has higher confidence → existing fact updated, old value preserved in
properties.previous_valuesfor audit - Equal confidence → flagged for your review via the alert channel
Semantic search
Key facts and node descriptions are embedded usingtext-embedding-3-small (1536 dimensions) and stored in a pgvector HNSW index. This powers natural-language queries across the knowledge graph even when exact keywords don’t match:
Semantic search requires
OPENAI_API_KEY to be set. Without it, the graph browser falls back to exact-match label and property search.The knowledge graph browser
Curia ships with a web-based knowledge graph browser for exploring everything it has learned.Accessing the browser
Open http://localhost:3000 in your browser. You’ll be prompted for yourWEB_APP_BOOTSTRAP_SECRET — the value you set in .env when you configured Curia. After authenticating, the knowledge graph browser is available at /kg.
If
WEB_APP_BOOTSTRAP_SECRET is not set in your environment, the knowledge graph API is intentionally disabled. Set the variable and restart Curia to enable it.Browsing and searching
The main graph view shows nodes and their relationships. Use the search bar to find specific people or topics:- Search by name: Type a name or partial name to find matching nodes
- Filter by type: Filter to
person,organization,project,event,decision, orconcept - Select a node: Click any node to center the view on it and expand its neighbors
depth parameter in the URL controls traversal depth if you want to explore further.
Click a person or organization node to open its entity memory panel, showing all recorded facts with confidence scores, sources, and decay classes.
Correcting the graph
The graph isn’t always right. When Curia records something incorrect, tell it directly:delete-relationship to remove incorrect edges and updates entity facts when you provide corrections. Every correction is audit-logged with your confirmation as the source.
When Curia detects a potential duplicate contact — two nodes that appear to represent the same person — it surfaces the conflict and walks you through a merge decision before making any changes. It never auto-merges without your confirmation.
What persists across restarts
Everything. Curia uses no in-process state that is lost on restart:Conversations
Conversations
Working memory is in Postgres. An active conversation resumes exactly where it left off after a restart, including tool results and intermediate calculations.
Long-running tasks
Long-running tasks
Persistent tasks store their progress, intent anchor, and remaining error budget in Postgres. The scheduler resumes them on the next execution burst.
Knowledge graph and entity memory
Knowledge graph and entity memory
All nodes, edges, embeddings, confidence scores, and temporal metadata are in Postgres. The graph grows indefinitely across deployments.
Bullpen threads
Bullpen threads
All inter-agent discussions are persisted in Postgres. Pending threads are surfaced to agents on their next activation.
Autonomy score and history
Autonomy score and history
The current autonomy score and its full change history are persisted in Postgres. Score changes take effect immediately — no restart needed.
Curia requires PostgreSQL 16 or later with the pgvector extension. All memory tiers share the same Postgres instance. See the installation guide for database configuration.
Agents
See how agents load and write to memory during task execution.
Dreaming
How the dream engine processes memory overnight — decay passes, confidence updates, and autonomy adjustments.