Prajana AI · memory platform
Smara records what your agents do, then consolidates it in the background into durable facts and a queryable knowledge graph. Every call after that starts with context instead of starting over.
Episodic ledger
Semantic memory + graph
confidence 0.93 · valid_from 2026-01-14
One call
A single request assembles working memory for the turn: relevant facts, the graph paths that connect them, the procedures that apply, and a token count you can budget against. Every fact comes back with its confidence, its validity window, and the sessions it was derived from.
curl "$SMARA_API_URL/v1/context" \
-H "Authorization: Bearer $SMARA_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"agent_id": "support-copilot",
"user_id": "user:8871",
"query": "when does this account renew?",
"token_budget": 2000
}'{
"facts": [
{
"text": "acme's enterprise plan renews 2026-03-01",
"confidence": 0.93,
"valid_from": "2026-01-14T09:12:00Z",
"source_sessions": ["sess_9f21", "sess_a077"]
}
],
"graph_paths": [
"user:8871 -works_at-> org:acme",
"org:acme -subscribes_to-> plan:enterprise"
],
"skills": ["renewal_escalation@v4"],
"tokens_used": 1174
}Four memory pillars
Flattening everything into one vector index is why agents feel amnesiac — a policy, a transcript and a fact have nothing in common except that they are text. Smara separates them by lifetime and by write path.
Ephemeral · per request
The context actually sent to the model on this call: system prompt, scratchpad, recent turns, and whatever long-term memory earned its place. Assembled fresh against a token budget — and never the source of truth.
Versioned · human-approved
How the agent should act: skills, SOPs, playbooks, conditional policies. Every change lands as a new version, and going live goes through human approval.
Durable · typed · queryable
Durable facts plus a real property graph over them — entities, typed relationships, temporal validity, confidence, provenance, supersession. Retrieval is hybrid: vectors find candidates, the graph finds what they connect to.
Append-only · ledger
The record of what actually happened: session transcripts, tool calls, outcomes. Nothing is edited in place, which makes it both an audit trail and the raw material consolidation runs on.
Consolidation pipeline
The hard part of agent memory is not storing things. It is deciding, later and calmly, which of the thousands of things that happened are worth keeping — and what to do when the new answer contradicts the old one.
Smara does that as a background job, off the request path. Your agent writes episodes and moves on; consolidation reads them, distills them, and reconciles the results against the existing graph. Nothing in the hot path gets slower as memory gets deeper.
Turns, tool calls, results and outcomes append to the episodic ledger as they happen. No judgement call at write time — the agent does not have to guess what will matter later.
A background worker reads new episodes, extracts candidate facts and typed relationships, and scores each one for confidence with its provenance attached.
Candidates are merged against what is already known: supersede a stale fact, extend a validity window, or flag a genuine contradiction for review instead of silently overwriting.
API-first · multi-tenant
There is no privileged path into Smara that you cannot take yourself. The developer portal is built on the same public API your agents call, with the same keys and the same tenant boundary.
Every capability is a documented REST endpoint under a versioned prefix. No SDK-only features, no private control plane.
Scoped API keys issued from the portal, shown once at creation, revocable in one call. Key material is stored hashed, never in plaintext.
Every record in every store carries its tenant, user and agent scope. Cross-tenant reads are not a configuration option.
Create a tenant, issue an API key, and make your first /v1/context call. The API reference in the portal is generated from the running service, so it cannot drift from what the API actually does.