Agents need more than memory — they need context to reason and actions to execute, today stitched from disconnected vector DBs, caches, and audit logs. Areev unifies them in one governed query, with importance scoring, temporal reasoning, biological decay, and cryptographic erasure native.
These capabilities don't exist in any existing database. Areev was built around them — not on top of them.
Vector DBs rank by similarity. Caches don't rank at all. Neither understands that some memories matter more than others.
→ Not in Pinecone, Weaviate, RedisWhen something happened changes what it means. No existing database can answer "what did the user believe about X, as of Tuesday?"
→ Not in Postgres, Elasticsearch, QdrantMemories that aren't reinforced should fade. No database has a native forgetting curve — you'd need background jobs scanning every store.
→ Not in any existing databaseOne declarative query fuses hexastore, BM25, vector, and temporal recall — engine-optimised, policy-aware, with provenance built in. Application code stops doing retrieval glue.
→ Not in any existing databaseA versioned, governed agent definition — memory, context, tools, LLM config, and policy posture in one signed object. Publish, diff, roll back. Compliance travels with the harness.
→ Not in any existing databaseA memory write needs to store the fact, its embedding, its timestamp, and its importance score atomically. With assembled parts, any can fail independently.
→ Requires distributed transactions that vector DBs, caches, and object stores don't support together.When someone writes in, Areev runs a CAL query — assembling the agent's harness, its memory, and the catalog of actions — so the model can think it through and reply.
Plain words. Unstructured. Human.
Memory, context, and actions — one prompt.
Loops until the goal is met.
lookup_shipment(order_id) Grounded answer. Human voice.
CAL is how agents talk to Areev. Declare what context you need across every grain type — beliefs, goals, events, reasoning — and CAL composes, budgets, and formats it in a single round-trip. No N+1 queries. No client-side stitching.
ASSEMBLE ticket_context FROM task: (RECALL goals ABOUT $session WHERE status IS OPEN LIMIT 1), messages: (RECALL events ABOUT $user RECENT 5 WITH annotate_relative_time), workflow: (RECALL workflows WHERE trigger = "ticket_classification"), knowledge: (RECALL beliefs WHERE tags INCLUDE ["product", "support"] LIMIT 10 WITH rerank), user: (RECALL beliefs ABOUT $user WHERE relation IS PREFERENCE WITH conflict_resolution), goals: (RECALL goals ABOUT $user RECENT 3), tools: (RECALL actions LIMIT 10), history: (RECALL actions ABOUT $user RECENT 5 WITH dedup) BUDGET 2500 tokens WITH provenance FORMAT TEMPLATE ticket_brief
## Task Classify the inbound ticket and route it to the right queue within SLA (opened 4m ago) ## Messages **agent** (4m ago): Did the rate-limit issue start before or after your plan upgrade? **user** (3m ago): After. **agent** (3m ago): Got it — can you share the exact error you're seeing? **user** (2m ago): API returning 429s even after upgrading to Pro yesterday. ## Workflow classify → (check_plan, check_product) → assign_severity → route → notify ## Knowledge - Pro plan rate limit: 1000 req/min (0.98) - Plan upgrades take up to 2h to propagate (0.95) - Gateway caches tier info 30m after plan change (0.88) ## User Prefers email · SLA-sensitive account ## Goals Migrate Starter → Pro · Integrate API to production ## Tools classify_ticket · route_ticket · escalate_ticket · check_plan_status · get_rate_limit_config ## History check_plan_status → "Pro active since 2026-04-16" classify_ticket → "billing, P2" route_ticket → "billing-eng queue"
Classify the inbound ticket and route it to the right queue within SLA (opened 4m ago)
agent (4m ago): Did the rate-limit issue start before or after your plan upgrade?
user (3m ago): After.
agent (3m ago): Got it — can you share the exact error you're seeing?
user (2m ago): API returning 429s even after upgrading to Pro yesterday.
classify → (check_plan, check_product) → assign_severity → route → notify
Prefers email · SLA-sensitive account
Migrate Starter → Pro · Integrate API to production
classify_ticket · route_ticket · escalate_ticket · check_plan_status · get_rate_limit_config
## Task {{task.content}} _({{task.opened_at | relative}})_ ## Messages {{#each messages}} **{{actor}}** _({{created_at | relative}})_: {{content}} {{/each}} ## Workflow {{workflow.content}} ## Knowledge {{#each knowledge}} - {{content}} _({{confidence | percent}})_ {{/each}} ## User {{#each user}}{{object}}{{^@last}} · {{/@last}}{{/each}} ## Goals {{#each goals}}{{content}}{{^@last}} · {{/@last}}{{/each}} ## Tools {{#each tools}}{{tool_name}}{{^@last}} · {{/@last}}{{/each}} ## History {{#each history}} **{{tool_name}}** → "{{content | truncate 40}}" {{/each}}
Instead of replaying raw transcripts, Areev stores semantic grains — the compressed, typed residue of every meaningful interaction. 10 grain types cover the full cognitive surface.
Most agent stacks treat compliance as an audit trail you read after something goes wrong. Areev enforces it on the write path — at the engine, before the grain lands.
Violations are blocked at the engine, before the grain lands.
Every recall carries what it returned, and what it excluded — with reasons.
Apply GDPR, HIPAA, and SOX to one tenant. Strictest rule wins.
Human → agent → sub-agent, capped at depth 5. Audited at every access.
Merkle-signed envelopes. Verify a grain belongs without trusting the sender.
Destroy the key. The grain becomes mathematically unreadable.
The human mind, as a primitive. Starting now.