Exception Broker

A control layer for AI-acquired decisions: CALL-E gathers real-world approvals, while Exception Broker verifies evidence and operational constraints before anything can execute.

Comment

Inspiration

AI agents are becoming very good at reaching people, gathering information, and obtaining decisions through real-world channels like phone calls.

But acquiring a decision is not the same as having authority to execute it.

A customer can approve a recovery plan while operational constraints no longer support it. A supplier can confirm an exception while the underlying evidence is incomplete. An AI interaction can succeed while the resulting action is still unsafe to apply.

Exception Broker was built around that gap:

Decision acquired ≠ authority to execute.

What it does

Exception Broker is an execution-control layer for AI-acquired operational decisions.

CALL-E handles the acquisition boundary: it can place a real phone call and return conversation evidence and, when available, a structured result.

Exception Broker then takes over.

It preserves the acquired evidence, validates structured results without inventing missing information, requires exact review of what was actually authorized, and evaluates the reviewed proposal against operational constraints.

The Broker then produces one of three dispositions:

ALLOW · BLOCK · WAIT

A decision can remain APPROVED while its application is still BLOCKED.

The product can be experienced in three ways:

  • Interactive Demo — a deterministic guided scenario with no external provider required.
  • Hosted Sandbox — a limited live CALL-E integration using a controlled synthetic testing destination.
  • Your CALL-E Account (BYOK) — connect your own CALL-E API key and an authorized recipient for a live acquisition.

The hackathon build keeps application effects local and controlled. It demonstrates the execution boundary without claiming to modify an external ERP, WMS, CRM, or customer system.

How we built it

Exception Broker is built with TypeScript, React, Node.js, Vite, Zod, Motion, Vitest, Railway, and the official CALL-E SDK.

The live acquisition boundary is intentionally fail-closed.

Each CALL-E acquisition receives a server-owned idempotency key. Provider responses are sanitized before persistence or display. Structured results are schema-validated, and Exception Broker never infers authorization from transcript text when CALL-E has not returned a usable structured result.

We also built bounded reconciliation for an important real-world failure mode: a network request can fail after the provider may already have received it.

Instead of blindly creating another phone call, Exception Broker preserves provider-acceptance uncertainty and reconciles using the same logical acquisition and idempotency key.

For Control, an acquired decision is bound to an exact review target. Only after that review does the Broker evaluate the application attempt against independently modeled operational facts.

That separation is the core of the product:

Acquisition → Decision → Exact Review → Operational Reality → Disposition

Challenges we ran into

The hardest problem was not making an AI phone call.

It was handling uncertainty correctly after the call boundary.

A failed HTTP response does not necessarily prove that the provider never received the request. Blind retries could create duplicate real-world actions, so we had to model uncertainty explicitly instead of treating every technical failure as a clean failure.

A second challenge was preserving the distinction between:

  • what was said in the conversation,
  • what CALL-E actually returned,
  • what Exception Broker could safely normalize,
  • what was reviewed,
  • and what operational reality allowed.

During one real CALL-E test, the synthetic destination completed a conversation but did not produce a usable structured decision. Exception Broker correctly stopped instead of manufacturing one.

In another live run, CALL-E encountered an ambiguity in the requested constraints, clarified the exact terms during the conversation, and captured an explicit final APPROVED decision. Exception Broker preserved that result, required exact review, and evaluated it through the controlled application boundary.

Those two outcomes reinforced the same principle: the system must evaluate what CALL-E actually returns, not what we hoped it would return.

Accomplishments that we're proud of

  • Real CALL-E runtime integration, not a mocked provider wrapper.
  • Live phone acquisition with conversation and provider evidence.
  • Structured decision handling when CALL-E supplies a usable result.
  • Fail-closed behavior when a usable decision cannot be established.
  • Idempotent reconciliation for ambiguous provider acceptance.
  • Hosted and BYOK live-access modes.
  • Exact review before application evaluation.
  • Deterministic ALLOW / BLOCK / WAIT control proofs.
  • A guided Interactive Demo that explains the full control path without requiring a live phone call.
  • No external execution in the hackathon environment.

The live demo also demonstrates an important property of the Broker:

An APPROVED decision can resolve to ALLOW when the controlled context supports it.

Another APPROVED decision can resolve to BLOCK when operational reality cannot support the action.

Most importantly, Exception Broker can say:

“The decision exists, but I still cannot prove that it should be applied.”

and stop there.

What we learned

The interesting problem in agentic systems begins after the agent succeeds.

A voice agent can obtain an answer.

A browser agent can click a button.

An email agent can obtain approval.

None of those outcomes automatically prove that the resulting action is still valid in the operational world.

We learned that provenance, uncertainty, idempotency, exact review, and execution control are not secondary safety features.

They are part of the product.

What's next for Exception Broker

CALL-E is the first acquisition channel, not the last.

The same control boundary could sit behind decisions acquired through voice, email, browser agents, ticketing systems, or workplace tools.

Future versions could add production operational connectors, organization-level policies, RBAC/SSO, durable shared audit trails, additional provider adapters, and controlled execution adapters for systems such as ERP, WMS, CRM, and workflow platforms.

The long-term vision is simple:

A control plane between AI-acquired decisions and real-world consequences.

Built With

Share this project:

Updates

Submission history