The problem
Most assistants optimize for a successful action or API call. In the real world, that can create false closure: a service provider can mark a repair complete while the user's actual problem still exists.
Alexa+ Home-Repair Outcome Loop explores a different contract for agents: responsibility stays open until the real-world outcome is verified.
What it does
The demo starts with a simple request:
“Alexa, my AC is broken. Handle it and make sure it is actually fixed.”
The system then:
- creates a repair case,
- books a service provider,
- checks provider status,
- reads observable home-state evidence,
- refuses to close when the provider says “complete” but the room is still too warm,
- reopens/escalates the case,
- closes only after provider status and home-state evidence agree.
The core principle is:
Provider complete ≠ home recovered.
In the deterministic judge scenario, provider completion is followed by a failed outcome check at 29.2°C against an acceptable threshold of ≤25.0°C. The case remains open. After recovery reaches 24.4°C, verification passes and the final state becomes Verified resolved.
Alexa+ / MCP implementation
The project exposes six bounded domain operations through a self-hosted MCP server using Streamable HTTP:
- create_repair_case
- book_home_service
- get_service_status
- read_home_state
- verify_outcome
- reopen_or_escalate_case
The MCP surface is independently exercised through a real HTTP-level round trip and targets protocol revision 2025-11-25.
For judgeability without private credentials, the repository also ships a deterministic simulated Alexa+ web experience. Provider and thermostat values are explicitly synthetic; the verification and recovery logic is the repository's real application logic.
Architecture
The MCP transport and the agent runtime adapters share one deterministic domain implementation. This prevents transport or agent layers from silently changing the outcome rules and makes the behavior easy to test.
The repository also contains a Strands + Amazon Bedrock + AgentCore runtime path with traced tool adapters and deployment configuration. Live AWS deployment is a separate evidence gate and is not claimed until a remote invocation is actually verified.
Why this matters beyond home repair
The same outcome-verification pattern applies to many agentic workflows:
- delivery marked complete vs. package actually received,
- refund issued vs. money actually returned,
- appointment booked vs. service actually delivered,
- maintenance ticket closed vs. fault actually resolved.
The broader idea is simple: agents should optimize for verified outcomes, not successful tool calls.
Product experience
The public judge simulator visually separates:
- the user's desired outcome,
- provider-reported completion,
- independent home-state evidence,
- failed verification,
- recovery action,
- verified closure.
Safety and truth boundary
The prototype does not diagnose medical conditions, control safety-critical equipment, or claim that the simulated provider/thermostat systems are real integrations. Synthetic state is clearly separated from real application logic.
Current build status
- deterministic outcome/recovery loop: working
- Streamable HTTP MCP server: working and tested
- public Alexa+ judge simulator: deployed and manually runtime-verified on Android
- CI/lint/tests: passing
- MIT open-source repository: public
- Strands/AgentCore/Bedrock path: code-ready and CI-tested
- live AWS runtime proof: separate pending gate; no live-success claim until verified
This is a new project built during the hackathon window.
Log in or sign up for Devpost to join the conversation.