Customer Recovery Brain

• 

  The headline “CRM says healthy” and the conflicting signal cards

• 

  The Orange tier with cited date reconciliation

• 

  The graph panel with 23 relationships and their sources

• 

  The draft email and proposed CRM update, marked not sent

• 

  The “what changed after Oct 12” answer, citing the new note

Inspiration

A CRM health score is often the last thing to change. An account can be marked Green while the warning signs sit in other tools: an open support escalation, a usage drop in analytics, a meeting note saying the executive sponsor has moved teams. By the time someone connects them, the renewal is close and the window to recover is short.

We wanted an agent that reads across those sources and explains why an account is at risk, cites every claim, says what is still unknown, and prepares the recovery work, while leaving the final decision to a person.

What it does

Customer Recovery Brain analyzes a synthetic account, Cedar Labs:

• Explains risk. It reconciles conflicting sources by date. A September 30 CRM snapshot says Green, but newer evidence shows an open sync incident, a 40% drop in weekly active users, and no executive sponsor.
• Proposes a risk tier using the tiers defined in a retrieved recovery playbook, with a cited justification. It keeps facts, inferences and unknowns separate.
• Drafts a recovery plan with owners named only when a source names them, proposed milestones, and measurable exit criteria.
• Prepares the actions. Each plan ends with a draft customer email from the account's CSM and a proposed CRM update (for example, Health from Green to Orange), all marked DRAFT, NOT SENT, requires human approval.
• Updates its answer when new evidence arrives. Add a customer note, index it, and ask "what changed?". The answer cites the new note first and updates which actions are still needed.

How we built it

• Knowledge layer: HydraDB. Synthetic CRM, support, meeting-notes, analytics, ownership and playbook documents are ingested into a dedicated HydraDB database. Each question uses hybrid retrieval plus HydraDB's knowledge graph. The UI lists the graph's relationships (for example cedar labs → red classification validated by → cx leadership) with the source document each came from.
• Reasoning: a configurable LLM. The demo uses OpenAI gpt-5.4-mini and answers in about 8–12 seconds. For privacy, the same app runs fully locally on Ollama (qwen3.5:9b) by changing one config file, so no account data leaves the machine.
• App: a single-file Python backend using only the standard-library HTTP server, plus one static HTML page. It serves on localhost only, and API keys stay on the server.
• Guardrails: source text is treated as untrusted evidence, never as instructions. The app refuses to answer until every source is fully indexed, and nothing is ever sent or changed automatically.

$$ \text{sources} \xrightarrow{\text{ingest}} \text{HydraDB} \xrightarrow{\text{hybrid + graph}} {S_1,\dots,S_k} \xrightarrow{\text{LLM}} \text{cited plan} + \text{staged actions} $$

Every answer must pass a citation check:

$$ \emptyset \neq \text{cited}(a) \subseteq {S_1,\dots,S_k} $$

If the model cites a label that doesn't exist, it gets one retry, and the answer is rejected if it still fails. The check proves each citation points to a real retrieved source, not that the source supports the claim. That last judgement stays with a human.

Challenges

• Local model latency. On a laptop, qwen3.5:9b with thinking mode on took longer than our 90-second request timeout. With thinking off it took about 70 seconds per answer. The graph context alone adds about 10,000 input tokens. We measured each step: HydraDB retrieval takes 0.5–2 seconds, and almost all the remaining time is generation. That's why the demo uses a hosted model and Ollama is the private option.
• Made-up citations. The small local model sometimes cited sources that didn't exist. We now give the model the exact list of labels it may cite and retry once if it still gets one wrong.
• API schema changes. HydraDB v2 rejected title as a top-level metadata field, so we moved it into additional_metadata.
• Indexing time. Building the knowledge graph took about 40 minutes for the first batch of sources. We kept the readiness check rather than answer from partially indexed data.
• Staying honest. The prompt forbids inventing owners, deadlines, causes or churn probabilities, and requires it to state that causality and cancellation are unproven when they are.

What we learned

• Dated, connected evidence matters more than model size, but local inference speed decides whether a demo feels interactive.
• A "brain" is most useful when it can be updated: indexing one new note visibly changes the assessment.
• The useful agentic step isn't sending emails automatically. It's preparing accurate, cited drafts that a person can approve in seconds.

Limitations

This is a prototype: one synthetic account, with document ingestion standing in for live CRM and support integrations. It is not a validated churn predictor.

Built With

• css
• gpt-5.4-mini
• html
• hybrid-search
• hydradb
• javascript
• knowledge-graph
• llm
• ollama
• openai
• python
• python-dotenv
• qwen
• rag
• unittest