Bellwrench

• 

  Consent-first dispatch workspace with safety screening, scoped intake, vendor authorization, and a visible no-booking/no-spend boundary.

• 

  Populated non-emergency work order with safety screening, bounded disclosure, and human-controlled vendor selection.

• 

  Authorization review standardizes the requested evidence and keeps the operator visibly in control before any real CALL-E side effect.

Inspiration

A leaking sink is not a life-safety emergency, but every hour still matters. Small property managers often phone vendors one at a time, repeat the same work-order context, and compare inconsistent notes. The opportunity was not merely to automate dialing; it was to make the returned answers safe, comparable, and useful without surrendering commercial authority to an agent.

What it does

An operator creates a non-emergency work order, chooses only vendors the organization is authorized to contact, and previews the exact caller identity, purpose, disclosure budget, result fields, and no-booking boundary. A deliberate final confirmation enables CALL-E to place the outbound call. Bellwrench then separates verified, incomplete, failed, and unknown outcomes, ranks only complete validated evidence, and lets the operator record either a vendor for manual follow-up or no dispatch. The audit record always states that no booking was made.

How we built it

Bellwrench is a Next.js 16 and React 19 application written in TypeScript. The server-only integration uses the official @call-e/calle SDK to create calls and poll for results. Runtime validation enforces a closed vendor-result schema. Content-bound idempotency, known-call-ID recovery, and conservative reconciliation handle duplicate and acceptance-ambiguous requests. The responsive operations console exposes safety and evidence state directly instead of hiding it behind a generic chat interface.

Challenges we ran into

The difficult part was preserving truth across an irreversible phone side effect. A network failure after call creation may mean the call was accepted even when the response was lost, so treating every exception as a safe retry risks dialing twice. We separated definitive failures from unknown outcomes, preserved known call IDs, and bound idempotency to the complete approved call content. We also had to keep incomplete or weakly supported answers out of the ranked recommendation without discarding the evidence a human may still need.

Accomplishments that we're proud of

• CALL-E is a real runtime dependency behind an explicit confirmation gate.
• Emergency requests are refused before a CALL-E client is created.
• The UI masks recipients and never receives the API key.
• Result validation preserves verified, incomplete, failed, and unknown states.
• Only verified evidence can be ranked or selected for manual follow-up.
• The app never books work, accepts terms, or commits spend.
• 108 automated tests pass across 16 files, alongside lint, production build, dependency audit, and upstream repository validation.

What we learned

Structured output is not automatically trustworthy output. A useful real-world agent must distinguish what the transport did, what the recipient said, how strongly that statement is supported, and what authority the operator actually granted. The best product experience makes those boundaries visible before and after the call.

What's next for Bellwrench

After the hackathon, Bellwrench can add shared durable audit storage, property and roster policies, working-hour rules, expiring evidence, and vendor response history. The central contract will remain unchanged: Bellwrench gathers and compares evidence; a person authorizes every booking and spend decision.

Built With

• call-e
• next.js
• react
• typescript
• vercel
• vitest