Inspiration
AI assistants are getting better at starting tasks. The harder problem is continuing safely after an interruption.
If one action already happened, another failed, and the real world changed while the user was away, a naive “Continue” can repeat completed consequences or treat a failed attempt as success.
Continuity is built around one rule:
Reconcile → Resume → Complete
What it does
Continuity for Alexa+ is a simulated Alexa+ experience that shows how an interrupted agentic workflow can resume without losing track of reality.
The judge demo uses a simple dinner-planning scenario:
- A1 — Reserve restaurant. The reservation completes and must not be duplicated later.
- A2 — Arrange ride. The ride provider fails, so Continuity records a failure—not a success.
- While the workflow is interrupted, dinner moves from 7:00 PM to 7:30 PM.
- A3 — Finalize departure plan. This must stay blocked until the ride is actually confirmed.
When the user returns and says “Alexa, continue,” Continuity does not restart the workflow. It reconciles first.
The restaurant stays booked. The failed ride still needs attention. The new 7:30 PM time is used. And the departure plan remains blocked until the ride has valid completion evidence.
Only after A2 succeeds does A3 become eligible. Only after all required conditions are supported does the objective reach COMPLETED / SUCCESS.
Why it matters
The customer experience is simple: an agent should know where it left off before it touches the world again.
That matters anywhere an AI assistant can create real consequences—reservations, payments, scheduling, travel, fulfillment, account changes, or multi-step workflows across providers.
Continuity turns “Continue” from a blind retry into a verified state transition.
How we built it
The final competition wrapper is a zero-dependency Node.js application using only standard-library modules. It includes:
- a polished Alexa+ simulated web experience;
- durable JSON state outside the conversation surface;
- deterministic action eligibility;
- explicit separation between attempted and completed work;
- failed-attempt tracking;
- condition invalidation and replacement;
- fail-closed action ordering;
- a competition metadata surface labeled for MCP protocol version
2025-11-25.
The competition wrapper uses synthetic data only, requires no production credentials, and introduces no paid runtime dependency.
Technical proof
The final competition wrapper passes 7/7 deterministic recovery tests with zero failures.
Preserved prior private integration evidence separately includes an MCP 2025-11-25 localhost execution trace demonstrating interruption, process restart, reconciliation, and final success, plus 47/47 private integration tests passed with zero failures and zero errors.
Those are deliberately presented as two different evidence layers: the 7/7 result validates the final judge-facing wrapper; the 47/47 result is supporting private build-lineage evidence.
Challenges
The hardest problem was preserving the difference between attempted work and completed work across interruption. A failed provider call must never become completion evidence, while a completed consequence must never be repeated just because the conversation or process restarted.
The second challenge was presentation: the recovery model is technical, but the customer value must be understandable immediately. The final demo therefore keeps A1/A2/A3 visible for technical traceability while giving each action a concrete human meaning.
Accomplishments
- Completed work remains preserved across interruption.
- Failed work remains failure until valid completion evidence exists.
- Changed conditions are reconciled before resumption.
- Out-of-order actions fail closed.
- Durable state survives restart.
- Final success is evidence-backed.
- The judge demo explains the customer problem and the technical proof in under three minutes.
- $0 new spend for the competition wrapper.
What we learned
A reliable “Continue” is not a retry command. It is a decision point that should reconcile what already happened, what failed, what changed, and what is safe to do next.
What's next
The competition build intentionally stays narrow and synthetic. The next step is applying the same recovery contract to real provider integrations while preserving provider independence, explicit authority boundaries, and evidence-backed consequences.
Built With
- alexa+-simulated-experience
- css
- html
- javascript
- mcp-2025-11-25
- node.js
Log in or sign up for Devpost to join the conversation.