Alexa+ DoneWise

DoneWise is an MCP server that helps AI assistants get permission, retry safely, and verify calendar actions and test payments before saying “done.”

Comment

Inspiration

A voice assistant says a payment failed, so you try again. Later, you discover that both payments went through. Or it says your appointment moved, but the calendar still shows the old time. An assistant that can take action needs a reliable way to tell you what actually happened.

I built DoneWise for the Alexa+ track so assistants can back their confirmations with evidence. It checks consent, tracks each operation and reads the provider's state before issuing a verified receipt. Another agent can later retrieve that receipt without needing the original conversation.

DoneWise is designed for people who use assistants such as Alexa to manage appointments and deposits, and for developers connecting those assistants to external services. The goal is to make uncertainty visible so users can avoid unnecessary retries and know when a change still needs attention.

What it does

In the recorded demo, I schedule a plumber, approve a $60 test deposit and change the appointment. The simulator uses a real Google Calendar and Stripe in test mode. Two deliberate failures show how DoneWise responds to uncertainty:

  • The payment succeeds, but the response is lost. DoneWise preserves the operation identity and checks the payment's state to recover the result. The evidence panel shows the PaymentIntent ID and one applied charge.
  • The calendar acknowledges a change without applying it. DoneWise checks the calendar, makes a bounded retry and leaves the move unconfirmed. When I explicitly ask to try again, it continues the same operation and verifies the new time.

Payment approval applies only to the specified amount and payee. Application code controls consent and uses receipt text for action confirmations on screen and aloud. Each receipt records the status, supporting evidence, observation time and next step. Pending work can be checked without starting another action.

A different agent then retrieves the saved receipts through a classic Alexa Skill in the Developer Console simulator. Lambda invokes a Strands agent on AgentCore with no history of the original conversation. It reports the stored observations and their times, without making new calendar or payment reads or writes.

The plumbing providers in the demo and test scenarios are fictional. A calendar entry does not mean a real plumber accepted a booking. No real money moves. The web UI simulates an Alexa+ experience; the classic skill is not an official Alexa+ integration.

How I built it

DoneWise exposes a Python verification harness through six Model Context Protocol tools for calendar creation and rescheduling, payment requests, approval, operation status and receipt recap. SQLite persists operation identities, approvals, attempts and receipts. Typed contracts and provider adapters keep verification separate from the model.

The recorded demo uses Claude Haiku 5.5 through the Anthropic API in a local FastAPI simulator. The interface shows the conversation, its supporting receipts and labelled fault controls, with browser speech input and output. A Docker quickstart runs the scripted flow with local Fake adapters and no model credentials.

The AWS components have three roles:

  • Amazon Lightsail serves the authenticated MCP endpoint over HTTPS through Caddy, with SQLite on persistent disk.
  • A Strands agent using Nova Pro runs on AgentCore and retrieves saved receipts. Alexa Skills Kit and Lambda connect the classic development skill to this agent. AgentCore Observability and CloudWatch record its model invocation and tool calls.
  • Amazon Bedrock provides Nova Pro, Claude Sonnet 4.6 and gpt-oss-120b for the separate model comparison described below.

The MIT licensed donewise-harness package can be installed from source without MCP, FastAPI or model SDKs. It has not been released on PyPI. Claude Code and Codex helped with development, review and testing.

Challenges and lessons

A timeout does not tell you whether an action failed or its response disappeared. Stable identity prevents a retry from becoming a new operation; independent reads establish what happened. Retries are bounded by provider safety conditions, and unresolved outcomes can remain unknown.

A remote Strands run tried to execute a calendar write after a recap in the same model response. I added a guard to stop subsequent tools and restricted the separate recap agent to reading saved receipts. The corrected remote story completed all five turns.

The interface also needed to handle expired approvals and session changes. Replaced sessions remain readable but cannot accept new actions. Recaps are labelled as stored evidence, and only verified results receive a checkmark. I documented SDK, timezone, deployment and permission issues in the friction log and Product Feedback.

Results and evidence

Recorded connected tests completed all five backend and MCP turns with Sonnet 4.6 through Anthropic, Nova Pro through Bedrock, and Strands against Lightsail. Independent Stripe lookups in the recorded Nova and remote Strands tests confirmed one successful $60 test payment per run after a lost response. False calendar acknowledgements remained unconfirmed until an explicit retry succeeded. The connected simulator evidence and remote test evidence are published.

Three models on Bedrock. This evaluation used real model calls with controlled Fake adapters, ten scenarios and one execution per scenario and variant. It was separate from the connected Google Calendar and Stripe tests. The baseline already had stable operation identity, idempotency keys and optional calendar and payment reads.

False success claims, counted against all success claims, were:

  • Nova Pro: baseline 5/14; DoneWise 0/11.
  • Claude Sonnet 4.6: baseline 5/19; DoneWise 0/14.
  • gpt-oss-120b: baseline 4/15; DoneWise 0/11.

All three models produced the same results on these additional metrics:

  • Extra charges / authorized payment intents: baseline 0/4; DoneWise 0/4.
  • Completed mutations / mutation scenarios: baseline 4/7; DoneWise 6/7.
  • Completed protections / protection scenarios: baseline 2/3; DoneWise 3/3.

Neither variant produced duplicate charges in these model runs. Mutation completion means the requested change happened. Protection completion means preserving concurrent state or refusing an unsafe action. Zero false confirmations does not mean every requested mutation was completed.

Codex performed a semantic review of the claims against independent recorded state snapshots. No human review was performed. These results measure the whole application, including receipt presentation, and do not establish that model prose always follows instructions. The protocol, model run IDs, results and review annotations are available in the repository.

Deterministic comparison without a model. A separate published run used Fake adapters and three variants: the original baseline, a baseline with stable idempotency keys and one automatic retry after a lost response, and DoneWise. Neither deterministic baseline reads the result back.

In that order, the results were:

  • False success claims / all success claims: 4/10; 4/13; 0/11.
  • Extra charges / authorized payment intents: 2/4; 1/4; 0/4.
  • Completed mutations / mutation scenarios: 2/7; 3/7; 6/7.
  • Completed protections / protection scenarios: 1/3; 1/3; 3/3.

The idempotent baseline avoided duplicate charges in S01 and S07. Its remaining duplicate occurred in S10, where the test deliberately expired the idempotency window before a retry. Those charges were Fake records, not Stripe transactions. Full results for run run_671d3192be484121aafb6368d4928291 and the earlier two variant comparison are available.

Both evaluations compare the whole harness. Some protection scenarios test controls absent from the baseline, rather than identical provider failures. These finite samples are not production reliability guarantees. Zero in a finite sample does not mean never.

Paired Alexa tests returned the exact receipt speech, with skill execution taking 1.124 to 1.853 seconds in three recorded samples. The Alexa integration evidence includes the separate AgentCore timings and their measurement conditions. A Claude Code sandbox session provides additional evidence from an external MCP client.

What's next

DoneWise is currently a demo for one user. The next steps I would explore are account linking, isolation between users, recovery of simulator sessions after a restart and testing on Echo devices. Production payments and official Alexa+ integration or certification remain outside the demonstrated scope.

Built With

Share this project:

Updates

Submission history