LostLine

Inspiration

Losing an item rarely means knowing the one place to call. It means reconstructing a route, finding official numbers, repeating the description, handling voicemail or refusal, and reconciling inconsistent answers. That is useful phone work to automate—but a careless agent could reveal identity, overclaim ownership, or place unnecessary calls.

LostLine focuses on the practical middle: coordinate the repetitive inquiry, minimize disclosure, stop when the evidence is strong enough, and leave the final claim with the person.

What it does

LostLine is a consent-first lost-property route coordinator. It:

• requires fresh owner authorization, a separately withheld proof detail, recently human-verified public contacts, confirmed calling hours, and a short approved live window;
• limits item facts to short hand-authored ASCII-English noun phrases and rejects unknown, sensitive, prompt-like, duplicate, or out-of-scope input;
• previews every disclosed fact, the exact CALL-E task, masked destinations, call cap, and a receipt bound to the full request;
• requires the caller to disclose AI identity, CALL-E processing/transcription, and possible audio recording where enabled, then records structured explicit agreement before accepting item evidence;
• creates one independently idempotent CALL-E task at a time and durably checkpoints the accepted call ID before polling;
• accepts only strict per-recipient enums and feature IDs, rejects numeric-heavy reference codes, and never retains provider free-form text;
• computes confidence locally instead of copying model confidence; and
• stops before later destinations after a reached desk reports an item with at least two distinct matched features and no contradiction.

It never claims, reserves, buys, pays for, picks up, or arranges delivery of an item.

How we built it

LostLine is a focused TypeScript app using the official @call-e/calle 0.2.2 SDK. The SDK is imported only on the live path; preview, tests, and the local demo need no account, credential, network, or phone line.

The live adapter uses calls.create() and calls.waitForResult() separately. Before create, LostLine reserves a private mode-0600 output and records the side-effect-derived idempotency key. After CALL-E accepts a task, it atomically persists the public call ID before polling. If polling fails, the checkpoint remains for manual dashboard reconciliation instead of a blind retry.

The result schema uses additionalProperties: false, a required post-disclosure agreement boolean, and safe enums for desk state, item state, retrieval mode, and matched/contradicted feature IDs. The local validator also requires a completed top-level task, exactly one completed recipient, and one exact destination match. strong requires agreement, a reached desk, item yes, two or more distinct matched feature IDs, and zero contradictions.

Challenges

The first challenge was separating useful matching details from ownership proof. The request confirms that a separate claim-verification detail is withheld, and the calling task forbids asking for claimant identity or proof.

The second was crash-safe recovery. A process can fail after a provider accepts a call. We derive idempotency from the exact side effect, checkpoint before create, persist the call ID before polling, use fsynced same-directory temporary files plus atomic rename, and never retry automatically after uncertainty.

The third was making “coordinator” more than a batch wrapper. LostLine calls an ordered route one destination at a time, derives confidence locally, stops on invalid output or provider failure, and avoids later calls once the evidence threshold is met.

Accomplishments

• The fictional local demo plans three destinations, accepts a validated candidate on task two, and avoids task three.
• The real official SDK adapter is exercised through an in-memory transport, covering create, Idempotency-Key, snake_case wire serialization, polling, and camelCase result conversion without a socket or credential.
• 18/18 safety, behavior, consent-result, durability, CLI-gate, adaptive-routing, and SDK tests pass, along with strict TypeScript checking and the official repository validator.
• API credentials may go only to the exact https://api.heycall-e.com origin.
• Provider summaries, transcripts, recordings, URLs, addresses, payment instructions, and sensitive-looking reference codes are excluded from the private report.

Evidence boundary

The current public demo is deliberately local and fictional: no network, real phone, credential, or live CALL-E outcome is shown or implied. Controlled live proof remains pending confirmation of a usable free-call balance, no card or automatic charging, any required user-completed KYC, and one adult test participant who understands provider processing and unspecified retention. Any later live evidence will be redacted to task/terminal status, structured fields, call counts, and free-balance delta only.

What we learned

Phone agents need a narrower authority model than chat assistants. A useful workflow must expose the exact disclosure, bind consent to the exact request, checkpoint irreversible side effects, distrust provider output, and keep the final ownership decision human.

We also learned that an idempotency key should represent the normalized side effect, not just the UI request, and that recipient correlation must not rely on response-array position.

What's next

• Run one controlled, consenting-recipient, zero-cost CALL-E proof after every external gate is satisfied.
• Validate the disclosure and structured fields with lost-and-found operators.
• Add a local review UI for the route, evidence chips, calls avoided, and the safe next-action card.
• Explore caller-owned recipient correlation IDs, cancellation, checkpoint hooks, balance visibility, and per-call retention controls if CALL-E adds them.

Built With

• call-e