RecallAI

Recall AI: agentic recall platform on AWS CDS, reaching, verifying and guiding every owner via RCS, WhatsApp and email to turn recalls into tracked, doorstep service with verified repair closure.

Comment

RecallAI: Turning Vehicle Recalls into One Conversation, from Notice to Repaired Car

💡 Inspiration

Safety recalls exist to save lives, yet many go unrepaired. Owners get a letter they never read, don't realise the risk, or can't find the time to book a service visit. After a resale, the recall often goes to someone who doesn't even own the car any more. An open airbag inflator recall isn't paperwork; it's a safety risk on the road.

We asked a simple question: what if the recall notice started the repair, instead of asking the owner to? That idea became RecallAI, an agentic recall platform built on AWS Communication Developer Services (CDS) with Amazon Bedrock AgentCore. It reaches the owner on RCS, carries the same conversation on to WhatsApp and email, and manages the whole journey: notify → verify → educate → book with a free tow → repair → close.

🚗 What it does

  1. Identify: the OEM uploads a campaign CSV of affected VINs. Each VIN is checked (format, ISO 3779 check digit, duplicates) and becomes one tracked recall case.
  2. Notify on RCS: the owner of record gets an RCS rich card with the recall, a Do-Not-Drive warning, a View recall details page (with a video) and two buttons: I am the owner / I am not the owner.
  3. Continue on WhatsApp: I am the owner sends a Meta-approved WhatsApp message to the owner, and the same case carries on there. RCS tells them that from now on everything about this recall comes on WhatsApp.
  4. Verify: the owner replies with a photo of the VIN plate. Claude reads it and only an exact match verifies the car; after three wrong photos, a person takes over.
  5. Engage: the owner asks anything in plain language ("Is it safe to drive?", "Will I pay?"). The Recall agent answers only from the OEM's approved recall content and escalates anything else to a human.
  6. Book with a free tow: the owner shares a location, picks a real nearby dealer (Amazon Location Service) and a time. Because the recall is Do-Not-Drive, a free tow is arranged before the booking is accepted. The owner gets a confirmation, a unique check-in QR code and a next-steps video.
  7. Repair & update: status updates at every stage: tow reminder → tow on the way → picked up → checked in → repair in progress → repaired → back home. The "repair complete" message goes out on RCS and WhatsApp, followed by a summary email.
  8. Close: the owner rates the experience and the case is completed, with a full audit trail.
  9. Wrong owner? I am not the owner thanks the recipient and stops all messages to them. The Validation agent weighs seven ownership sources, finds the likely new owner and starts their journey on WhatsApp, which fixes the OEM's records along the way.

The OEM console shows every case live, step by step, and labels who did each step: an AI agent (with "via Supervisor" when the Supervisor routed it), an AI model, automation or a person.

🛠️ How we built it

We used Kiro, AWS's agentic IDE, as our build partner from start to finish:

  • Spec-driven development: we wrote the recall journey as requirements (17 of them, in EARS format), a design document and an ordered task list, then built milestone by milestone from those specs to working code. Each spec keeps an "as built" section, so the docs still match the code.
  • Agentic coding: Kiro's agents wrote and refactored most of the Lambda functions, the three agents, the React console and the boto3 deployment scripts. For larger changes we used Kiro workflows with an implement-and-review loop.
  • Steering, skills and hooks: steering files keep every change in line with our architecture and security rules, with always-on rules plus area rules that load only for the backend, agents, UI or deploy code. Skills package our everyday jobs (run tests, update a Lambda, redeploy the agent, deploy the console). Hooks block secrets from ever being committed and remind us to update the docs when behaviour changes.

The platform itself is built on:

  • Communication backbone (CDS), all used at runtime on the same case:
    • AWS End User Messaging (EUM) – RCS: the recall rich card, the owner's replies and delivery events through Amazon SNS, the "continue on WhatsApp" message, the reply to I am not the owner, and the repair-complete message.
    • AWS End User Messaging Social – WhatsApp: the approved template that opens the conversation, then the whole two-way journey (see below).
    • Amazon Simple Email Service (SES): the "repair complete" summary email.
  • Agentic layer (Amazon Bedrock AgentCore): three agents, built with the Strands Agents SDK, run in one AgentCore Runtime with Memory, Identity and Observability switched on.
    • The Supervisor routes every incoming message to the right agent or fixed step.
    • The Validation agent (Claude Sonnet 4.5) handles the WhatsApp handoff and the ownership check.
    • The Recall agent (Claude Haiku 4.5) answers the owner's questions.

Routine turns use the faster model and hard reasoning the stronger one, retrying on the other if one is throttled.

  • Event-driven orchestration: replies arrive through Amazon SNS at a webhook Lambda, flow through Amazon EventBridge and reach the AgentCore Runtime. Nothing runs on always-on servers. Steps that must happen exactly once (dealer list, tow, booking) run as plain code, so they reply in one to eight seconds and never happen twice.
  • Guardrails by design:
    • agents act only through tool Lambdas;
    • every status change goes through one recordStatus transaction with an append-only audit entry;
    • every outgoing message passes one dispatcher that enforces opt-out, suppression and quiet hours;
    • phone numbers, emails and VINs are masked in logs, API responses and model prompts.
  • Location (Amazon Location Service): real nearby Honda dealers first, then multi-brand car workshops, each with distance and address. The tow pickup is planned from the owner's shared location.
  • Data & state: Amazon DynamoDB (single table) holds campaigns, cases, messages, appointments, tows and the audit trail. VIN photos are stored in Amazon S3, encrypted with AWS KMS.
  • Verification:
    • Claude Haiku 4.5 reads the VIN photo, and Claude Sonnet 4.5 re-reads any unclear one.
    • A unique, single-use signed QR code is created for each booking, for check-in at the dealer.
  • Console: React on Amazon S3 and CloudFront, with Amazon Cognito roles for the OEM, dealers and evaluators, and a no-login guest link for judges.
  • Reproducible: idempotent Python + boto3 deploy.py / teardown.py, and 313 automated tests that run with no live AWS or model calls.

💬 How we used WhatsApp (AWS End User Messaging Social)

Most of the conversation happens on WhatsApp, all through AWS End User Messaging Social:

  • Business-initiated Utility template (recall_vin_verify_v1, Meta-approved): an image header with the brand banner (uploaded with PostWhatsAppMessageMedia), the recall and Do-Not-Drive message, and the VIN photo request. Approval is checked before every send, with a wa.me link on RCS as the fallback.
  • The 24-hour window:
    • reply buttons for quick questions, Book my repair and feedback;
    • list messages for dealers and appointment times;
    • a native location request;
    • an image message for the QR code;
    • a link preview for the video.
  • Rich inbound: VIN plate photos go straight into encrypted S3 (GetWhatsAppMessageMedia) and are read by Claude. Location pins, list and button replies, and free text all arrive through Amazon SNS.
  • Feels human: every message is marked read with a typing indicator while the reply is prepared. Delivery receipts keep the order right; for example, the video waits until the QR code has been delivered.
  • Agents on WhatsApp: the Supervisor routes each message, the Recall agent answers in the chat, and the Validation agent starts a new owner's journey with the same template.
  • Respecting the channel: one number per case, opt-out and suppression on every send, approved templates only, and demo limits that protect the number's quality rating.

📈 How we measure it

A campaign succeeds when cars get repaired, so the headline metric is

$$ \text{Recall Completion Rate} = \frac{\text{Vehicles repaired}}{\text{Vehicles affected}} \times 100\% $$

and every case moves through a funnel the OEM can watch:

$$ \text{Notified} \;\rightarrow\; \text{Verified} \;\rightarrow\; \text{Booked} \;\rightarrow\; \text{Repaired} \;\rightarrow\; \text{Closed} $$

A vehicle counts as verified only when the VIN read from the photo, $\hat{v}$, exactly matches the VIN on the case, $v$, with enough confidence $c$:

$$ \text{verified} \iff \hat{v} = v \;\wedge\; |v| = 17 \;\wedge\; c \ge 0.85 $$

For a Do-Not-Drive recall the tow comes before the repair, so the pickup is planned back from the appointment time $t_{\text{slot}}$:

$$ t_{\text{pickup}} = t_{\text{slot}} - 60\ \text{min} $$

🧗 Challenges we ran into

  • Cross-channel continuity: keeping one conversation and one case consistent as the owner moves from RCS to WhatsApp, and sending the closure back out on RCS, WhatsApp and email.
  • Channel rules: WhatsApp template approval, the 24-hour window, and RCS reach. Our RCS agent is still a testing agent, and RCS isn't offered in India, so we added a way to start the journey directly on WhatsApp.
  • Message order on the phone: the video could overtake the QR image, so delivery receipts now decide when the next message goes.
  • Exactly once, every time: stopping duplicate replies and double bookings when messages arrive close together, using a per-case lock and plain code for the booking.
  • Consent & compliance: respecting opt-outs, suppression and quiet hours on every channel, and never messaging someone again after I am not the owner.
  • Agent guardrails: keeping answers inside the approved recall content, keeping Do-Not-Drive safety advice prominent, and sending anything else to a human.
  • Showing the agents' work honestly: recording which agent, model or person handled each step, so the console shows real involvement rather than claims.

🏆 Accomplishments that we're proud of

  • A real cross-channel conversation, end to end on real phones: the RCS recall card, then WhatsApp for verification, questions, booking, QR code and video, then the closure on RCS and WhatsApp and a summary email. It all runs on one case, with nothing restarted along the way.
  • Three CDS services and Amazon Bedrock AgentCore working as one system: the Supervisor, Validation and Recall agents decide what to do. AWS End User Messaging (RCS), AWS End User Messaging Social (WhatsApp) and Amazon SES deliver it.
  • AI where it adds value, exact code where it must be exact: Claude reads VIN plate photos, agents answer open questions and weigh ownership evidence, and bookings and tows happen exactly once in one to eight seconds.
  • Fixing the owner of record, not just messaging it: after I am not the owner, the Validation agent checks seven sources, refuses to trust a resold car's old owner, and starts the new owner's journey on WhatsApp.
  • Safety and privacy that agents can't bypass: one audited path for every status change, one dispatcher that enforces opt-out and suppression on every message, and PII masked in logs, prompts and the console.
  • Transparent agents: the console shows every step live and who handled it (an agent, a model, automation or a person), taken from recorded data.
  • Built to be picked up: idempotent boto3 deploy scripts, 313 automated tests, and Kiro specs, steering, skills and hooks in the repo, so another team can continue from a fresh clone.
  • Open for evaluators: a no-login guest link starts the WhatsApp journey on the evaluator's own phone, with guardrails that protect the number's quality rating.

📚 What we learned

  • Communication is often what holds back recall completion: the right message on the right channel at the right time changes outcomes.
  • Spec-driven development with Kiro made the build faster and more consistent. Clear specs and steering rules led to better code from the agents, and keeping "as built" notes stopped the docs drifting.
  • Agentic AI works best when it is grounded in a clear workflow with strong guardrails. Agents do the reasoning; plain code does the steps that must be exact.
  • Cross-channel continuity is a data problem first. Once every tap and message belongs to one case, moving from RCS to WhatsApp to email feels natural.
  • CDS let us move from one-way notifications to a two-way, fully traceable conversation.

🚀 What's next for RecallAI

  • RCS → SMS fallback for phones without RCS, plus an RCS country launch so the notice can reach every owner.
  • Connect to OEM and dealer management systems for live recall feeds, real appointment slots, check-in and work-order completion.
  • More ownership scenarios (owner unknown, a review queue for the recall team).
  • Templates with variables for every make and model, and more languages.
  • Contact the highest-risk vehicles first, and extend the model to medical device and consumer product recalls.

▶️ Try it

Demo brand: Honda-Wipro Automotive (fictional). Demo – not a real recall. Dealers are real places but are never contacted; slots, towing and ownership records are simulated; the days after booking are fast-forwarded to about 30 seconds.

RecallAI: the recall comes to you, and doesn't stop until your car is fixed.

Built With

Share this project:

Updates

Submission history