Quickstart

Two parts. Part 1 works right now — live caller memory and enrichment in five minutes. Part 2 is the governance engine in beta — shown so you can see where the substrate is headed, clearly labeled.

If you haven't installed yet, do Installation first. You need MNEMIX_API_KEY exported.

Part 1 — Live today: recall a caller

Step 1 — Cold recall

The first call on a number creates the contact and fires real-world enrichment (Trestle, Twilio Lookup, Baylio) in the background:

mnemix recall +15551234567

Or over HTTP — this is the production pre-call hook:

curl -sS -X POST https://mcp.mnemix.ai/v1/recall_and_enrich \
  -H "Authorization: Bearer $MNEMIX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "phone_number": "+15551234567", "trigger": "answered", "session_id": "call_demo1" }'

The response carries caller, memory, enrichment (person / company / phone), and a measured timing_ms — a real field on every response, never a published benchmark.

Step 2 — Write the call back

curl -sS -X POST https://mcp.mnemix.ai/v1/calls/end \
  -H "Authorization: Bearer $MNEMIX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "phone_number": "+15551234567",
    "session_id": "call_demo1",
    "transcript": [
      { "role": "user", "text": "I want to book an appointment for next Tuesday.", "ts_ms": 0 },
      { "role": "agent", "text": "You are booked for Tuesday at 10 AM.", "ts_ms": 18000 }
    ],
    "duration_s": 42,
    "outcome": "appointment_booked"
  }'

Step 3 — Recall again

mnemix recall +15551234567

Same number, warm path — the card now shows a returning caller with history, served from cache. That loop (recall → act → write back) is the whole voice integration.

Part 2 — The governance engine (beta roadmap)

Everything below is the in-development substrate. The payloads are illustrative of the spec-frozen design — these endpoints are not yet publicly callable. They're documented so you can design against the model; watch the changelog for the beta release.

The finance-reconciliation story shows where this goes. A confirmed opening balance of −$49.98 gets locked as a fact, citing its bank statement as evidence. Locked facts are addressed by entity + fact key (e.g. entity_id: acct_acme, fact_key: opening_balance.2025-08-01) and written through supersession-safe procedures — never raw updates.

When an agent later proposes an action, the gate evaluates it against the active policy bundle:

// validation gate request shape (spec-frozen, beta roadmap)
{
  "proposed_action": {
    "action": "report_opening_balance",
    "value": { "amount": 1200.00, "currency": "USD" }
  },
  "policy_bundle_id": "finance.recon.v0",
  "mode": "high_stakes"
}

// → illustrative verdict
{
  "verdict": "denied",        // allowed | denied | needs_human
  "rule_results": [{
    "rule": "locked_fact_honored",
    "passed": false,
    "expected": { "amount": -49.98 },
    "proposed": { "amount": 1200.00 }
  }],
  "evidence_refs": ["bank-stmt-2025-08"],
  "rerun_hash": "sha256:…"
}

The agent confidently proposed a number the data doesn't support — the failure mode finance auditors lose sleep over — and the gate denied it, citing the exact fact and the evidence behind it. In high_stakes mode that's a hard barrier (the call returns 422); in standard mode it's advisory.

And because every verdict records a rerun_hash pinned to the exact bundle version and facts that were active, any past decision can be re-executed and verified later — the audit guarantee.

What you used

• The live voice surface — recall_and_enrich and calls/end.
• Three substrate primitives (in concept) — locked_facts, evidence_refs, and the validation_gate, arriving in beta.

Next steps

• Core concepts — go deep on each primitive (sidebar).
• MCP server — give any MCP agent these tools natively.