SoPing
Persistent reminders, a web interface and MCP tools, with explicit handling when a send result is uncertain.
Real interface in demo mode · fictional reminders and simulated delivery
Problem & context
A reminder needs to stay scheduled after an assistant or its client closes. A network failure can also leave an ambiguous result: the provider may have accepted a send without confirming it. Retrying blindly risks a duplicate.
My contribution
Built a reminder workflow with a bilingual web interface and MCP tools sharing a persistent SQLite queue. Added isolated workspaces, scheduling, attempt history and rules driven by signed events. Kept provider transports separate from the simulator used to inspect workflows without sending real messages.
Decisions & tradeoffs
Let the backend own reminders and preserve one intent across attempts.
A worker processes a persistent queue and idempotency limits duplicates. The backend must remain running; a sleeping machine defers processing until it wakes.
Distinguish failure, retryable results and uncertain outcomes.
Retries are bounded. An uncertain result stays visible without an automatic resend; provider acceptance proves neither delivery nor reading.
Outcome
A local application bringing reminder scheduling, history and controls together. The demonstration shown uses fictional data and simulated sends only; real providers and host clients remain separately qualified.