Call Coach AI is a work-in-progress sales-call assistant from ZeroGold. Its useful pattern is not a model generating a stream of sales advice: Jev supplies typed judgments, and a local playbook decides which suggestion to show the human representative.
One request, several narrow judgments
The inspected server.mjs sends the conversation as state.sales_call_transcript, along with the questions in schema.json, to TypeSafe’s /v1/systemone endpoint. The API key stays on the server.
The schema asks for:
- A Choice: the next action—send pricing, book a demo, involve the decision maker, handle an objection, send a proposal, ask a discovery question, arrange a follow-up, or take no action.
- A Score: the customer’s current buying stage.
- Seven Noul signals: pricing questions, a timeline, budget, decision-maker involvement, ownership language, blocking objections, and previous sales contact.
These questions go into one request rather than a separate chat-model call for each signal.
The decision layer is ordinary code
public/decide.js turns the returned probabilities into a stable interface:
- Suppress actions the representative marked done and actions blocked by playbook rules.
- Renormalize the probabilities of the remaining options.
- Break near-ties using a configured priority order.
- Keep the current suggestion until a challenger clearly wins or remains ahead across updates.
- Show “keep listening” when the evidence is insufficient.
- Smooth buying-stage updates and use hysteresis to avoid a flickering gauge.
The displayed next-action score is therefore a policy-adjusted value, not an untouched model probability. Its relationship to real-world accuracy still needs evaluation.
What is worth borrowing
This is a concrete example of separating semantic judgment, application policy, and human action. The model interprets a conversation; code enforces the playbook and display behavior; the person decides what to say or do. The coaching tips come from the local playbook rather than requiring generated prose on each turn.
Setup and documentation caveats
- The repository targets Node.js 18+ and includes an optional Electron overlay. GitHub shows an MIT license.
- The default model is
jev-latest; pinning a model version would make experiments easier to reproduce. - The README says browser speech recognition and no packages to install, but the inspected revision also contains a local Whisper transcription endpoint and Hugging Face/ONNX dependencies. Check the current code and selected input mode rather than relying on that setup description alone.
- Server-side transcript trimming keeps the last 40 turns and limits each turn’s text. The request code retries certain overload/rate-limit responses, but no explicit fetch timeout was visible in the inspected function.
Before using real customer calls
Conversation text is sent to TypeSafe. The README warns that browser speech recognition can send audio to Google; the newer local transcription path does not mean every mode is local. Get appropriate recording/transcription consent and avoid sending sensitive customer information.
The inspected server listens without an explicit loopback address, and no request authentication was visible in the routes reviewed. Treat it as a demo, not a service to expose publicly without hardening.
Verification: README, server.mjs, schema.json, public/decide.js, and package.json inspected at commit 0d657db. Not installed, executed, or tested against the live Jev API. This is a focused implementation reading, not a full security audit.