VINRelease

The auction says “pending.” The lienholder says “sent.” The dealership still has no title.

That is the problem VINRelease is built for.

A title clerk does not need another transcript. They need to know what is actually blocking the title, who owns the next step, and whether the phone evidence is strong enough to move the case.

VINRelease is deliberately narrow. It does not try to be a dealership CRM, and it does not treat a convincing conversation as proof that a case is finished.

It turns a real phone call into the next justified step:

$$ \text{Phone call} \rightarrow \text{Evidence} \rightarrow \text{Next justified step} $$

And the product is built around one simple rule:

$$ \text{Sent} \neq \text{Received} $$

CALL-E reaches the outside party. VINRelease decides whether the answer is enough to move the case.

The 60-second version

• One real-world workflow: overdue vehicle-title exceptions.
• Two outside parties: first the auction, then—only when the evidence points there—the lienholder.
• One real CALL-E SDK task completed through the production runtime path.
• Every call is approved for one recipient, one purpose, and one disclosure packet.
• CALL-E returns structured evidence; VINRelease validates it before the case can change.
• “Release sent” becomes WAITING_EXTERNAL, not CLOSED.
• An unsafe or incomplete answer becomes NEEDS_HUMAN.
• 23 automated tests cover the workflow, validation, safety boundaries, idempotency, replay, and human-stop behavior.
• VINRelease was merged into CALL-E’s official awesome-phone-call-agents repository as pull request #463.

Inspiration

The phone call itself is not the hard part.

The hard part is deciding what the call actually changed.

Imagine one overdue vehicle title:

• The auction portal still says “pending.”
• The auction says the missing lien release is the blocker.
• The bank says the release was sent.
• The dealership still does not have the title.

That sounds like progress. It is not the same thing as resolution.

A title clerk still needs three answers:

1. What is the current blocker?
2. Who owns the next action?
3. Which facts were actually confirmed on the phone?

VINRelease is designed around those three questions.

The judge case uses a synthetic 2019 BMW 330i with $18,700 of blocked inventory so the operational stakes are easy to see. The $18,700 is illustrative inventory value, not measured savings and not a claim about a real dealership result.

What it does

The operator opens one overdue title case.

VINRelease shows the current blocker, the next owner, the inventory at risk, the evidence already collected, and one recommended next action.

Before CALL-E can place a call, the operator sees exactly:

• who will be called,
• why that party is being called,
• which vehicle facts may be disclosed,
• which facts must never be disclosed,
• which questions the agent is allowed to ask,
• and what case movement would be possible if the call returns usable evidence.

The operator approves that exact call.

Then CALL-E does the part ordinary software cannot do by itself: it reaches someone in the outside world and gets an answer.

VINRelease takes that structured result and asks one question:

Do we know enough to move this case forward?

If yes, it moves.

If something happened but completion is not yet proven, it waits.

If the result is incomplete, contradictory, unsafe, or outside the approved task, it stops and gives the case back to a title clerk.

The golden path

The first call is to Metro Auto Auction.

The auction result says the title is blocked because the lien release is missing.

That evidence changes the case from an auction problem into a lienholder problem. Only then does VINRelease allow the second contact.

The second call is separately authorized to ABC Bank’s lien-release desk.

The bank says the release was sent and provides reference LR-4721.

VINRelease records that evidence and moves the case to WAITING_EXTERNAL.

Not CLOSED.

Because “we sent it” is not proof that the dealership physically received it.

The first call can unlock the second call. The second call can move the case into waiting. Neither call is allowed to manufacture a finish line the evidence did not reach.

That distinction is the product.

The failure path matters just as much

Reset the public demo and choose Unsupported credential request.

The recipient asks for something outside the approved disclosure packet.

VINRelease does not let the agent improvise. The agent declines, and the case becomes NEEDS_HUMAN with the reason preserved for the title clerk.

A useful phone agent needs to know when the right action is to stop.

Why CALL-E is essential

CALL-E is not a phone button attached to the dashboard.

It is VINRelease’s connection to a fact that exists outside the software.

VINRelease already knows the case record. What it does not know is what the auction or lienholder will say today.

CALL-E creates that new observation.

$$ \text{Approved task} \rightarrow \text{CALL-E conversation} \rightarrow \text{Structured evidence} \rightarrow \text{Case decision} $$

VINRelease decides who may be called, what may be disclosed, and what needs to be learned.

CALL-E places the call and returns the structured result, evidence, summary, and provider record.

CALL-E handles the conversation. VINRelease handles the consequences.

How we built it

The runtime path is simple to explain:

Operator approval → CALL-E task → structured result → validation → case decision → evidence-linked transition

Under the hood:

• The live phone path uses the official @call-e/calle TypeScript SDK.
• Each live task is created for one provisioned E.164 recipient with a bounded purpose.
• The authorization preview is hashed with SHA-256. If the recipient, purpose, questions, disclosure fields, or expected transition changes, the old approval no longer matches.
• A stable idempotency key prevents the same approved action from creating a second provider task.
• CALL-E receives a strict recipientResultSchema, so the phone outcome comes back as typed data instead of an unconstrained paragraph.
• A provider-wire schema is normalized into VINRelease’s stricter local domain schema and validated with Zod.
• Provider output never changes the title case directly.
• A deterministic resolution engine decides the next allowed state from the validated result.
• Wrong department, document rejection, case not found, unknown questions, unsafe requests, and unsupported results all have explicit stop behavior.
• Terminal webhook events are deduplicated, then VINRelease fetches the canonical CALL-E Calls API record before applying a terminal result.
• The public judge experience is a deterministic no-call replay, but it goes through the same domain-result and resolution logic as the live workflow.
• npm run verify runs linting, TypeScript checks, 23 Vitest tests, and a production build.

The most important engineering choice is also the least flashy one:

A phone provider can report what happened. It cannot directly declare the business case resolved.

Real CALL-E proof

On September 11, 2026, VINRelease created a real CALL-E task to a user-controlled test number through the production runtime path.

Call ID: call_rkZ1HkMxxjswZKSx1CjCkA

CALL-E completed the task and returned three evidence items plus a schema-valid needs_human result.

The recipient indicated that the synthetic case could be located, but the conversation ended before the blocker or the next owner was established.

That result was incomplete.

So VINRelease did not invent a next step.

For us, that was a better proof than manufacturing a perfect success story. The real SDK path ran, CALL-E returned evidence, and uncertainty stayed uncertainty.

This real task does not prove that a real vehicle title was released. The two-call sequence shown to judges is a separate safe replay.

Why this is a practical problem

VINRelease was not invented around an API demo.

The workflow is familiar title-desk work: track an outstanding title, identify the missing document, follow up with the auction or lienholder, record what was actually confirmed, and keep the case open until the evidence really supports closure.

The opportunity is not to replace the title clerk.

The opportunity is to remove repetitive chase work while keeping the clerk in control of decisions that actually require judgment.

Challenges we ran into

The difficult part was never getting an AI to speak.

It was deciding what the software is allowed to believe after the conversation ends.

During real-call testing we hit a provider-schema mismatch. Instead of smoothing over it, we made the boundary between CALL-E’s wire result and VINRelease’s local domain result explicit.

That became a better architecture: a provider result must be normalized and validated before it can influence the case.

We also had a second problem: how do we let judges experience the entire workflow without accidentally placing a real phone call?

So VINRelease separates two modes clearly:

• Safe demo: deterministic, schema-valid, no external phone side effect.
• Live mode: explicit server-side opt-in, a controlled or consenting destination, and per-call authorization.

The public app defaults to Safe demo. The repository contains the live CALL-E path.

Accomplishments we are proud of

• Completed a real CALL-E SDK task through the production runtime path.
• Built a two-party workflow where the first outside answer determines whether the second phone call is even allowed.
• Made “sent but not received” a real workflow state instead of calling it success.
• Added explicit per-call authorization, minimum disclosure, stale-preview rejection, idempotency, and canonical provider reconciliation.
• Shipped a public no-login judge demo with both the normal path and the human-stop path.
• Added 23 automated tests plus lint, typecheck, and production-build verification.
• Contributed VINRelease to CALL-E’s public awesome-phone-call-agents repository; pull request #463 was merged.

What we learned

A natural voice is useful.

But a natural voice is not the same thing as a trustworthy workflow.

A wrong department is not progress.

A credential request is not something to improvise through.

An incomplete answer should stay incomplete.

And the rule still holds:

$$ \text{Sent} \neq \text{Received} $$

Let the agent handle the conversation. Let deterministic application logic decide what the conversation is allowed to change.

What’s next

The next step is not “give the agent more freedom.”

It is to connect this narrow workflow to the systems a real title team already uses:

• durable multi-user case storage,
• authenticated dealership roles,
• a governed contact directory,
• DMS and title-system integrations,
• a trusted dealership receipt signal before a case can become CLOSED,
• and analytics across repeated auction and lienholder exception patterns.

The product boundary stays the same:

CALL-E reaches the outside world. VINRelease moves the case only as far as the evidence really allows.

Judge path — about two minutes

1. Open vinrelease.vercel.app and confirm the header says Safe demo.
2. Select Resolve next blocker and review the Metro Auto Auction authorization screen.
3. Authorize it. Confirm the blocker becomes Lien release missing and ABC Bank becomes the next approved contact.
4. Authorize the ABC Bank call. Confirm reference LR-4721 and state WAITING_EXTERNAL.
5. Notice that VINRelease still says receipt is unconfirmed. It does not declare victory.
6. Reset, choose Unsupported credential request, authorize the auction replay, and confirm NEEDS_HUMAN.

Links

• Demo video
• Public app
• Source code
• Merged CALL-E contribution — PR #463

Demo integrity

The hosted judge path is a deterministic, schema-valid replay and places no real phone calls.

The $18,700 inventory value is synthetic.

The real CALL-E task described above is separate from the replay and does not claim that a real title was released.

Built With

• call-e
• codex
• elevenlabs
• next.js
• typescript
• vercel
• vitest
• zod