ReadyBy

ReadyBy is a voice-first household AI agent that replans around changing deadlines, verifies task feasibility, and keeps people in control through real MCP tools and approval.

Comment

Inspiration

There’s a moment in a busy morning when you stop doing your own task and start figuring out everyone else’s.

The bags are packed. Lunch is ready. You need to leave at 8:20. Then the washer needs more time, and someone has to work out what can wait, what still has to happen, and whether everyone can still get out the door.

That invisible coordination work inspired ReadyBy. We wanted a household assistant that could share the responsibility of adapting the plan when circumstances change.

ReadyBy helps a household protect a shared deadline by understanding what changed, checking the options, and asking before changing commitments.

What it does

ReadyBy is a voice-first household coordination agent, demonstrated through an independent Alexa+ web simulation with a working MCP server.

A household member can speak or type a change, such as “The washer needs more time.” ReadyBy asks for missing details, updates the reported state, and checks how the change affects the shared plan. It accounts for who is available, which tasks depend on others, and which activities require attention versus passive waiting.

Our school-run demonstration makes the trade-off visible:

  • Before the disruption: two adults, seven tasks, an 8:20 departure, and a checked 8:19 finish.
  • After the washer report: at the labelled 8:06 demo chapter, another fifteen minutes of waiting pushes the full finish to 8:28.
  • With a reviewed recovery: saving flexible laundry for later allows the remaining departure work to finish at 8:16, leaving four minutes of planned buffer.

Saying “yes” opens the proposal for review. The household approves the exact revision on screen before ReadyBy applies it. Packed bags and prepared lunch stay completed. Deferred laundry stays unfinished and available for later.

If laundry is essential, ReadyBy keeps it in the plan and explains that the original deadline cannot hold under the supplied estimates. A later departure requires agreement.

The scenario seeds fictional time and reported progress; subsequent requests exercise the real application. These times are calculated from task estimates, not measured household time savings or guarantees about physical work.

How we built it

We built the shared household display in React and TypeScript, with a Node.js backend and persistent SQLite state. The hosted demo runs on Google Cloud Compute Engine, served over HTTPS through Caddy.

Gemini Live, integrated through Google’s Gen AI SDK, supplies bidirectional audio, transcription and spoken replies. The browser receives a short-lived, single-use credential; permanent provider keys stay on the server. Typed interaction provides another way to use the same household tools.

The official MCP TypeScript SDK connects the interface to thirteen typed tools over Streamable HTTP. Those tools interpret requests, report progress and delays, inspect schedules, prepare proposals, and commit reviewed changes. An independent SDK client also exercises the server outside the browser.

Groq’s GPT-OSS 120B interprets household requests, with a configured Gemini fallback. We also implemented a local Ollama alternative and optional Vosk recorded-speech transcription for local setups.

Our central engineering decision was to give authoritative scheduling to deterministic code. A bounded search calculates candidate plans, and an independent checker validates them. The language model interprets intent; the planner calculates feasibility.

Revision checks, transactional writes and idempotent requests protect saved progress. Consequential changes require a short-lived, single-use confirmation tied to the exact proposal and revision.

Challenges we faced

Understanding a request without inventing the missing facts. In an early local-model run, “The washer needs more time” produced an unsupported twelve-minute estimate. Our validation blocked it and requested an explicit duration. That failure helped us design clarification and scoped follow-ups around information the person actually supplied.

Making recovery respect household priorities. We had to distinguish flexible work from essential work, preserve reported completion, and make an infeasible deadline a useful result. A schedule only helps if its trade-offs respect the people using it.

Keeping voice convenient while making approval precise. Conversational agreement can be ambiguous. We made “yes” open review, with the final action bound to the displayed revision. A changed or expired proposal requires fresh review.

Handling real provider and deployment limits. Quota errors, inconsistent intent extraction and live-audio billing prerequisites required explicit fallback behavior, validation and inspectable error reporting. Persistent household state also shaped our hosting choice: a VM with durable SQLite fit the current implementation.

Accomplishments we’re proud of

We completed the loop from a real spoken request through MCP tools, checked planning, visible approval and persistent household state.

Our recorded 0.4 verification reports 64 passing automated tests, successful type checking and a production build. Hosted integration evidence shows actual audio transcription reaching the household tools and producing a grounded spoken response. Browser checks exercised review and approval; restart checks preserved the saved recovery. A basic human microphone smoke test was also confirmed.

We’re especially proud of the essential-laundry case. It demonstrates that ReadyBy can explain when a deadline no longer works while keeping the household’s priorities intact.

What we learned

We learned that reliable agents need clear boundaries between interpretation, calculation and authorization. Valid JSON can still express the wrong action. A convincing spoken answer can still describe an invalid schedule. Time passing cannot establish that someone completed a physical chore.

Those lessons shaped the product: clarify missing facts, independently check plans, preserve reported progress, and ask people to approve the trade-offs that affect them.

What’s next for ReadyBy

We want to evaluate repeated use with real households, broaden the planning model beyond the current one-to-two-adult, eight-task scope, and test voice interaction across accents and noisy environments. Native Alexa integration would require the appropriate platform access and account-linking work; the current project is an independent web simulation with real AI and MCP execution.

Our aim is to give the person coordinating everyone’s morning a shared, checked next move when the morning changes.

Built With

Share this project:

Updates

Submission history