CallOps

Inspiration

A supplier says the replacement part will arrive on Friday. A repair workshop can easily turn that estimate into a promise that the customer's machine will be returned on Friday. Those are different events. CallOps addresses this narrow communication problem: collect the missing supplier facts before composing a customer update.

What it does

CallOps separates part arrival, repair completion, device return and the next supplier update. It compares the findings with the workshop's earlier expectation and preserves estimates, unknowns and conflicting statements. The proposed customer update links each sentence to supporting evidence and stays a draft for the workshop to review.

The public application demonstrates four clearly labelled fictional outcomes. An evidence reader makes their source excerpts inspectable. Neither the public demo nor its synthetic replay places phone calls or sends customer messages.

How we built it

The TypeScript application uses exact-brief approval, explicit workflow transitions, validated browser persistence and a bounded deterministic date interpreter. The reusable Node-side CALL-E integration includes a fixed MCP transport, an in-memory capability vault, durable execution checkpoints and sanitization of returned text.

The private operator requires separate approval to prepare a plan and to execute the returned plan. The actual destination remains private. Plan and run are each limited to one dispatch; status observations are bounded and no automatic redial is scheduled.

The pinned CALL-E Core is exercised through synthetic credentials and fake HTTP in the integration tests. Real authentication, MCP discovery and service schemas were checked on 13 September, leading to corrections for nested result evidence and multiline transcripts. This is service-contract evidence, not proof that a phone call took place.

What we learned

A useful follow-up needs more than a summary. An arrival estimate cannot establish a return commitment; an unknown execution outcome must remain unknown; and a UI approval must stay attached to the exact brief. Keeping provider execution, supplier statements and customer expectations separate makes these distinctions reviewable.

Current limits

The interpreter targets the demonstrated repair vocabulary and is not a general conversation parser. The public browser remains a no-call demonstration. A representative live call has not yet been completed. No real-workshop adoption, measured time saving, deployment scale or independently verified call outcome is claimed.

Built With

• call-e
• mcp
• node.js
• typescript
• vite
• vitest