Credits and refunds
Verify the reason and user-stated instruction before changing a financial record.
action → issue_credit
Host enforced
Memory for support agents
Customer memory for AI support agents.
Carry selected customer history across chat, email, and phone. Continue the case with context, then check current evidence before the host issues a credit, changes a plan, cancels service, or closes a ticket.
customer history → evidence policy → act | ask | abstain
Evidence classification
Use a hunch to improve the reply, not to change the account.
“The customer sounds frustrated” can shape tone. It is not the same as “the customer asked to cancel.” Source, confidence, and confirmation stay attached so policy can treat them differently.
recall("cancellation intent")
{
"content": "Customer may want to cancel",
"source": "agent_inferred",
"confidence": 0.62,
"confirmation": "required"
}
{
"content": "Cancel at the end of this cycle",
"source": "user_stated",
"confidence": 0.98,
"confirmed": true
}
- conversation
- Inferred context may shape the reply. A direct instruction continues the case.
- action
- Inferred frustration is held from cancellation and credit tools. Evaluate a confirmed instruction against the active cancellation policy.
These values are explanatory fixture data, not measured support performance. An API or MCP confirmation records authenticated project-credential context against one scoped memory. It does not authenticate the end user. The customer host authenticates the end user and retains any end-user attestation. A Console confirmation records operator context. No confirmation proves objective truth.
Support action outcomes
Follow up on interest without acting on a guess.
A remembered wish can start a follow-up. The host changes billing only after the customer gives a direct instruction that clears policy.
Act / plan change
confirm → recall_for_action("change billing") → act
The customer asks about annual billing, later says yes to the change,
and the host applies account authorization before plan.change.
Ask / invoice correction
invoice.correct(invoice_id) → ask
“Fix the invoice” does not identify the accepted correction. The host asks for the disputed line or amount before mutating the ledger.
Abstain / goodwill credit
credit.issue(account_id) → abstain
Frustration is agent_inferred, not authority to move
money. The host skips issue_credit and routes the case
through the approved credit path.
Pre-action check
The account mutation waits for an advisory decision.
ContextDB evaluates remembered evidence under a named policy. The support host decides whether and how to continue under its own business rules.
- act
- Evidence clears memory policy. The host still checks account authorization.
- ask
- A specific fact needs confirmation before the support tool can run.
- abstain
- No memory may support the mutation. The host skips it or escalates.
POST /v1/recall_for_action
{
"decision_id": "support-credit-fixture",
"request": {
"action": "credit.issue",
"account_id": "synthetic-account"
},
"outcome": "abstain",
"reason": "inferred frustration is not action authority",
"policy_version": "default",
"evidence_ids": ["inferred-frustration"],
"source": "agent_inferred",
"confidence": 0.62,
"confirmation": "required",
"host_next_step": "skip_credit_and_route_case"
}
abstain → do not issue credit → use authorized case path
ContextDB advises. The customer host enforces. ContextDB cannot call or block the billing tool by itself.
The support host owns credentials and business authorization.
The host checks the advisory outcome before it invokes billing, CRM,
help-desk, or account tools. On ask or abstain,
it does not perform the proposed mutation.
Before changing the account
Check what the customer said before issuing credits or changing plans.
Plans and permissions
Distinguish a request, a historical preference, and an agent inference before mutating account state.
action → change_plan
Host enforced
Resolution and closure
Keep the evidence that justified an automated resolution so an operator can review it later.
decision → reason + evidence IDs
Reviewable
Action and host boundary
Keep your help desk, CRM, and billing system.
Those systems remain authoritative for customer and account state. ContextDB adds cross-channel memory and an advisory decision before the support host changes them.
- Current state Help desk / CRM / billing customer + account records →
- Memory decision ContextDB evidence × policy → act | ask | abstain
- Enforcement Customer support host authorization + business rules →
- Mutation System of record credit | plan | cancel | close
The support host owns enforcement. Review the database ownership boundary → Read the Intercom Fin memory integration guide →
Support-agent FAQ
What support teams should know.
Does ContextDB decide our refund policy?
No. Your team defines business rules and host enforcement. ContextDB evaluates remembered evidence under the active trust policy.
Do we keep our help desk and CRM?
Yes. ContextDB complements those systems by tracking what an agent remembers and why that memory was or was not used for an action.
What happens when evidence is missing?
The result is ask or abstain. The host
requests a specific confirmation or routes the case to a person.
Test one refund or plan change.
Pick a refund, plan change, or cancellation and add a memory check before it.