-
-
StillDone's public exhibit: a simulated Alexa+ experience with deterministic fixture playback and transparent evidence provenance.
-
Pre-state evidence shows a 7:45 departure, an absent preparation task, and rainy weather before the mission's actions.
-
The model proposes; deterministic code controls execution. A digital Google Tasks entry is verified through separate read-back.
-
Calendar mutation pauses at a human approval boundary. The exhibit records zero calendar writes before authorization.
-
Three verified predicates produce a historical READY receipt. Its SHA-256 hash stays intact even after later drift.
-
The deterministic exhibit illustrates departure changing from verified 7:30 to 8:00, invalidating current readiness.
-
Fresh fixture reconciliation marks current truth DRIFTED while preserving the historical READY receipt and simulated Alexa+ response.
-
The provenance card separates historical recorded-live AWS and Google integration evidence from offline fixture playback.
Inspiration
AI assistants often declare a task complete as soon as an API returns success. But an HTTP 200 response does not prove that the intended real-world outcome happened — or that it remains true tomorrow.
Imagine a family asking: "Get us ready for tomorrow morning. We need to leave by 7:30." An assistant might successfully update a calendar and create a task, but what happens when somebody changes the departure to 8:00 later that evening?
We built StillDone around a simple principle: Done, and still true.
What it does
StillDone is a desired-state mission runtime that treats completion as something to prove, not something an AI model can simply declare.
It transforms natural-language intent into explicit, testable desired-state predicates, then:
- Observes existing state across services.
- Uses an AI model to propose a structured plan without granting the model execution authority.
- Executes permitted actions while requiring human approval for sensitive changes.
- Independently reads external state back after execution.
- Declares READY only when the required predicates are verified.
- Issues an immutable SHA-256 mission receipt.
- Reconciles the mission when reality changes, revoking readiness and reporting DRIFTED when necessary.
Our demonstration follows a departure changing from 07:45 → 07:30 (READY) → 08:00 (DRIFTED).
The defining moment is not when the assistant performs an action. It is when StillDone recognizes that its earlier completion claim is no longer true.
How we built it
StillDone combines a real AWS-powered planning architecture with a deterministic verification runtime.
Amazon Bedrock Nova Micro provides natural-language planning through the Converse API, orchestrated with the Strands Agents SDK. The model proposes actions but has no authority to approve, execute, verify, or declare a mission complete.
A real Model Context Protocol (MCP) server, built with the official Python SDK, exposes typed mission tools over Streamable HTTP. We successfully tested real remote MCP execution on Amazon Bedrock AgentCore Runtime, including protocol negotiation and remote tool calls.
Our provider integrations include Google Calendar, Google Tasks, and Open-Meteo. Real AWS and external-service integrations were executed and preserved as dated evidence, including independent read-back verification of calendar and task mutations.
The deterministic Python core manages authorization, single-use approvals, execution, idempotency, predicates, freshness, durable evidence, immutable receipts, and reconciliation.
We also implemented two isolated Python dependency environments to resolve a real incompatibility between the Strands Agents SDK and newer MCP SDK requirements, without weakening dependency constraints.
The public exhibit is hosted on Cloudflare Pages, with the open-source implementation, automated tests, and reproduction instructions available on GitHub.
Demonstration transparency: The public exhibit and video show a deterministic offline fixture replay with a clearly labeled SIMULATED ALEXA+ EXPERIENCE. They do not execute live AWS or Google calls for visitors. Authentic historical Bedrock, AgentCore, Calendar, Tasks, and Open-Meteo integrations are documented separately as RECORDED_LIVE evidence. The complete seven-step mission is demonstrated through fixture playback, not claimed as one current-live end-to-end run.
Challenges we ran into
Separating AI confidence from factual authority. We designed independent verification so that a successful tool response or persuasive model explanation cannot create READY status without observed evidence.
Handling ambiguous failures. Network timeouts after successful writes can produce duplicates. We implemented idempotency controls, read-before-retry behavior, and durable recovery evidence.
Balancing safety with usability. Sensitive calendar changes require a cryptographically bound, single-use human approval, while appropriately classified reversible actions can proceed automatically.
Resolving incompatible SDK dependencies. Strands Agents and our MCP server required incompatible MCP dependency ranges. We isolated their runtime environments instead of overriding upstream requirements.
Building under a zero-personal-spend constraint. We tested real Bedrock and AgentCore integrations, preserved the evidence, and deliberately removed metered cloud infrastructure after verification.
Accomplishments that we're proud of
- Built a desired-state runtime where verified completion can be revoked when reality changes.
- Demonstrated READY → DRIFTED reconciliation while preserving the original immutable receipt.
- Implemented real Bedrock, AgentCore MCP, Google Calendar, Google Tasks, and Open-Meteo integrations, with historical execution evidence.
- Created an accessible, publicly hosted, self-contained demonstration that judges can explore without credentials.
- Passed more than 3,700 automated tests across two isolated Python runtime environments.
- Built mcp-verify, a reusable verification middleware package within the repository, demonstrating independent read-back and predicate verification for MCP tools.
What we learned
The most important lesson was that tool execution and outcome verification are fundamentally different responsibilities.
AI-generated explanations cannot replace independently observed facts. We also learned that verification must continue beyond the initial execution: an accurate historical receipt should remain intact even when the current mission state becomes invalid.
Working with AWS, Strands, MCP, and external APIs reinforced the importance of explicit authority boundaries, reproducible evidence, and honest reporting of failures and limitations.
What's next for StillDone
We want to extend StillDone beyond calendars and tasks into additional real-world domains, including smart-home states, location-based missions, and more complex multi-service workflows.
Future work includes direct Alexa+ client integration when partner access becomes available, scheduled reconciliation, richer freshness policies, and additional independently verifiable provider adapters.
Our long-term vision is an agent ecosystem where "done" is not a promise from a model, but a continuously verifiable state backed by evidence.
StillDone — Done, and still true.
Public demo: https://stilldone-judge-exhibit.pages.dev
Source code: https://github.com/zyganali-glitch/StillDone
Reproducibility and evidence: https://github.com/zyganali-glitch/StillDone/blob/main/docs/REPRODUCTION.md
Built With
- amazon-bedrock
- amazon-bedrock-agentcore
- amazon-web-services
- cloudflare-pages
- github-actions
- google-calendar-api
- google-tasks-api
- http
- mcp
- model-context-protocol
- open-meteo
- pytest
- python
- strands-agents
- streamable

Log in or sign up for Devpost to join the conversation.