Kanverse Human API

Kanverse Human API turns phone-only services into goal-driven workflows, using CALL-E to call targets, evaluate outcomes, and continue automatically until the goal is achieved.

Comment

Inspiration

A huge part of the real world still has no API. Local shops, repair services, clinics, offices, suppliers, and many other organizations can only be reached by phone.

We wanted to explore a simple idea: what if a phone number could behave like an API endpoint?

That became Kanverse Human API — a goal-driven layer that uses CALL-E to interact with phone-only services and turns the results into structured decisions.

What it does

The user gives Human API a goal and one or more authorized phone targets.

For example:

“Find a repair shop that can replace my phone screen tomorrow for under £80.”

Human API prepares a CALL-E plan for the first target. After explicit user confirmation, CALL-E can make the real phone call and return a structured outcome. Human API then evaluates that result.

If the goal was achieved, the mission stops. If not, CallChain automatically prepares the next authorized target, but a new explicit user confirmation is required before another real call can be placed. If the result is ambiguous, Human API stops for human review.

Real-world use case: trusted-contact outreach

Human API can call an approved well-wisher with a requested message or question. If CALL-E reports that the goal was not achieved, CallChain evaluates the structured outcome and prepares the next approved contact for fresh user confirmation.

The submitted demo shows a real CALL-E call, while the multi-target continuation path is demonstrated through the project's safe local Dry Run.

How we built it

The prototype uses:

HTML, CSS, and JavaScript for the interface and mission orchestration Node.js and Express for the local backend The official @call-e/core MCP client CALL-E's plan_call, run_call, and get_call_run operations

The browser manages the mission and CallChain state, while the backend securely bridges the application to CALL-E.

We also built a visual dashboard that shows the current mission, each target's bounded outcome, whether Human API should continue or stop, and the CallChain history.

Safety

Human API starts in Dry Run mode by default.

This allows the workflow to be demonstrated and tested without placing real calls, contacting CALL-E, or consuming CALL-E call credits.

Live Mode must be enabled deliberately. The server also requires authentication, an explicit destination allowlist, valid E.164 numbers, explicit live intent, and a short-lived one-time approval token.

Changing modes invalidates the existing plan. Even in Live Mode, every real call requires a separate Confirm & Call action. Ambiguous outcomes stop the chain for human review instead of triggering another call.

Sensitive CALL-E identifiers remain on the server, while browser-visible status information is bounded and phone-number-redacted.

Challenges we ran into

One challenge was reliably connecting the Node.js backend to CALL-E on Windows. We had to align the application with the authenticated CALL-E token cache and official MCP server URL.

Another challenge was designing multi-call orchestration safely. We wanted Human API to make decisions from structured outcomes without making uncontrolled calls. The solution was to separate automatic evaluation and preparation from explicit permission to place each real call.

Accomplishments that we're proud of

We successfully validated the CALL-E lifecycle with a real outbound test call:

plan → confirmation → real call → status → structured outcome → next-step decision.

We also built a working multi-target CallChain, demonstrated safely in Dry Run, where one target can fail, Human API evaluates the result, prepares another target, and stops once the goal is achieved.

What we learned

CALL-E can be more than the communication layer for a single AI phone call.

By combining structured call outcomes with an orchestration layer, phone conversations can become components of larger software workflows.

The key insight behind Human API is:

CALL-E handles the call. Human API handles the mission.

What's next for Kanverse Human API

We want to expand Human API beyond manually entered phone numbers.

Future versions could discover appropriate targets, extract richer structured data from each interaction, compare options, schedule follow-up calls, and expose reusable goal-driven workflows to other apps and AI agents.

Ultimately, the idea is to make parts of the offline world programmatically accessible:

Human ↔ Machine ↔ World

Share this project:

Updates

Submission history