The agent remembers across turns or sessions
Past statements influence what the agent considers now.
recall(user_id, query)
Cross-session
Use cases
For agents that book, refund, schedule, and update accounts.
Use ContextDB when an agent moves from answering to doing. Put an evidence and policy decision before the booking, credit, account change, calendar commitment, or workflow mutation.
remembered evidence × policy → act | ask | abstain → host enforcement
Actions by workflow
Put a memory check before the consequential action.
-
A caller can revise, speculate, and contradict an old preference. Keep the conversation fluid while evaluating the booking separately.
appointment.book → act | ask | abstain -
Before issuing a credit or changing a plan, check whether the memory came from the customer, an agent inference, or another source.
credit.issue · plan.change → policy -
Scheduling
Ask when a time is stale or tentative
A remembered time can help the conversation without authorizing a new calendar commitment. Confirmation resolves the specific slot.
calendar.commit → confirm or pause -
Evaluate memory before the host updates a CRM, closes a ticket, or sends a downstream command.
account.update → decision → host action
When to use ContextDB
Use ContextDB when remembered context can affect a real action.
The next step changes a system or commitment
The agent does more than generate text for a person to review.
book · refund · update · close
Host tool
You need a reason after the fact
An operator must be able to connect the proposed action to evidence and policy.
decision → evidence IDs + policy + reason
Traceable
If your agent only needs relevant text for a draft, ordinary retrieval may
be enough. ContextDB is for remembered context that can affect permission
to act.
Pre-action check
Before the agent changes anything, evaluate one exact action.
Use ordinary recall for response context. Use
recall_for_action for the proposed side effect, then make
the host enforce the advisory outcome.
evidence = recall_for_action(
user_id="caller-1",
query="change the appointment"
)
match evidence.outcome:
case "act": perform_change(evidence.memories)
case "ask": request_confirmation()
case "abstain": stop_and_escalate()
- act
- Evidence clears policy. The host may continue under its own authorization rules.
- ask
- A named fact needs confirmation. The host pauses and asks for it.
- abstain
- No memory may support the action. The host stops or escalates.
POST /v1/recall_for_action
{
"decision_id": "scheduling-fixture",
"request": {
"action": "appointment.reschedule",
"proposed_day": "Friday"
},
"outcome": "ask",
"policy_version": "default",
"evidence_ids": [
"confirmed-thursday",
"tentative-friday"
],
"source": "user_stated",
"confidence": 0.40,
"confirmation": "required",
"host_next_step": "request_slot_confirmation"
}
The source and confidence values are fixture data. Confirmation records attestation, not objective truth.
The application owns the action boundary.
ContextDB advises. The customer host enforces. The host owns tool credentials, business authorization, and the final mutation in the system of record.
Build the full workflow
Use a different path for direct facts, conversations, and business data.
Known application fact
remember(source, confidence, content)
Write the exact sourced fact your host already knows. Use the memory API →
Completed conversation
structured turns → propose or commit job
Submit completed turns through the asynchronous path. Use Formation →
Customer-context table
preview → backfill → checkpoint → increment
Move selected records through a bounded source worker. Use Managed Sources →
Release candidate
suite → run → diff → exit
Compare deterministic recall and action cases with a pinned baseline. Use Memory CI →
Pick the one action you would hate to get wrong.
Start with the exact memory that should be allowed to support it.