• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

RelayCase — Because Asking Isn't the Same as Done.

The biggest problem with everyday coordination isn't that we forget to ask. It's that we often don't know what happens after we ask.

Inspiration — The Missing Step Between Asking and Doing

Imagine a simple situation.

A package arrives at your doorstep. You're away from home, so you ask a family member to bring it inside.

You send a message.

"Can you bring the package in?"

The message is delivered. Maybe a reminder is even created.

But three questions remain unanswered:

Did they see the request? Did they agree to do it? Did they actually finish?

Most digital assistants are excellent at creating reminders, sending notifications, and managing task lists. Yet sending a message is not the same as transferring responsibility.

We began with a question:

What if an AI assistant didn't just help people assign tasks, but helped them establish clear, accountable handoffs—without taking away human control?

That question became RelayCase.

What It Does — Turning Requests Into Accountable Actions

RelayCase is a consent-based responsibility management application built around a simulated Alexa+ experience and the Model Context Protocol (MCP).

Instead of treating a task as a single checkbox, RelayCase models the actual journey from request to acknowledgement.

Here's how it works.

1. A request begins with a conversation.

Priya wants Sam to bring a package inside. She enters a simple command into the RelayCase assistant. The assistant uses an MCP tool to create a persistent, structured case.

2. Human approval comes before delegation.

Before an invitation is sent, Priya must review and explicitly approve the request through the application.

The assistant cannot grant that approval on her behalf.

Even if it attempts to send the invitation prematurely, the backend rejects the operation.

3. Responsibility must be accepted, not assumed.

Sam receives the invitation and can accept or decline it.

Only after Sam accepts does RelayCase record that responsibility has been taken.

4. Completion is reported honestly.

After performing the task, Sam reports it as completed.

RelayCase deliberately distinguishes a human completion claim from independently verified physical-world proof.

A report is evidence of what someone said—not proof that a physical event occurred.

5. The requester closes the loop.

Priya reviews Sam's report and acknowledges it.

The case history preserves the sequence of actions, the responsible actors, and the recorded state transitions.

The result is a structured workflow:

Draft → Preview → Approved → Invited → Accepted → Reported Done → Acknowledged

RelayCase also supports declined invitations, disputes, authorization failures, and other states where real-world coordination doesn't go perfectly.

How We Built It — An AI Interface With Real Boundaries

The most important engineering decision was to separate the assistant's ability to request an action from the server's authority to permit it.

Our architecture consists of four primary layers.

1. Simulated Alexa+ Experience

We built a conversational web interface that demonstrates how an assistant can interact with structured household workflows.

The current assistant uses deterministic commands rather than pretending to be an unrestricted language model or a live Alexa+ connection.

2. Model Context Protocol Integration

RelayCase exposes seven MCP tools through a Streamable HTTP interface.

These tools allow the assistant to discover participants, inspect cases, create drafts, preview requests, and interact with authorized handoff operations.

We also integrated the maintained MCP TypeScript SDK and tested interoperability using an independent SDK client.

This demonstrates a practical approach to connecting assistant experiences with controlled application functionality.

3. Server-Enforced Authorization

The backend is implemented with Node.js, with a shared domain service enforcing permissions and valid state transitions.

Important protections include:

• Explicit first-party human approval before invitation delivery.
• Separate requester and assignee permissions.
• Server-derived actor identity.
• Idempotent operations to protect against duplicate requests.
• Approval invalidation when relevant draft content changes.
• Rejection of unauthorized actions and invalid state transitions.

The assistant cannot bypass these protections by changing its command.

4. Persistent State and Audit History

We use SQLite to persist cases, participants, approval records, handoff attempts, and event history.

This enables the application to retain responsibility records across sessions and server restarts.

The event timeline helps users understand not only the current status, but also the decisions that led to it.

Design — Making Accountability Visible

We didn't want RelayCase to look like another generic chatbot.

We designed it as a tactile architectural accountability workbench, using warm parchment backgrounds, terracotta accents, editorial typography, and carefully restrained motion.

The interface includes a seven-stage responsibility tracker, structured case details, visual approval indicators, and a readable activity timeline.

An assistant workbench exposes MCP activity instead of hiding every technical interaction behind a conversational response.

A major design principle guided our decisions:

The interface should never visually communicate more certainty than the underlying evidence supports.

That means an accepted request looks different from a reported completion, and a reported completion looks different from an acknowledgement.

Accessibility, responsive layouts, keyboard interactions, and reduced-motion support were considered throughout the redesign.

Challenges We Ran Into

Challenge 1 — Giving an AI assistant useful capabilities without unrestricted authority

Connecting an assistant to tools is relatively straightforward. Ensuring it cannot exceed its authority is much harder.

We solved this by centralizing business rules in the server-side domain layer and requiring human approval through an independent authenticated action.

Challenge 2 — MCP interoperability across development environments

Our initial development environment experienced npm connectivity problems, preventing independent SDK verification.

We preserved the working local prototype, introduced an official SDK adapter, and subsequently validated the MCP handshake, tool discovery, and invocation flow on Windows.

Challenge 3 — Reliable event ordering and state consistency

During repeated testing, we discovered that events recorded within the same millisecond could appear in an incorrect order.

We corrected the history-ordering logic and added a deterministic regression test.

This reinforced why event history must be reliable when users depend on it to understand responsibility.

Challenge 4 — Designing honest completion states

A common task-management interface treats checking a box as definitive completion.

For RelayCase, this would have undermined the product's purpose.

We designed separate states for acceptance, completion reporting, and requester acknowledgement, preserving the distinction between a person's statement and independently verified reality.

Accomplishments We're Proud Of

Our biggest achievement is building a complete, locally working interaction between the assistant, MCP interface, authorization service, database, and human participants.

The application has undergone automated and browser-level validation, including:

• 35 passing core and security tests
• 19 passing independent judge-workflow checks
• 9 passing maintained MCP SDK integration checks
• 16 passing Chrome browser end-to-end checks

These checks cover important scenarios such as unauthorized operations, approval enforcement, persisted state, and the complete two-person handoff.

We are particularly proud that a rejected action is part of the demonstration—not something hidden from the judges.

RelayCase demonstrates that saying "no" can be just as important as successfully executing an AI tool.

What We Learned

Building RelayCase changed how we think about intelligent assistants.

We learned that useful automation is not simply about how many actions an AI can perform.

It is about whether those actions are authorized, understandable, recoverable, and connected to real human decisions.

We also learned that technical correctness and product clarity must evolve together.

A state machine can be correct internally, but if users cannot understand what a status means, the system has failed to communicate its value.

Most importantly:

Trustworthy automation should make responsibility clearer—not make human accountability disappear behind an AI-generated response.

What's Next — Beyond Household Handoffs

RelayCase currently demonstrates its workflows through a simulated Alexa+ experience and synthetic household participants.

Our future direction is to investigate real assistant integrations, opt-in notifications, richer accessibility support, and additional coordination scenarios.

Potential applications include shared households, family caregiving coordination, team operations, and other situations where responsibilities move between people.

Future integrations would require additional privacy controls, user validation, and platform-specific testing.

Our larger vision is to make AI-assisted coordination more transparent by design.

Not an assistant that simply tells you something has been handled.

An assistant that helps everyone understand what was requested, what was accepted, what was reported, and what remains uncertain.

---

RelayCase

Because asking isn't the same as done.

Built for the Amazon Developer Hackathon 2026 — Alexa+ Track.

Built With

• alexa+
• css3
• html5
• javascript
• json-rpc
• mcp-typescript-sdk
• model-context-protocol-(mcp)
• node.js
• rest-api
• sqlite
• streamable-http
• web-audio-api