Exception Resolver

AI detects operational exceptions, calls the right person to resolve them, and turns every conversation into structured action.

Comment

Inspiration

Operational exceptions are easy to detect. They are much harder to resolve.

A shipment is delayed. A delivery window is at risk. A critical exception needs an answer that does not exist in the system.

The information may be with a carrier dispatcher, supplier, driver, warehouse contact, or another person. At that point, the automation stops.

Someone has to call.

That exposed a gap we wanted to solve:

What happens when the information required to resolve an operational exception exists with a person instead of a system?

That led to Exception Resolver.

Our core idea is simple:

Detect. Call. Structure. Approve. Resolve.

Exception Resolver uses CALL-E as an active part of an operational workflow. Instead of simply alerting an operator that something is wrong, it identifies the information gap, calls the person who can provide that information, turns the conversation into decision-ready facts, and proposes a resolution for human approval.

The goal is not to replace the person making the decision.

It is to eliminate the manual work between “we have a problem” and “we have enough information to decide what to do.”

What it does

Exception Resolver turns an operational exception into an active resolution workflow.

For the demonstrated shipment exception, the application:

  1. Identifies the exception and its urgency.
  2. Separates known information from missing information.
  3. Determines what the phone conversation needs to establish.
  4. Uses CALL-E at runtime to place a real phone call to the appropriate contact.
  5. Conducts the conversation to obtain the missing operational information.
  6. Brings the conversation back into the exception workflow.
  7. Extracts decision-relevant facts from the conversation.
  8. Generates a proposed resolution based on the exception and newly gathered information.
  9. Shows the evidence and recommendation to the operator.
  10. Requires human approval before the resolution is applied.
  11. Records the outcome in the exception history.

The complete workflow is:

Exception → Information Gap → CALL-E → Real Conversation → Structured Facts → Recommendation → Human Approval → Resolution

This is intentionally different from a standalone voice chatbot.

The call has a job.

It exists to retrieve a specific piece of information that the operational system needs in order to move an exception forward.

How we built it

Exception Resolver is built around an operational exception record and the information required to resolve it.

The application first establishes the current state of the exception. It then identifies the information that is missing and uses that gap to determine what the CALL-E conversation needs to establish.

CALL-E is not simulated or simply referenced in the interface.

It is called at runtime.

The live workflow places a real phone call, conducts the conversation, and brings the resulting information back into Exception Resolver.

From there, the application separates four different layers:

What was said → What was learned → What should happen → What the human approved

That distinction is important.

A transcript is not a resolution.

The useful output is the small set of facts that can actually change the state of the exception and support a decision.

The final step deliberately keeps the consequential decision with the human. The AI can gather information and recommend an action, but it does not silently execute that recommendation.

Challenges we ran into

The hardest problem was not making a phone call.

It was making the phone call useful.

We had to design around a specific question:

What does the application actually need to learn from this person before the exception can move forward?

That meant distinguishing between information the system already knew and information that had to be obtained externally.

We also had to solve the transition from conversation to workflow.

A transcript contains a lot of information, but an operational system needs something more precise:

  • What did we learn?
  • Which facts matter?
  • What changed?
  • What should happen next?

Finally, we had to establish a clear boundary between automation and authority.

An AI agent can gather information.

An AI agent can interpret that information.

An AI agent can recommend a resolution.

But a consequential operational decision should remain visible to the person responsible for it.

That led us to deliberately separate:

  • Known information
  • Missing information
  • Information gathered by CALL-E
  • Extracted facts
  • Proposed resolution
  • Human approval
  • Recorded outcome

Accomplishments that we're proud of

We are proud that Exception Resolver demonstrates a complete operational loop, rather than stopping at a phone-call demo.

The application demonstrates:

Detect an exception. Identify what is missing. Call the person who knows. Capture the answer. Turn it into structured information. Recommend what to do. Let a human approve it. Resolve the exception.

Most importantly, CALL-E is doing meaningful work inside the application.

The phone conversation is not a novelty layer placed on top of a dashboard.

The conversation supplies information that the workflow actually needs.

That is the behavior we wanted to demonstrate: AI that can cross the boundary between software and the real world while still keeping the decision-maker in control.

What we learned

We learned that voice AI becomes particularly valuable at an information boundary.

If the information exists in a database, software can retrieve it.

If the information exists in an API, software can call it.

If the information exists with a person, sometimes the next API call is a phone call.

We also learned that conversation alone is not enough.

For voice AI to become operationally useful, the conversation has to connect back to the business process. The system needs to understand what information it was trying to obtain, identify the facts that matter, and turn those facts into something a person can act on.

Most importantly, we learned that human approval does not have to be the opposite of automation.

It can be the boundary that makes automation trustworthy.

AI gathers. AI recommends. Human approves.

What's next for Exception Resolver

The demonstrated workflow focuses on one specific pattern: using a real phone conversation to obtain missing information and resolve an operational exception.

The same pattern could extend to many other exception types:

  • delayed shipments
  • missed delivery windows
  • supplier issues
  • service interruptions
  • scheduling conflicts
  • inventory exceptions
  • field-service problems
  • customer escalations

The underlying workflow stays the same:

Detect the exception. Identify what is missing. Call the person who knows. Capture the answer. Recommend the next step. Keep the human in control. Resolve the exception.

Our vision is straightforward:

When an operational system detects a problem, it should be able to do more than tell someone that work exists.

It should be able to help gather what is needed to get the work done.

The core idea is simple:

When the next API call doesn't exist, the next call might be a phone call.

Detect. Call. Structure. Approve. Resolve.

Built With

Share this project:

Updates

Submission history