Aurora Concierge: agentic RCS booking with SMS fallback

Inspiration

Aesthetic treatment marketplaces help millions of people research procedures through reviews, before and after photos and Q&A. Their business is turning that research into qualified leads for providers. But the journey usually ends at the lead: there is no consult booking, no calendar and no reminders, so what happens between "I'm interested" and the actual consultation happens outside the platform, and that is where patients drop off.

We built this for a real customer case: RealSelf, a US aesthetic treatments marketplace where consultation booking is on the roadmap but not yet available. Following the hackathon rules, this is a brand new DinoCloud project: no customer code, no customer data, and every provider, slot and appointment is synthetic. "Aurora Concierge" is the product name, and "Aurora Aesthetics Demo" is a fictitious brand used on the RCS testing agent; no customer branding is used in the product.

We picked RCS because it is the native messaging channel on the phone: rich cards, carousels and tappable suggested replies, with no app to install. And since not every device supports RCS, we wanted the experience to degrade gracefully to SMS instead of failing silently.

What it does

Case 1: appointment concierge

1. The patient texts "I want rhinoplasty in Miami".
2. The agent searches verified providers and replies with a short line plus an RCS carousel of up to 5 specialists (name, specialty, rating) with "See availability" and "View profile" buttons.
3. Tapping "See availability" returns up to 4 open slots as suggested replies.
4. Tapping a slot books it and returns a confirmation card with "Reschedule" and "Cancel".
5. If the procedure or the city is missing, the agent asks for one thing at a time. If the slot was just taken, it offers the next ones.
6. The agent never gives clinical advice: questions about symptoms, risks, dosage or recovery are handed off to the consultation with the provider, and urgent wording points to the clinic or 911.

Case 2: 48 h and 24 h reminders with SMS fallback

1. Booking creates two one-time schedules, at T-48h and T-24h. In demo mode they are compressed to 2 and 4 minutes after booking.
2. On an RCS device the patient gets a reminder card with the date, a logistics checklist (documents, questions, medication list for the clinic) and Confirm, Reschedule and Cancel buttons.
3. If the device does not support RCS, or the message is not delivered before its TTL, AWS End User Messaging falls back to SMS: "Reminder: ... 1) Confirm 2) Reschedule 3) Cancel. Reply 1, 2 or 3." The fallback is per-message configuration, not custom retry code.
4. Rescheduling replaces the pending schedules; cancelling deletes them, and a schedule that fires after a cancellation is ignored.
5. Every delivery event (RCS delivered, read, fallback, SMS delivered) is stored and plotted on a CloudWatch dashboard that shows RCS against SMS in real time.

How we built it

Fully serverless, built with AWS CDK v2 in TypeScript across 4 stacks: Data, Agent, Messaging and Observability. All 4 stacks are deployed in a DinoCloud dev account in us-east-1, the AgentCore Runtime is READY, and the RCS agent's two-way messaging is wired to the inbound SNS topic.

The architecture diagram is the first image in the project gallery.

Engineering choices worth calling out:

• Contracts first. SNS events and Gateway tools have written contracts, so channel, agent and tools were built in parallel by different people and tested against the same fixtures.
• Layered guardrails. Input classifier for clinical and urgent questions (English and Spanish) that answers before calling the model, hard rules in the prompt, an output guard for dosage or recovery times, and a contract validator on every reply.
• The demo never goes mute. If Bedrock or Memory fail, the turn is resolved with a deterministic flow over the same Gateway tools. Read tools are retried; writes are not repeated once sent, to avoid double bookings.
• One template, two channels. Each RCS template also produces a GSM-7 SMS version within the SMS length limit, used both by the RCS fallback and by a CHANNEL_MODE=sms plan B.
• Privacy by design, even with synthetic data. Patient text is redacted (email, phone, card, SSN, date of birth, name, address) before reaching the model and again before Memory; logs carry no patient text, only session, path, block types and latency.
• Tested IaC and a deployed smoke test. Jest suites for the Lambdas, templates and CDK assertions, pytest for the agent, and a local mode that runs the full conversation with no AWS calls. On the deployed stacks, a synthetic seed of 309 items and an end to end smoke test (tool calls, Gateway MCP with SigV4, a booking that creates both reminders, T-48h and T-24h schedules in demo mode, and cleanup) all pass.

Challenges we ran into

• RCS testers outside the US. Our team is in Argentina. Registering Argentine numbers as RCS testers failed with COUNTRY_NOT_ENABLED in both the CLI and the console, even though the documentation says the testing agent accepts testers from any country. A US number worked; we opened an AWS Support case.
• Showing SMS fallback from an SMS sandbox. A real US toll-free or 10DLC number needs days or weeks of registration, so the fallback goes through a pool with a US SIMULATOR number. It exercises the full fallback path and emits real delivery events, but it does not deliver to real phones. We show the fallback in the dashboard and the event log instead of pretending it lands on a handset.
• Tooling caught up with the service. AWS CLI 2.33.2 did not include the RCS commands; we had to upgrade. Brand data is not set on the RCS agent but as fields of a TEST_RCS_LAUNCH_REGISTRATION, and a rejected registration version starts empty. All pool identities must match on message type, deletion protection and opt-out list or the call fails with ConflictException.
• Keeping the RCS agent out of CloudFormation. Registration goes through Google and carrier approvals, so the agent and numbers are registered once by a documented script and referenced by id from CDK; a cdk destroy cannot delete them.
• Cold starts. A new AgentCore Runtime session takes a few seconds to warm up, so the demo prewarms the session and the router has its own turn budget.
• Dependency drift. The MCP Python client 2.x changed the streamable HTTP client, which broke our SigV4 auth to the Gateway; we pinned 1.x.

Accomplishments that we're proud of

• A deployed, end to end agentic booking flow on AWS: 4 CDK stacks live, AgentCore Runtime READY, and a smoke test that passes from tool calls through booking, reminder scheduling and cleanup.
• An RCS testing agent ACTIVE in AWS for a fictitious brand, with carousels, rich cards and suggested replies, and two-way messaging wired into the agent. The demo video shows the flow on a registered tester phone.
• SMS fallback as configuration, not code, visible in a live RCS vs SMS dashboard.
• A full AgentCore stack (Runtime, Memory and Gateway with IAM auth) with a deterministic safety net, so a model failure never leaves a patient without an answer or with a double booking.
• Non-clinical guardrails and PII redaction designed for a regulated-adjacent domain, before any real data is involved.
• A repo a team can pick up: four CDK stacks, written event and tool contracts, tests, a gated deploy script, a smoke test and a manual for the RCS registration with verified commands.

What we learned

• RCS changes what a "text message" can do: a carousel plus suggested replies turns a booking flow into three taps, with no app and no web form.
• Fallback should be designed from day one: writing every message once for RCS and once for SMS kept both channels consistent.
• AgentCore Gateway is a clean boundary between the agent and the business tools; it let us split the work by person and test each side alone.
• Sandbox limits (tester countries, simulator numbers) are part of the design, and being explicit about them in the demo builds more trust than hiding them.

What's next

• Move from the testing agent to a launched RCS agent and a registered US toll-free or 10DLC number, so SMS fallback reaches real phones.
• Connect the booking tools to a real scheduling backend through the same Gateway contracts.
• Post-consult follow-up that ends with a review request (non-clinical, with handoff to the clinic for anything health related).
• Opt-in based re-engagement of patients who researched but did not book, once marketing consent is in place.
• Evaluation harness for the agent (tone, non-clinical compliance, booking success rate) on synthetic conversations.

Try it out

• Repository: https://github.com/dinocloud/cds-hackathon-rcs-concierge-public
• Demo video: https://youtu.be/mZCtn2_C_3Y
• Architecture diagram: first image in the project gallery; the source diagram lives in the repository at docs/diagrams/.
• Demo access:
  • Run the whole conversation locally, no AWS account needed: printf 'rhinoplasty in Miami\n1\n1\n' | python3 agent/app.py --local --chat
  • Live RCS on your phone: RCS testing agents only deliver to registered testers. Send us a US mobile number through this Devpost project page and we will register it during the judging window.
  • Deploy your own copy: npm install && npm run synth, then follow the README (RCS agent registration in scripts/register-rcs-agent.md).
• ACE opportunity ID: O29946171

Built With

• amazon-bedrock
• amazon-bedrock-agentcore
• amazon-cloudwatch
• amazon-dynamodb
• amazon-eventbridge-scheduler
• amazon-sns
• anthropic
• aws-cdk
• aws-end-user-messaging
• aws-lambda
• aws-secrets-manager
• claude
• jest
• mcp
• node.js
• pytest
• python
• rcs
• sms
• strands-agents
• typescript