Relay — Rescue the Afternoon

A late pickup is rarely just a late pickup. It changes work commitments, travel, groceries and dinner. We wanted a household assistant that can make those dependencies visible and help a parent choose a workable recovery while under pressure.

What it does

Relay is a working simulated Alexa+ experience for household recovery. Enter “Alex is delayed by 45 minutes. School closes at 3:10. Don't move my client call. Keep spending under $10.” Relay retains those facts, checks caregiver permission and availability, travel, deadlines, meeting locks and budget, then compares feasible alternatives. It reports honestly when no safe option remains.

Before applying a proposal, Relay shows the exact schedule changes and asks for approval. It records receipts, supports undo, and preserves household state after a refresh. A failure demonstration rolls back partial task changes, blocks the failed workflow, and offers different alternatives for fresh review. A calendar importer previews one-day ICS commitments without modifying the original calendar.

How we built it

React and TypeScript power the interface. A shared JavaScript domain engine validates constraints and versions proposals against current household state. The official Model Context Protocol SDK exposes ten tools, including disruption reporting, calendar import, proposal generation, confirmation, execution and undo. The public MCP endpoint uses Streamable HTTP and protocol version 2025-11-25.

The deployed simulator uses an SDK MCP client over an in-process transport and per-user D1 persistence. A separately runnable Node server uses actual HTTP MCP and SQLite. The default conversation host is a labeled rules-based intent parser, not a language model. We used Codex as the agentic development tool. The repository includes an optional Bedrock host, but no live Bedrock integration is claimed.

Challenges

The key challenge was making approval meaningful after household facts change. Proposals are tied to the current state revision, and stale proposals cannot execute. Cumulative disruptions preserve earlier constraints. Failure handling restores sandbox tasks before generating new alternatives. Calendar import rejects unsupported forms instead of silently interpreting them incorrectly.

Accomplishments

We built a working end-to-end simulator with real MCP tools, explicit approval, failure recovery, undo and persistent state. Typechecking, the production build and 41 automated tests passed. Browser verification confirmed that a compound request generated a feasible proposal, approval applied it, and the committed state survived a reload.

What we learned

A useful assistant must explain the consequences of a decision and keep its actions grounded in current facts. A plausible response is not enough: permissions, deadlines, approval and failure behavior need explicit enforcement.

What's next

Verify the optional Bedrock host with real AWS credentials and model access, add real calendar and household-service adapters, and evaluate broader natural-language requests. Real service integrations will require account linking, idempotency and compensation beyond the current sandbox.

Track

Alexa+ — simulated-experience route. No AWS Builder or additional Open Source mini-challenge claim.

Working demo

https://relay-household-rescue.mistylamp32.chatgpt.site

The deployed demo currently requires the owner's Site authentication. Do not present it as publicly accessible to judges. The source includes local setup instructions requiring no AWS credentials. Household actions are simulated; this is not a live Alexa+ integration.

Product feedback

MCP TypeScript SDK and Streamable HTTP: Used to expose ten household tools and connect the Node host through real HTTP MCP. Shared tool schemas and transport support let the interface and optional model host use the same domain behavior. Protocol negotiation, HTTP tool calls, authentication and restart persistence passed automated checks. Integration required explicitly separating transport lifecycle from persistent household state and guarding approval in the domain engine. We would use MCP again for tool reuse. A runnable reference showing persistent state, stale-plan rejection and trusted approval together would improve onboarding.

Codex: Used as the agentic development tool to plan, implement, test and inspect the simulator. It helped connect interface work to executable backend checks. Clear boundaries were still necessary to distinguish deployed behavior from unverified optional integrations. We would use it again with explicit acceptance criteria and recorded verification evidence.

Browser speech APIs: Included for supported browsers, with typed input as a fallback. Microphone permissions and browser support are environmental dependencies. Live microphone behavior was not verified, so no successful voice test is claimed. We would retain typed input in future versions.

Node SQLite: Used for persistent household snapshots and receipts in the standalone server. Restart persistence passed integration tests. It fits a single-household demo, but external calendar and commerce actions need service-level compensation rather than relying on local transactions. We would use it again for this scope.

Site hosting, Workers and D1: Used to deploy the working simulator with per-user state. Live verification confirmed approval and persistence after reload. Private access is useful during development, but judge access needs separate attention before submission. We would use this deployment approach again while planning sharing earlier.

Amazon services: No live Amazon Bedrock or Agent Toolkit usage is claimed. The project follows the permitted simulated Alexa+ path and supplies a runnable MCP implementation.

Built With

• cloudflare-workers
• d1
• javascript
• mcp-typescript-sdk
• model-context-protocol
• node.js
• react
• sqlite
• typescript
• vite