CreditCall

Why I built it

Accounts payable software is good at finding exceptions. The awkward part comes next: somebody still has to call, explain the issue, and find out how the supplier wants it handled. CreditCall turns that loose follow-up into one bounded phone task while keeping a person in control.

What it does

CreditCall reads a fictional invoice packet and calculates the exception in regular JavaScript. Eight monitor arms were ordered at $94 CAD and invoiced at $119 CAD, so the verified difference is $200.

Before a phone number is submitted, the workflow requires:

a named human approver;
explicit consent from the test recipient; and
a separate final confirmation to start exactly one call.

CALL-E then places a disclosed automated test call. It explains the fictional exception, asks whether the preferred credit-request route is email or a vendor portal, and returns a structured result. It never approves payment or asks for credentials, payment details, or personal information.

The live test

I tested CreditCall on August 31, 2026 using my own consented number. The carrier's call-screening service answered first. CALL-E still completed the task, captured email as the follow-up preference, and returned a completed result with 0.92 confidence after 36 seconds.

The repository intentionally does not publish provider output, phone numbers, call IDs, or transcripts. The public demo still shows the screening edge case and the resulting safety changes.

That test found a real edge case. The next revision tells the agent to give screening only its name and a short reason. When a person joins, it repeats the automation disclosure, asks whether they are ready, and waits. Screening replies can never count as approval or a follow-up choice.

How I built it

The app uses Node.js and CALL-E through MCP and the official CLI. Planning, execution, and status checks are separate steps. A local single-use reservation blocks duplicate starts for the same plan. Terminal output masks phone numbers recursively. The default command is a dry run that never places a call.

Eight Node tests cover the $200 calculation, consent and approval gates, disclosure, call screening, E.164 validation, and phone-number masking. The full upstream repository validation also passes.

Challenges

The hard part was not the arithmetic. It was treating a phone call as a real side effect. A retry must never happen silently. An uncertain start must be recovered, not repeated. A carrier's screening system must not be mistaken for a person. Useful proof must not publish private call data.

What is next

The next useful step is an adapter that accepts a verified exception from an accounts payable system and writes the structured CALL-E result back to the case. The same safety boundary stays in place: code verifies the amount, a person approves the outreach, and the phone agent only collects the next step.