FieldRelay

Governed AI phone operations that turn authorized vendor calls into human-approved dispatch decisions.

Comment

Inspiration

Property maintenance is not delayed because repairs are hard to understand. It is delayed by phone work: finding an available vendor, collecting a quote, confirming timing, and keeping residents informed.

Most maintenance platforms organize this work. They do not make the call. We asked: what if the calls were made automatically, while every consequential decision still belonged to a person?

What it does

FieldRelay turns a maintenance incident into an authorized phone call, and the phone call into a governed operational decision.

  1. An operator creates an incident.
  2. FieldRelay verifies that the selected contact is authorized for the specific purpose.
  3. It reserves an idempotency key and commits the call task before any provider I/O.
  4. CALL-E phones the vendor with a disclosure and a purpose-bounded brief.
  5. The response returns as schema-constrained structured data, such as availability and a quoted amount.
  6. FieldRelay validates the result and stops for human approval whenever the answer introduces cost or risk.
  7. An approved decision becomes an explicit dispatch lifecycle: scheduled, en route, on site, and completed.

Our verified authorized live CALL-E run returned available: yes, quoted_amount_text: $35, and confidence 0.82 / high. For judging, the production app is intentionally kept in exact live mode with a bounded, provisioned CALL-E target; every call remains purpose-bound, idempotent, webhook/reconciliation backed, and human-approved before dispatch.

What it refuses to do

The most important engineering is what FieldRelay declines:

  • It will not dial a contact that was not explicitly provisioned and authorized for the requested purpose.
  • It will not use the live provider unless CALL_E_MODE is exactly live.
  • It will not redial an ambiguous outcome automatically.
  • It will not create two calls for one authorized task; the call-task UUID is the idempotency key across retries.
  • It will not store phone numbers, transcripts, or recordings in the operational record.
  • It will not accept undeclared or invalid answer fields.
  • It will not turn a quoted price into permission to spend; a human must approve.
  • It will not present unmeasured rates as facts.

How we built it

FieldRelay uses Clean Architecture so the domain remains independent of frameworks, persistence, HTTP, and CALL-E implementation types.

  • Frontend: Angular 20, Ionic, TypeScript, centralized design tokens, dark/light parity.
  • API: NestJS with PostgreSQL and transactional units of work.
  • CALL-E boundary: Developer API integration using bearer authentication, purpose-derived briefs, mandatory disclosure, a per-task idempotency key, and a closed result schema.
  • Outcome ingestion: authenticated, replay-safe webhook handling with event deduplication and strict schema validation.
  • Deployment: Vercel for the SPA and NestJS API, with Neon PostgreSQL.
  • Verification: 438 database-backed and focused tests, lint, strict type checking, production builds, design-token checks, and a zero-finding UI detector.

The reusable service-dispatch-call contribution was reviewed and merged into CALL-E's public Awesome Phone Call Agents repository as PR #107.

Challenges we ran into

A timeout that could have caused duplicate work. A proof client stopped waiting after 15 seconds even though CALL-E had accepted the call. We raised the timeout and encoded the real protection in the application: retries reuse the already-committed task UUID rather than minting a new identity.

A persistence rule that looked harmless. An idempotency reservation referenced a call task without an appropriate delete behavior. PostgreSQL integration tests exposed that retention would fail. The reservation now safely outlives the task it guards.

Documentation and API contract differences. The integration guide described a singular recipient while the published API specification uses recipient and phone arrays. Reading the specification directly also revealed the nested webhook call identifier. We corrected the adapter and added regression coverage.

Provider schema constraints. FieldRelay enforces stricter numeric bounds locally, then sends only schema keywords CALL-E supports. This prevents a strict provider from rejecting the complete request while preserving application safety.

Accomplishments

  • A real application-driven CALL-E call returned a validated structured result.
  • Human approval and dispatch form one coherent end-to-end workflow.
  • Ambiguous outcomes are modeled explicitly and never auto-redialed.
  • Provider callbacks are authenticated, replay-safe, and privacy-bounded.
  • Every navigation route in the evaluator is implemented.
  • The public CALL-E contribution is already merged and reusable by the community.

What we learned

Getting an AI to make a call is the easy part. The difficult and valuable work is ensuring it knows when it must not call, retain, retry, decide, or claim certainty.

Ambiguity is not merely an error; in a system that can spend money or contact people, it is a durable state that requires human review.

What's next

We would add automated visual-regression and accessibility testing, optimize the frontend entry bundle, and adopt provider-signed webhooks if CALL-E publishes a signing mechanism.

Try it

Built With

Share this project:

Updates

Submission history