ResolveCall

When the API can't fix it, ResolveCall picks up the phone.

Inspiration

Modern systems are very good at detecting operational failures. APIs, webhooks, monitoring systems, and automation can tell us what went wrong almost immediately.

But detection is only half the problem.

In many real-world operations, the final resolution still depends on a human answering a phone call. A carrier may need to confirm a delivery window. A vendor may need to authorize an action. A field operation may require a dispatcher. And sometimes there is simply no API to perform the recovery — only a phone number.

That gap inspired ResolveCall.

We wanted to build an agent that doesn't stop at "an incident occurred" or "please contact the vendor."

Instead:

ResolveCall actually picks up the phone.

What ResolveCall Does

ResolveCall is an autonomous operational incident recovery agent powered by CALL-E.

The workflow is:

Incident → Plan → CALL-E → Real Phone Call → Negotiation → Evidence → Policy Verification → Recovery

When an operational incident is received, ResolveCall dynamically creates a recovery objective based on the failure, authorized destination, required action, and operational deadline.

It then uses CALL-E to place an authorized real-world phone call.

During the call, the agent can communicate with the operational contact, negotiate a resolution, and collect the information required to verify that the incident can actually be recovered.

The conversation is then converted into structured evidence.

But ResolveCall does something especially important:

It does not blindly trust the conversation.

The extracted evidence is evaluated by a deterministic policy engine.

For a negotiated completion time (T_{proposed}) and operational deadline (T_{deadline}):

$$ \Delta = T_{deadline} - T_{proposed} $$

A recovery commitment is valid only when:

$$ \Delta \geq 0 $$

This means an AI conversation can never simply declare success. The operational evidence must satisfy the actual constraints.

The Real-World Phone Call

This project was built around the idea that CALL-E should be used as a real operational actuator, not as a simulated interface.

We validated the system using an actual authorized phone destination and a real CALL-E conversation.

The captured conversation demonstrated the complete recovery path:

Real Incident → Recovery Plan → CALL-E → PSTN → Human Conversation → Evidence Extraction → Deterministic Policy Validation → Recovery

The system extracted a negotiated 10:00 AM–12:00 PM recovery window, representative information, and a dispatch reference from the recipient's actual conversation, then verified that the proposed completion time satisfied the operational deadline.

The corrected pipeline evaluates that captured real call as VALID / RECOVERED.

We also deliberately tested failure conditions. When a call is interrupted or insufficient evidence is obtained, ResolveCall does not claim success. It keeps the incident in:

RECOVERY_UNCONFIRMED

This distinction is fundamental to the system.

How We Built It

ResolveCall is organized into several layers:

1. Incident Engine

Receives structured operational incidents and maintains their lifecycle.

2. Recovery Planner

Transforms the incident into a concrete recovery objective, constraints, deadline, and required evidence.

3. CALL-E Telephony

Uses CALL-E to reach an authorized operational destination through a real phone call.

4. Evidence Engine

Extracts structured evidence from the actual conversation, including:

negotiated delivery/recovery window
representative information
authorization or dispatch reference
operational commitment

Evidence is scoped to the specific incident and recovery call.

5. Deterministic Policy Engine

Evaluates whether the evidence actually satisfies the operational constraints.

6. Audit Trail

Records the recovery lifecycle, call events, evidence, policy evaluation, and final outcome.

What We Learned

The biggest lesson was that voice is fundamentally different from an API response.

Phone conversations are messy.

Speech can be fragmented. Calls can be interrupted. Telephony events can appear alongside conversation events. Speech recognition can produce partial phrases.

That forced us to separate four different concepts:

Telephony state → Conversation → Evidence → Decision

A connected call does not automatically mean a successful recovery.

Likewise:

an incident contact name is not proof that a person answered
an incident ID is not an authorization code
a delivery window in incident metadata is not a negotiated delivery window
an incomplete conversation is not a successful recovery

This led us to build explicit evidence provenance and isolation between incidents and recovery runs.

Our final validation reached 35/35 automated tests passing, including regression tests for state transitions, evidence isolation, transcript normalization, extraction correctness, deadline validation, and the complete recovery path.

Challenges We Faced

Making a Phone Call Part of an Autonomous Workflow

The biggest challenge was closing the loop between software and the physical world.

It is easy to create an alert saying:

"Contact the vendor."

It is much harder to build:

detect → plan → call → negotiate → extract → validate → decide

as an autonomous workflow.

Preventing False Positives

We wanted ResolveCall to be trustworthy, not merely impressive.

The system therefore separates conversational evidence from deterministic policy decisions.

If evidence is missing, the system says so.

If the call is interrupted, the system says so.

If the negotiated commitment violates the deadline, the system rejects it.

The agent is allowed to negotiate.

The policy engine decides whether the recovery is actually valid.

Why This Matters

The world is not fully API-native.

Logistics providers, healthcare operations, telecom systems, transportation networks, field services, supply chains, and vendor operations can still depend on humans reachable through phone calls.

ResolveCall explores what happens when autonomous agents can operate across that boundary.

Instead of:

Software → API → Action

we enable:

Software → AI Agent → Phone → Human → Evidence → Verified Action

The phone becomes an operational interface.

What's Next

We see ResolveCall as a general-purpose bridge between API-native software and human-operated systems.

The same architecture could eventually support:

logistics recovery
carrier coordination
field-service dispatch
vendor escalation
supply-chain exceptions
telecom operations
appointment coordination
emergency operational workflows

Anywhere a critical workflow ends with:

"You need to call them."

ResolveCall can potentially make that final step autonomous, controlled, and auditable.

The Vision

APIs automate software.

ResolveCall automates the phone call that software couldn't automate.