ParcelBridge

A safety-first AI phone-agent prototype for parcel delivery exceptions, with single-use authorization, offline CALL-E runtime proof, and zero real calls.

Comment

Inspiration

Failed parcel deliveries create frustration for recipients and extra operational work for delivery teams. A phone agent could help coordinate a new delivery window, but calling someone is a real-world action that should never happen automatically or without clear permission.

ParcelBridge explores a safety-first alternative: separate planning, authorization, and call execution into distinct stages, and make refusal the default whenever the system cannot prove that an action is authorized.

What it does

ParcelBridge is a reference app for parcel delivery-exception planning.

It demonstrates how an AI phone-agent workflow can:

  • prepare a delivery coordination plan;
  • use explicit, single-use plan-only authorization;
  • prevent automatic retries after an authorization is consumed;
  • keep recipient data out of process arguments, environment variables, logs, and disk argument files;
  • sanitize capability-shaped values before they reach the caller;
  • reject phone-shaped or secret-shaped user input;
  • omit run_call and all real dialing behavior.

The public demo is intentionally offline and synthetic. It does not contact a live CALL-E endpoint and does not place a real phone call.

How we built it

ParcelBridge includes two reproducible demo surfaces.

Python offline reference app

The Python app builds fictional delivery-exception payloads, passes them through an in-process synthetic MCP response source, and applies fail-closed sanitization before returning a result.

It includes:

  • recursive sanitization of nested JSON-like data;
  • rejection of unsupported nested types;
  • phone-shape detection for user-provided notes;
  • secret-shape detection;
  • no raw response persistence;
  • no capability-value persistence;
  • no network access;
  • no dialing path.

Official CALL-E runtime offline proof

The Node bridge installs the exact-pinned official dependency:

@call-e/[email protected]

It imports:

@call-e/core/mcp-client

and genuinely executes the official:

callMcpTool

function against an injected offline synthetic fetchImpl.

This allows reviewers to reproduce the official CALL-E runtime integration without using a live CALL-E endpoint, real OAuth credentials, or a real phone number.

The proof observes the MCP sequence:

  • initialize
  • notifications/initialized
  • tools/call
  • tool name: plan_call

It does not invoke:

  • run_call
  • get_call_run
  • track_ui_events

Challenges we faced

The most difficult part was not building a demo screen. It was proving that the system fails safely.

During development we found and fixed several important issues:

  • automated tests were able to delete a real recipient file;
  • an early transport path wrote phone-bearing arguments to a temporary file;
  • a CLI argument-file option was not actually consumed;
  • a consent form had a CSRF cookie and hidden-field state mismatch;
  • a successful form response did not initially trigger the required record migration;
  • an offline synthetic READY response was initially at risk of being mistaken for a live provider result;
  • the first public package version was not valid PEP 440;
  • user notes were parsed but not consistently enforced by the payload policy;
  • the sanitizer originally did not recursively validate nested values;
  • a public fake MCP boundary could expose raw capability-shaped values before sanitization.

Each issue was handled with a fail-closed correction and regression tests.

Accomplishments

We are proud that ParcelBridge now provides:

  • a public and reproducible reference app;
  • exact-pinned official CALL-E runtime integration;
  • a real execution of callMcpTool using an injected offline transport;
  • standard editable Python installation with no PYTHONPATH workaround;
  • 148 passing Python tests;
  • 12 passing Node tests;
  • recursive response sanitization;
  • phone-shape and secret-shape input rejection;
  • zero live CALL-E endpoint requests in the submitted demo;
  • zero real OAuth credential reads;
  • zero run_call invocations;
  • zero real phone calls.

The public contribution is available as CALL-E repository PR #84.

What we learned

The most important lesson was that using an official SDK is not the same as proving a live provider call.

We learned to distinguish clearly between:

  • importing official runtime code;
  • executing the official runtime;
  • using a synthetic transport;
  • contacting a live endpoint;
  • generating a plan;
  • executing a real phone call.

We also learned that safety evidence must be reproducible. A private implementation or an internal test report is not enough if reviewers cannot run the same public workflow themselves.

What's next

The next technical step would be a separately authorized live CALL-E plan_call validation with real endpoint-provenance evidence.

That future validation would still remain plan-only. Real call execution would require a new, independent human authorization and would remain outside the current public reference app.

ParcelBridge does not claim:

  • live CALL-E endpoint validation;
  • provider-verified business semantics;
  • a real phone call;
  • production readiness.

Built With

Share this project:

Updates

Submission history