THREAD: Don't lose the thread

The commitment layer for Alexa+. When a plan changes, THREAD finds every commitment it breaks, hands each one to the right person (or agent) with only the context they need, and stays until it’s done.

Comment

Inspiration

Life runs on shared commitments: a ride, a refill, a shift, a visit, a delivery. They span people, devices, services and, increasingly, AI agents. When one thing changes, someone has to work out what breaks, who can take over, what that person needs to know, and whether it actually happened. Today that "someone" is a person carrying it all in their head.

Assistants are great at single tasks. Nothing looks after the commitment until it is really kept. We wanted Alexa+ to do that follow-through.

What it does

THREAD is the commitment layer for Alexa+. Ask it the signature question, "What does this change affect?", and it:

  • Finds the ripple. It shows which commitments are now at risk and how badly, and also which are fine, so a change doesn't become a household-wide alarm.
  • Proposes who should take over, with reasons. It can propose a person, or a service (for example pharmacy delivery) when no one is free.
  • Hands off with the least context. The new owner gets only what they need; everything else is withheld and labelled, never leaked. A Context Receipt shows both lists.
  • Never confuses "accepted" with "done". Status goes Accepted → Plan secured → Resolved, and only evidence marks something resolved. Anything that spends money waits for an explicit "yes".
  • Keeps watching. New signals (rain moves the departure) update the plan and notify the right person.

The demo is a family weekend. Maya can't drive Saturday, so Leo's tournament and Rosa's refill are at risk and dinner is fine. Sam takes the ride on his own phone, a pharmacy delivery covers the refill once Maya approves, and the tournament resolves only when Sam arrives.

But the engine is domain-agnostic. A commitment is just an objective, its responsibilities, and what counts as done. The same engine serves caregivers sharing medication and visits, small teams covering shifts, Alexa+ brands offered at the exact moment a plan breaks, and AI agents handing work to each other without oversharing. The open-source engine already ships examples for a household, a caregiver rota and an agent-to-agent handoff.

How we built it

  • A real, self-hosted MCP server. It is built on the official @modelcontextprotocol/sdk: MCP spec 2025-11-25 over stateless Streamable HTTP, served by Hono.
    • 8 single-intent tools: create_thread, list_threads, get_thread, report_change, request_handoff, respond_to_handoff, record_evidence, confirm_action. Each is a 1:1 adapter whose schemas come straight from the engine.
    • No LLM on the server, so tools are deterministic: report_change p95 is about 23 ms locally, well under the 500 ms budget.
  • Alexa+ auth. An embedded OAuth 2.1 server (ES256, PKCE S256, resource indicators).
    • Tier 1 service tokens can only list tools. Tier 2 tokens act as a person.
    • Identity always comes from the token, never from what's said, so Maya can't accept Sam's handoff.
    • 21 conformance tests cover the Alexa+ auth checklist.
  • Thread Lens: an MCP App (ui://thread/lens) with 10 glanceable views for the Echo Show, plus an Agent Skill that says when to call each tool.
  • A simulated Alexa+ experience built from real MCP clients: an Echo Show for Maya and a phone for Sam, each signed in with its own OAuth token. An "Under the hood" drawer shows the live JSON-RPC traffic.
  • An open-source engine, thread-core (Apache-2.0, v0.1.0): impact graph, ranking, least-context policy, evidence-based resolution and an event log. It is pure, deterministic and property-tested. The Alexa+ server installs it from the public release.
  • AWS-ready.
    • A CDK stack with Lambda + Function URL (the same MCP server), DynamoDB, SSM and a budget alarm.
    • An optional Amazon Bedrock live agent that uses the same 8 tools, with the Agent Skill as its instructions.
    • npm run synth passes offline. Not deployed: no AWS account was available before the deadline.
  • Built spec-first with Kiro and Kiro Crew.
    • Every component started as a Kiro spec (requirements → design → tasks), with steering files and guard hooks: one protects contract files, another refuses to stop while tests are red.
    • Kiro Crew ran the build phases unattended overnight, committing and opening pull requests while keeping every gate green.
  • Proven, not claimed.
    • npm run verify (contract checksums, dependency allowlist, secret scan, typecheck, 68 tests) runs in CI on Ubuntu and Windows.
    • A Playwright test plays the whole story in a browser.
    • Official MCP Inspector transcripts are committed in the repo.
    • npm install && npm run demo works on a fresh clone with no credentials.

Challenges we ran into

  • Errors vs output schemas. The MCP SDK client validates structuredContent against outputSchema even when isError is true. Our errors return isError plus text, with no structuredContent.
  • No Alexa+ device to test on. We built a simulator that is itself an MCP client, and proved the server independently with the MCP Inspector.
  • Autonomous builds need guardrails. Parallel Kiro Crew phases shared one worktree and broke each other's checks. Scoped commits and hard gates kept main green.
  • Bugs only a real recording exposed. Recording the demo found three UI bugs that the API-level tests missed: the sign-in redirect, an inbox field, and a missing Context Receipt. All are fixed.
  • No AWS account in time. The stack is honestly synthesized, not deployed.

Accomplishments that we're proud of

  • A new primitive for assistants, the commitment, with privacy by construction (least context) and honest completion (evidence, not a button).
  • A spec-current MCP server with OAuth, an MCP App and an Agent Skill, verified by the official Inspector.
  • A clean split: a reusable open-source engine plus a thin Alexa+ adapter.

What we learned

  • Stateless Streamable HTTP makes an MCP server portable: the same app runs locally and on Lambda.
  • Treating schemas as the contract (one zod object for validation and both MCP schemas) removes a whole class of drift.
  • Voice needs calm: saying what's not affected matters as much as raising what is.
  • Spec-first agentic development works when the gates are mechanical: checksums, allowlists, and hooks that refuse to stop on red.

What's next

  • Deploy the stack and submit THREAD as an Alexa+ add-on with live calendars.
  • Partner services (pharmacy, grocery, rides) as first-class options behind the same confirm-before-spend and evidence rules.
  • More templates on thread-core: caregiving, school logistics, team shifts, agent workflows.

Built With

Share this project:

Updates

Submission history