Inspiration
What it does
How we built it
Challenges we ran into
Accomplishments that we're proud of
What we learned
What's next for SurplusSignal
Inspiration
Food rescue coordinators often work inside short pickup windows. A donor's earlier pledge may have changed, but a free-form phone summary is not safe enough to dispatch from. Silence can look like consent, revised quantities can disappear into notes, and a summary may contain more personal data than the driver needs.
What it does
SurplusSignal prepares one consent-first confirmation call at a time. It checks that the donor opted in to an automated call for the current drive, previews the exact disclosure and task, and binds the request to a receipt before live mode can run.
The call asks only for a small structured result: whether the recipient agrees to continue, whether the pledge is confirmed, reduced, or withdrawn, the remaining quantity, one offered pickup window, storage mode, packaging state, and whether a person must follow up. The local validator rejects extra fields, contradictory answers, wrong phone or call bindings, and incomplete provider outcomes.
A valid result becomes a redacted candidate for human review. It is never treated as an accepted donation or a scheduled pickup. The dispatcher still verifies identity, address, food handling, route capacity, and every real-world commitment.
How we built it
The project is a TypeScript application using the official @call-e/calle SDK. The live path requires current consent, recent operator authorization, two explicit execution flags, a content-bound receipt, and a newly created private report file. It creates calls sequentially and stops after a provider error or malformed result.
The React dashboard runs against a checked-in fictional fixture. It uses no credentials, makes no network requests, and cannot place a phone call. It shows the same disclosure, agreement gate, structured result, and human-review boundary used by the application.
The implementation includes eleven passing tests. They cover the SDK contract, deterministic masked previews, disclosure wording, strict input parsing, time windows, semantic contradictions, refusal handling, fail-closed sequencing, and private report permissions.
Challenges we ran into
The hardest part was keeping a time-sensitive workflow useful without letting an AI-generated summary become an operational decision. The app therefore treats provider output as evidence to validate, not as an instruction to dispatch.
We attempted one controlled call to a user-owned South Korean number. CALL-E rejected the unsupported Korean locale before dialing. No call was placed and there was no charge. The submitted demo uses the local simulation and does not claim that a live conversation occurred.
Accomplishments that we're proud of
The contribution was merged into CALL-E's public Awesome Phone Call Agents repository. It provides a reusable reference for consent, idempotency, result validation, redaction, and human review in a real phone-work use case.
What we learned
A phone agent needs stronger boundaries than a chatbot. Consent must be specific to the call, retries need stable identifiers, and a positive-sounding answer is not enough. The recipient, provider task, phone number, allowed quantity, and offered time slot all need to agree before a row can enter the review queue.
What's next for SurplusSignal
The next step is live validation in a locale and destination supported by CALL-E, using an expressly opted-in test participant. The workflow will keep the same human-review boundary and will not add automatic dispatch.
Built with
TypeScript, React, Vite, Node.js, @call-e/calle, and the CALL-E API contract.
Built With
- call-e
- node.js
- react
- typescript
- vite
Log in or sign up for Devpost to join the conversation.