The memory guard between recall and action

Decision-safe memory for agents that take action.

Your agent remembers a preference. Should it book, ask, or stop? ContextDB returns trusted evidence for the action and records why the decision was made.

Try the open SDK See the decision loop

SDK available Cloud alpha No credit card. Keep your current database.

decision trace dec_01JQ7…

query
“Book the caller's next appointment.”

ask A low-confidence wish conflicts with a confirmed preference.

candidate “I might maybe come on Friday instead.” hold

trusted “I'd like to come in Thursday afternoon.” use

policy user_stated · confidence ≥ 0.9 v0.3

The shift

Retrieval was enough when agents only talked.

Agents now book visits, issue credits, update records, and commit calendars. A relevant memory can shape a sentence. It should not automatically authorize an action.

Gate the action

recall_for_action returns memory that passes policy. If the evidence is weak or conflicting, the answer is ask or abstain.

output → act | ask | abstain

Show the evidence

Each decision carries its evidence IDs, policy version, reason, user partition, and request ID for incident review.

decision → evidence[] + policy + reason

Keep correctness open

The trust model and evals live in the Apache-2.0 SDK. Cloud operates that model for teams that do not want to run it themselves.

open SDK → same trust bar → operated cloud

The object

A wish can be remembered without becoming an instruction.

This representative alpha scenario stores both statements. The low-confidence Friday wish gets requires_confirmation: true. Before booking, recall_for_action returns only the trusted Thursday fact.

Read the trust rules →

# tentative preference
remember({
  "content": "I might maybe come on Friday instead.",
  "source": "user_stated",
  "confidence": 0.4,
  "action_relevant": true
})
→ requires_confirmation: true

# previously confirmed preference
remember({
  "content": "I'd like to come in Thursday afternoon.",
  "source": "user_stated",
  "confidence": 0.95
})
→ trusted by policy

recall_for_action("book the visit")
→ Thursday only

Built for consequential moments

Memory for agents whose next step changes something.

ContextDB is for teams building agents that move beyond conversation into bookings, credits, account changes, and workflow mutations.

Voice agents

Confirm the caller's current intent before booking, rescheduling, refunding, or escalating during a live conversation.

Memory for voice agents →

Support agents

Separate account facts from inferred preferences before issuing a credit, changing a plan, or closing a case.

Memory for support agents →

Scheduling agents

Treat a confirmed time as evidence and an old, tentative preference as a reason to ask again.

Explore scheduling →

Workflow agents

Put a policy decision between remembered context and a mutation in your system of record.

Explore workflows →

Fits your stack

Beside your database, not instead of it.

ContextDB complements Postgres, Supabase, and Hasura. It does not replace them. Orders, users, and inventory stay in your system of record. ContextDB answers a different question: what may the agent treat as true enough to act on, and who vouched for it?

See where ContextDB fits →

Postgres Supabase Hasura Your agent host

system of record
orders · users · inventory
            │
            ▼
ContextDB decision-safe memory
memories · evidence · decisions · confirmations
            │
            ▼
your host enforces
book · refund · update · abstain

Put a decision between memory and action.

Start locally with the open SDK. Existing cloud alpha users can sign in to inspect decisions and evidence.

Try the SDK Open console