-
Gas odor triggers JARVIS’s approved emergency script and a P0 dispatch recommendation
-
Technician qualifications, evaluation checks, and proposed actions stay visible for human approval
-
The Decision Receipt records trigger evidence, applied rules, dispatch results, customer history, and the Arize trace
Inspiration
Every service call comes from a person dealing with a problem at home. Most calls may be routine, but some include signs of immediate danger: a gas odor, a carbon monoxide alarm, or an older resident without heat. In those moments, a dispatcher needs to see the risk clearly and act quickly.
I built J.A.R.V.I.S. Dispatch around a simple belief: AI should help people make better decisions under pressure, while leaving responsibility and judgment with people. Protecting the caller should come before convenience. That should be the norm for AI in service work.
What it does
J.A.R.V.I.S. Dispatch is a voice-first dispatcher demo for Brightline Heating & Air, a fictional HVAC company. It takes a caller’s request through a fixed workflow: check for safety triggers, look up customer and service history, find the relevant procedure, and recommend a qualified technician.
When a configured hazard is detected, JARVIS uses an approved safety script word for word. If a caller is unsure or the situation needs judgment, the system can flag it for human review. It also creates a Decision Receipt showing what phrase triggered a rule, what checks ran, why a technician was recommended, and whether a person approved the proposed actions. Replay reruns the rules and scorer on the saved inputs.
All company, customer, and technician data is synthetic. Dispatches, pages, and texts are dry runs. The demo does not contact anyone.
How we built it
I built the project in Python with a web interface and a fixed call-processing pipeline. The language model helps understand requests and phrase ordinary replies. Deterministic rules handle configured safety triggers, and a vetted scorer ranks eligible technicians based on urgency, qualifications, and availability.
JARVIS uses SurrealDB for customer and work-order history, Daytona for dispatch scoring, Arize AX for traces and evaluations, ElevenLabs for spoken replies, and Anchor Browser for service documentation. Each integration has a local fallback so the demo can keep running when a service or credential is unavailable.
Challenges we ran into
The hardest part was getting context right. “I smell gas” is different from “I don’t smell gas,” “there was a leak last year,” or “I’m not sure about this smell.” I tested these cases so the system can respect negation and past mentions, while sending uncertainty for human review.
I also learned that protecting privacy means checking more than what appears on screen. A test caught a phone number entering a trace. I fixed the leak and added a test that checks 159 trace spans for phone and card numbers. The smoke test also covers 14 safety-trigger cases.
Accomplishments that we're proud of
I’m proud that JARVIS doesn’t ask dispatchers to trust a recommendation without evidence. They can review the caller’s words, the rule that fired, the technician’s qualifications, the evaluation results, and the proposed next steps in one place.
I’m also proud that the system keeps a person in control. Proposed actions require approval, and even after approval, this demo records dry-run receipts instead of sending a dispatch, page, or text.
What we learned
Safety is a property of the whole workflow, not just the model’s response. Rules, privacy checks, tool boundaries, evaluations, clear receipts, and human review all play a part. We also learned to test what gets recorded in traces, not only what the user sees.
What's next for J.A.R.V.I.S. Dispatch
The next step is to learn from dispatch professionals and improve the workflow around their real procedures. A real deployment would need company-approved integrations, careful privacy and safety reviews, and human oversight designed with the people who handle these calls every day.
JARVIS is meant to support dispatchers, not replace them. The goal is for useful, explainable assistance—and human judgment—to be a normal part of service work.
Built With
- ai-safety
- anchor-browser
- arize-ax
- claude-/-anthropic
- daytona
- elevenlabs
- fastapi
- human-in-the-loop
- opentelemetry
- python
- surrealdb
