WorkRelay

When the plan changes, see what follows—and pick up where you left off.

Comment

Inspiration

A client asks to bring a launch forward. Updating the date is easy. Finding the affected documents, deadlines, original agreements, and unresolved decisions takes more work—especially after an interruption.

WorkRelay explores a conversational workflow for that moment: ask about a change, inspect its consequences on screen, authorize a specific action, and return later to what remains. This is our Alexa+ interaction hypothesis. We built a working local simulation to make the idea testable; voice usefulness and customer demand still require real user research.

What it does

WorkRelay is a local, single-project work agent with a guided Alexa+ workflow simulation. The simulation uses typed requests and on-screen controls, bounded local rules, and real saved project state. Alexa+ and a language model are not connected to this guided experience.

The core workflow is Compare → Review → Repair → Resume:

  • Compare the current agreement with sourced feedback without changing saved work.
  • Inspect affected tasks and documents, before/after values, and original evidence. Follow a document explanation back to the selected option.
  • Review and explicitly confirm the decision.
  • Select exact document-line repairs and task dates, preview the combined changes, and confirm one validated repair plan.
  • Reload and resume from saved facts, with unresolved feedback and unfinished tasks still visible.

In the fictional demo, moving launch from October 9 to October 7 reveals three document date mismatches and one task scheduled after launch. After the decision and repairs are confirmed, one feedback item and five unfinished tasks remain. Repairing the plan does not complete delivery.

Users can also start with a blank workspace, import supported meeting text, and explicitly link tasks and documents to confirmed requirements. Unknown owners and dates remain unknown. The interface supports English and Chinese while preserving original source text.

How we built it

React and TypeScript power the interface; Node.js, Express, and Zod support a shared domain engine and persisted project. Every proposed mutation is validated, previewed, and explicitly confirmed in the UI. Confirmation checks the current revision again and reports success only after persistence. Stale actions are rejected; undo advances the revision.

The MCP TypeScript SDK exposes nine real tools: workrelay_read_state, workrelay_audit, workrelay_resume, workrelay_readiness, workrelay_compare_options, workrelay_preview_impact, workrelay_repair_candidates, workrelay_preview_repair, and workrelay_propose.

The guided conversation route invokes read and preview tools through the SDK's in-memory transport. Separately, stdio and a loopback Streamable HTTP endpoint expose the same tool set; the HTTP path has been tested with protocol version 2025-11-25. These are local MCP capabilities, not a live Alexa connection. MCP can save a validated proposal for review; no MCP tool can approve or apply it.

The default application needs no account, credentials, or model download. An optional local model adapter is separate from the guided simulation and disabled by default; real model inference has not been validated.

Challenges we ran into

The hardest problems appeared between successful actions. Closing and reopening review could duplicate a pending draft, so equivalent actions at the same revision now reuse the existing proposal. Undo could leave an old success receipt visible, so receipts now follow saved activity and invalidate when the project changes.

Freshly imported tasks also lacked editable requirement relationships. We added explicit, validated task and document links, preserving original evidence and keeping unconfirmed requirements separate from the current agreement. These were application defects found during our own tests and walkthroughs, not Amazon service failures.

Accomplishments that we're proud of

The working build carries a choice through its evidence, explicit approval, exact repairs, and recovery in one persisted workspace. It also supports newly imported work, source-preserving handoff exports, and bilingual review. Pending handoffs remain local records and do not transfer responsibility automatically.

All 154 automated tests pass. A fresh source-package extraction on macOS with Node.js 22 passed dependency installation, the same 154 tests, production build, and local MCP smoke checks. The 155.9-second English-captioned demo contains one continuous recording of actual UI actions, with no accelerated or rearranged interaction.

What we learned

A useful conversation needs continuity: which option is selected, which evidence supports it, what has actually been saved, and what remains unfinished. Those distinctions must survive closing a review, refreshing the page, and undoing an action.

Automated checks and browser walkthroughs found different problems, so both became part of verification. The resulting evidence demonstrates the exercised workflow; it does not establish user demand, time saved, or real Alexa compatibility.

What's next for WorkRelay

Run unguided sessions with three to five people who coordinate real projects, using sanitized material. Observe whether they can distinguish previews from saved actions, choose repairs, and resume after an interruption; record errors, assistance, and completion times.

Then validate an available Alexa integration path while preserving the same evidence and approval boundaries. WorkRelay currently remains local and single-project. Its checks understand explicit labels and known relationships, not arbitrary prose, delivery quality, or general natural-language requests. The next changes should follow observed failures and integration results.

Built With

Share this project:

Updates

Submission history