FreshChain Resolver

Inspiration

Cold-chain delivery delays often trigger repeated calls among dispatchers, receiving desks, and quality teams. One unanswered call can cause detention, a missed receiving window, or avoidable product waste. We built FreshChain Resolver to automate this narrow but expensive coordination problem while keeping product-safety authority with humans.

What it does

FreshChain Resolver turns a delayed temperature-controlled shipment into a consent-aware CALL-E phone workflow. The agent contacts an authorized operations representative, identifies itself as AI, confirms whether the site can receive at the predicted arrival, captures dock and manual check-in instructions, or obtains the next receiving window.

CALL-E's structured result is normalized into exactly one downstream route:

• proceed — the authorized site accepts the ETA
• rebook — a new receiving window is confirmed
• hold — temperature status requires human quality review
• escalate — consent, identity, or the outcome is unclear

Unknown or out-of-range temperature always becomes hold. The agent cannot override quality controls, authorize disposal, or decide whether a product is safe.

How we built it

The Python MVP uses the published calle-ai==0.2.0 SDK, a validated delivery-exception web form, SQLite call history, a decision dashboard, explicit live-call confirmation, stable idempotency keys, strict JSON results, masking, and output redaction. Preview mode never calls. Deterministic simulation demonstrates the complete workflow safely.

The live adapter imports and invokes CALL-E at runtime. A retained integration log proves that the published SDK sends POST /v1/calls, preserves authorization and idempotency headers, and polls GET /v1/calls/{id} before parsing a structured result. This test is separate from simulation. All 16 pytest tests and 14 subtests pass.

Verification boundary and challenge

CALL-E account/MCP authentication was completed, and the Developer API key configuration and production SDK path are implemented. An authorized South Korean recipient was supplied for final cloud verification. CALL-E rejected both Korean and English plans because +82 is not currently a supported recipient region. Both returned ready_to_run=false with no confirmation token, so no outbound call occurred.

We do not present simulation as a successful live call. The limitation is regional platform support, not an unimplemented call path. A supported authorized recipient can use the cloud path without a code change.

Accomplishments

• Functional delivery-delay input and decision dashboard
• Structured proceed / rebook / hold / escalate routing
• Protected real CALL-E execution path
• No-call simulation and masked preview
• Published-SDK runtime HTTP proof
• 16 passing pytest tests and 14 passing subtests
• Reusable contribution merged into the official CALLE-AI/awesome-phone-call-agents main branch as PR #45 after multiple rounds of security and operational-safety review

What's next

When CALL-E supports South Korean recipients, we will add the live-call recording, then connect the structured decision to warehouse and transport systems. The same safety-bounded pattern can support refrigerated food, pharmaceutical logistics, and other receiving-window exceptions.

Built With

• call-e-sdk
• github
• http
• python
• sqlite