CallBrain

Inspiration

A few weeks ago my Shein order arrived very late. The package was stuck because of a problem at a delivery hub in Los Angeles. I called support several times, and every agent gave me a different answer: "it's in transit," "it was delivered," "please wait 3–5 more days," "we'll escalate it." Nobody told me what had actually happened, and nobody followed up when they said they would.

The problem wasn't the agents. Each one was guessing, because none of them could see what was happening right now: that the LA hub was backed up, and that hundreds of other customers were calling about the same thing. The information existed in the company's systems. It just wasn't on the agent's screen during the call. And the promises they made ("we'll update you") disappeared the moment the call ended.

That's what we built CallBrain to fix.

What it does

CallBrain is a live-call copilot for support teams that resolves the customer's issue before the call ends, and keeps every promise after it.

• Before the call: a 10-second briefing built from live data: account value, open tickets, recent failures, billing problems, usage trends, and the most likely reason they're calling.
• During the call: it listens (speech-to-text) and reacts only to what the customer actually raises. When the customer says "nobody can log in," it queries live systems through Triggerware and finds the root cause (a deploy this morning) and the blast radius: 13 other customers have the same error, so this is an incident, not a one-off. Every agent gives the same, correct answer.
• Possible issues & correlations: it shows everything live data reveals about the account (login failures, a duplicate charge, a usage drop) and how they connect, even before the customer mentions them.
• Guardrails from company policy: "She already got a credit in August. A second one needs manager approval." "Incident in progress: don't give your own ETA."
• One-click actions: apply a documented workaround (verified live by a Triggerware query), declare an incident, page the right expert.
• Promise Keeper: at wrap-up, every commitment the agent made becomes a Triggerware trigger on live data. When the refund lands or the fix ships, the promise is marked kept and the customer is updated automatically. Nobody has to remember.
• Signals & Reflexes: always-on triggers push alerts (P1 tickets, login-failure spikes, duplicate charges) with context from company runbooks. Anyone can create a new trigger by typing "tell me when…" in plain English.

How we built it

• Triggerware (the backbone): we used the official Node SDK against a Triggerware server. Company data (customers, tickets, logins, deploys, incidents, billing, usage) is registered as Triggerware virtual tables. We use cursors for live SQL and plain-English queries, triggers with push-based watch (no polling) for signals and promises, saved queries and convert-to-trigger, plus agents and connectors.
• Company brain: runbooks, policies, account notes and postmortems ground every answer, with citations back to the source document and the exact live query.
• AI: NVIDIA Nemotron (fast, structured JSON output) with Gemini as automatic fallback. A rule-based analyst gives an instant answer from live facts, which the AI then refines.
• App: Next.js + TypeScript + Tailwind, server-sent events for real-time updates, Web Speech API for live transcription, and a Control Room that changes production data on stage so judges can watch Triggerware detect each change and how many seconds it took.

Challenges we ran into

• Learning Triggerware's SQL dialect: no JOIN keyword (comma joins), no TIMESTAMP literals, and triggers that compare a limited number of rows by default. We stored times as fixed-width ISO strings so range filters work, and raised the trigger batch size.
• AI rate limits: our first model hit free-tier limits (5 requests/minute) and was often overloaded. We redesigned the copilot to make one AI call per update, added model rotation, a Nemotron primary, and a rule-based fallback so the demo never stalls.
• AI jumping ahead: early versions brought up the incident when the agent just said "hi, how can I help you." We made the copilot context-first: guidance appears only for issues the customer actually raised, while everything else is listed separately as possible issues. Live counts always come from Triggerware, never from the model.

Accomplishments that we're proud of

• Triggerware detects real data changes and pushes them back in ~3 seconds, without the app ever telling it something changed.
• The Promise Keeper loop: a sentence said on a call becomes a live trigger that closes itself when the data proves it happened.
• One shared, live source of truth, so every agent gives the customer the same answer.

What we learned

A company brain that only searches documents can't answer the most important question on a support call: "is this happening to anyone else right now?" Combining company knowledge with live, queryable, push-based data is what turns a chatbot into something that actually resolves issues.

What's next for CallBrain

• Connectors for real support stacks (Zendesk, Salesforce, Stripe, Shopify, carrier/logistics APIs) through Triggerware.
• A customer-facing chat that shares the same brain and hands off to a human with full context.
• Proactive outreach: when Triggerware detects a delivery-hub delay, notify affected customers before they have to call.

Built With

• gemini
• next.js
• node.js
• nvidia-nemotron
• pglite
• postgresql
• react
• server-sent-events
• sql
• tailwindcss
• triggerware
• typescript
• web-speech-api