Lead Rescue Engine

A Strands agent that finds lead-path failures without turning automation into spam or fake progress.

Comment

Inspiration

Small businesses can lose inquiries when quote/contact paths fail. But careless outreach automation can create a second failure: duplicate messages, false-positive claims, and stage inflation. Lead Rescue Engine is designed to reduce both problems.

What it does

Lead Rescue is an evidence-first Professional Agent. It performs GET-only public-page inspection, separates clear evidence from ambiguity and template noise, prepares mandatory Gmail-history dedupe searches before outreach, blocks protected/consequential actions, and advances a lifecycle only when specific evidence exists.

Lifecycle: FOUND → VERIFIED → DEDUPE_CLEARED → SENT → REPLIED → ACCEPTED → FUNDED → COMPLETED → PAID.

A visible error is a public symptom, not proof of root cause or lost revenue. A fetch failure stays UNVERIFIED. The agent itself never submits a real customer form or bulk-sends outreach.

How we built it

The Strands TypeScript implementation coordinates four bounded tools:

  • public-page inspection
  • Gmail dedupe preparation
  • evidence-ledger advancement
  • requested-action safety classification

Deterministic policy surrounds model judgment so the agent cannot skip evidence stages or silently authorize protected/consequential actions.

The v0.3 judgeable local web demo contains four adversarial cases: a clear visible error, a success+error conflict, a clean form, and template-junk content.

What changed after red-teaming

A current public transportation quote page exposed a false-positive case: its indexed text contains both a form-submitted success message and an error message. That falsified the naive rule “visible error means broken.” v0.3 now returns AMBIGUOUS_REVIEW and requires manual reproduction.

Separate current search results also exposed template/placeholder pages with the same error copy, so v0.3 downranks multiple placeholder signals as LOW_TRUST_TEMPLATE.

Verification checkpoint

  • deterministic/safety suite: 20/20 PASS
  • local HTTP health endpoint: PASS
  • local judgeable web demo: PASS
  • ambiguity negative control: PASS
  • template-junk negative control: PASS
  • Strands Agent/tool implementation: WRITTEN against the current official TypeScript API
  • live Strands package/model invocation: NOT YET VERIFIED in this build environment because package-network installation is unavailable

Friction / truth boundary

The public GitHub repo currently has a serious completeness gap: its README references source paths that are not present. GitHub write operations through the connected integration returned 403 on two separate write routes, so I am not claiming the repo is submission-ready. The corrected v0.3 package is preserved locally and publication remains an explicit infrastructure blocker.

Prior-work disclosure

This project is informed by earlier Lead Rescue, HandoffGuard, and Family reliability experiments. The v0.3 evidence-first implementation materially changes the detector, safety policy, lifecycle, tests, and demo. Final submission will point only to a public repo that actually contains the contest package and will disclose reused context/code accurately.

What's next

Publish the complete MIT-licensed v0.3 package, run a networked Strands invocation, deploy the judgeable demo, attach the required architecture diagram, record the <=5-minute video, then complete the required AWS Builder ID and contest attestations.

Built With

Share this project:

Updates