Never Ask Twice

Inspiration

Support is stateless by default. Every new session, a customer re-establishes who they are, what they're running, and what broke last time, and the agent re-derives context it has seen before. We wanted an agent that walks into the second conversation already knowing the customer, without turning that memory into a surveillance liability. "Never ask twice" is the whole promise: remember what matters, prove where it came from, and let the customer revoke it.

What it does

Never Ask Twice is a B2B customer-support agent that remembers each customer's context across sessions. Invent a customer it has never seen, describe their setup in plain prose, and close the session: Qwen distills durable facts from the transcript and writes them to memory. When that customer returns, the agent already knows their plan, integrations, SLA, and escalation path, so they never re-explain. You can reproduce the full cycle in about thirty seconds with a single curl against the live deployment, or run our deterministic regression harness (pnpm eval) that verifies forgetting and supersession against falsifiable assertions. Every recalled answer surfaces the exact facts it used, sourced to the session they came from.

How we built it

Three-tier memory: working (the live turn), episodic (recent interactions), and semantic (durable facts about the customer). Qwen does the distillation: after a session it reads the transcript and extracts durable facts into a constrained predicate schema (customer, plan, integration, SLA, open issue), which promote into semantic memory and are recalled on the customer's next contact. Memory is exposed over MCP so any agent can read and write it. The recall trace surfaces the actual cited facts behind each answer, not UI state, so you can audit exactly why the agent said what it said. Deployed on Alibaba Cloud Function Compute, with Qwen powering both distillation and response.

Challenges we ran into

The hard part was never recall, it was making recall trustworthy. Three bugs, each caught and fixed:

• A test double let our distillation write-path pass every test while persisting nothing real: the single most important mechanism was green and hollow. We rebuilt it to validate each candidate fact against the schema and fail loudly on an unguarded parse.
• Tenant isolation was enforced on the read path but not the write path: a fact could be written under the wrong tenant and only surface on recall. We moved the check to the write boundary.
• The recall panel reflected presentation state instead of the real cited-facts payload, which would have made the trace a lie. We tied it to the actual facts the answer used.

And one we're proud of: our own clean-room boundary scan blocked our final submission push when it caught a secret-manager reference in a demo file. We removed the reference rather than bypass the guard. A guardrail that only catches other people's mistakes isn't one; ours fired on its authors, on deadline, and held.

What we learned

Governed recall is the product, not recall. Memory in a support context has to be scoped to one tenant, sourced to a real interaction, revocable, and current, or it's a liability, not a feature. And a passing test suite is not proof: the most dangerous failure we hit looked completely green.

What's next for Never Ask Twice

Forgetting at scale (TTL and decay on stale facts), an async multi-tenant promotion pipeline so distillation never blocks a live turn, relevance-differentiated ranking beyond the current predicate set, and structural rather than merely enforced tenant isolation. The full engineering write-up, bugs included, is linked below.

Built With

• alibaba-cloud-function-compute
• model-context-protocol-(mcp)
• next.js
• node.js
• postgresql
• qwen
• typescript