Skip to main content

Under constructionStatus: Building. Being built now. Parts may run; the whole is not finished.

Every project’s status →

01.02Conversation copilot

Discovery Copilot for live sales calls

AR Labs' Discovery Copilot is a prototype that follows a live sales call, ticks a discovery checklist with quoted evidence and suggests the next question.

On this page
  1. How it works
  2. What exists today
  3. Decisions
  4. Related projects

Discovery Copilot is AR Labs' prototype copilot for live sales calls: a browser page that a person runs beside a video call to get live help with a structured conversation. It transcribes both sides of the call, follows which parts of a prepared plan have been covered, and shows a checklist that ticks itself, a suggested next question, and a short running note on whether the call is on track. The first use is the sales discovery call, for consultants and sellers who run one; the same engine is designed for any two-person conversation that follows a plan, such as research interviews, podcast interviews or facilitated sessions. Where Salesbot is an agent that runs the discovery conversation itself, Discovery Copilot leaves the conversation to a person and keeps track for them.

The person running the call should be looking at the other person, not at a screen. The interface is built around that: it updates quietly in place and never pops anything up.

How it works

Audio arrives as two separate streams. The microphone carries the user's own voice and the shared system audio carries the other side of the call, so every line of the transcript is labelled "You" or "Them" with certainty. Both streams go to Deepgram as one two-channel stream for live transcription, and the copilot assembles the fragments into turns: one speaker's continuous speech.

When a turn closes, the transcript and the current coverage state go to Claude Haiku 4.5 in one analysis pass. The model must answer through a single tool, report_coverage, which returns a status for each checklist item with a quoted line of evidence, the best item to raise next with a suggested question for it, and a status note measured against the call's goal. The server validates the result and pushes it to the page over server-sent events.

FIG. 01
flowchart LR
  M["Microphone: You"] --> DG["Deepgram, two channels"]
  S["Call audio: Them"] --> DG
  DG --> TU["Turn assembly"]
  TU --> AN["Analysis pass: Claude Haiku 4.5"]
  AN -->|"validated result"| SSE["Server-sent events"]
  SSE --> G["Result gate"]
  G --> CS["Checklist and next question"]
  G --> ST["Status note"]
  G --> CH["Chapters"]

The diagram above follows the data through one turn. The figure below shows where each part runs: the browser captures both voices, guards against echo and assembles turns; a small local server issues the browser its keys for the speech service, runs each analysis pass, validates it and autosaves the transcript to disk.

C4 container diagram: seller, prospect and call app; browser client and local server inside; the browser streams two channels to Deepgram; the server calls Claude Haiku 4.5 and autosaves. The seller talks and reads three panels in the browser client (React, Zustand, Tailwind), which runs beside any video-call app. The prospect speaks in the call, and the client captures that as system audio while the microphone carries the seller. The client asks the local server (Express) for a short-lived key, then streams both audio channels to Deepgram over WebSocket and receives transcripts back. It posts each finished turn and analysis request to the server over JSON/HTTPS. The server asks Claude Haiku 4.5 for a coverage report through one forced tool, validates the result and pushes it back to the client over server-sent events, and autosaves the transcript to JSONL and Markdown files on disk. Discovery Copilot: containers C4 LEVEL 2 · A LOCAL APP BESIDE A VIDEO CALL · THE BROWSER DOES THE LISTENING, THE SERVER DOES THE JUDGING FIGURE DISCOVERY COPILOT CONTAINERS DRAWN BY AR LABS SHEET 1 / 1 Seller [Person] Runs the call; glances at the panels Video-call app [External: any] Carries the prospect's voice Prospect [Person] On the other end of the call DISCOVERY COPILOT [Software system, runs locally] Browser client [Container: React + Zustand] Captures mic and call audio, guards against echo, assembles turns, applies results in order, shows checklist, status and chapters Local server [Container: Node, Express] Mints speech keys, buffers the transcript, runs each analysis pass and validates it Transcript files [JSONL + Markdown] Autosaved as the call runs Deepgram [External: speech-to-text] Two-channel live transcription Claude Haiku 4.5 [External: language model] Answers through one tool, report_coverage KEY Container the lab built Files on disk Person External service or app System boundary Call or data flow, labelled speaks talks (mic), reads panels call audio, captured as system audio streams You and Them transcripts [WebSocket] key request, turns, analysis [JSON/HTTPS] validated results [SSE] coverage pass [HTTPS] autosaves
The browser does the listening and the local server does the judging.

The page has three columns. On the left is the checklist, grouped by SPIN stage (Situation, Problem, Implication, Need-payoff, the sales-questioning method developed by Neil Rackham). Items move from pending to mentioned to covered, and one item is anchored as the best next, showing the words the user could say next. In the centre a status panel holds the newest note, with an actionable nudge in the largest type, above the live transcript. On the right the call grows into a list of chapters; clicking one scrolls the transcript to that section.

The engine is separated into three layers. The first is general knowledge of the SPIN method, written into the model's instructions. The second is the engine and interface, which know nothing about any particular client. The third is a library of call templates, each giving one call's goal, stages and checklist items, refined just before the call it is for. A generic discovery template that names no client is the default.

What exists today

Discovery Copilot is a working local prototype. It builds and runs on one machine, and its automated test suite of 371 tests passes. The analysis loop has been checked against the real model with recorded transcripts: items ticked with cited evidence, the next-question anchor advanced, and the template picked in the interface was the one analysed. Recent work added a speakers mode, so the copilot can be used on laptop speakers without headphones, and an echo guard that drops a transcript line when one channel picks up the other.

Live use on real two-party calls is still being proven, and the copilot is not deployed or offered for others to use. Planned extensions include a stronger model for suggestions when a call stalls, a list of gaps at the end of a call, and recovery after a dropped connection.

Decisions

Two audio streams instead of speaker detection. Deepgram's streaming speaker detection on a single mixed stream proved unreliable, so the copilot captures the user's microphone and the call audio separately. The channel split gives a deterministic "You" and "Them" for free. Speaker detection is still attempted within the call-audio channel to separate several remote speakers, on a best-effort basis.

A checklist that only moves forward. Coverage is folded into the checklist monotonically: an item can move from mentioned to covered but never back. A later analysis pass that misreads the conversation cannot un-tick something already established. Chapters follow a similar rule: finished chapters are frozen and only the open one grows.

A checklist rather than pop-ups. A competitive review of existing sales-call assistants found the most common complaint was live pop-ups distracting experienced sellers. A persistent checklist that updates in place gives the same information without interrupting.

Evidence for every tick. The model must quote the line that covers an item. The first quote is kept and shown, so the user can see why something was marked covered.

Results applied in order. Every analysis result carries a sequence number. The page applies a result only if it is newer than the last one applied, so a slow response cannot overwrite a fresher one.

A suggested question holds while it is being asked. Once a question is shown, it stays, in the same words, until its item is covered or a later pass that has heard new speech from the other side offers a better one. The user's own words never move it, because a suggestion that changes while someone is reading it aloud is worse than none.

Built to stay cheap per turn. The analysis instructions and tool definition never change between passes, so they can be cached by the model provider, and the transcript grows one completed turn at a time, so the copilot runs one analysis pass per turn rather than one per fragment of speech.

VOX Facilitator is our design for a voice agent that runs a planned session itself, and VOX Presenter holds spoken sessions about documents. Discovery Copilot is the one of the three that assists a person in a call with someone else.