CommitmentOS

• 

  CommitmentOS — finds the promises in your email, books the work time, and repairs the plan when things change.

• 

  The problem: the promise exists in your inbox, but the time to do the work was never reserved anywhere.

• 

  Control loop: Observe → Interpret → Plan → Policy → Execute & Verify — and back around. It doesn't plan once; it keeps the promise feasible.

• 

  A meeting lands on reserved time — CommitmentOS moves the affected block and preserves the rest automatically.

• 

  Today view: scheduled work blocks and pending approvals — nothing lands on the calendar without your confirmation.

• 

  Every detected commitment is anchored to the exact words in the email that support it — no evidence, no commitment.

• 

  Architecture on Google Cloud: Gemini interprets language; deterministic code plans, guards, and executes.

• 

  One audit entry, expanded: idempotency key, If-Match etag, observed etag — the execution receipt for a single calendar patch.

Inspiration

I make promises over email all the time—"Sure, I’ll send you the report this Friday"—but my calendar doesn’t automatically put that into my plan, and I keep forgetting about my tasks. A commitment isn't just something to extract into a task list; it also has to adapt to schedule changes, and there should be a way to verify whether the change actually happened. But I also don’t want an AI to change my Google Calendar freely. This led to the question behind CommitmentOS: how do I make an agent trustworthy enough to act without asking my permission for every single action?

What it does

CommitmentOS finds the commitments you make in Gmail, schedules time to complete them on Calendar, repairs the plan when it detects a scheduling conflict, and helps verify whether the work actually got done. Gemini 3.5 Flash reads your Gmail and identifies who promised what, to whom, and by when, including changes in deadlines. Every commitment must point to the exact words that support it, or it will be rejected. You confirm the required working time, and a deterministic planner turns the task into work blocks without creating scheduling conflicts. You must approve the first plan; after that, CommitmentOS can automatically adjust the schedule if a new task introduces conflicts. On the deployed service, schedule repairs typically complete in 7.2–10.2 seconds, with every change showing what moved and why. If you manually edit your Calendar, moved task blocks stay moved, and deleted blocks aren't recreated. CommitmentOS scheduling time doesn’t mean the work happened—you check in the minutes you actually worked on a task, and only you can mark a commitment complete. Every decision and schedule change appears in an audit timeline. Anyone can try the real interpretation, planning, and repair stack without signing in to your Google Account through the isolated sandbox at https://commitmentos-2hscowvydq-uw.a.run.app/sandbox or the read-only demo at https://commitmentos-2hscowvydq-uw.a.run.app/demo. Neither can access or change a visitor’s Gmail or Calendar.

How I built it

I don’t trust an LLM to change my calendar freely, so I never let one control it. Gemini 3.5 Flash reads through emails, extracts commitments, and must provide exact textual evidence for every claim. Then my code checks that each extracted commitment is valid, confirms who made the promise, decides how the work should be done, and makes every change to Calendar or other external systems. Gmail or Calendar changes trigger idempotent tasks that run through a durable Firestore-backed reconciliation loop. Each Calendar block keeps a stable identity, so CommitmentOS moves only what needs to change. Before writing any update to Calendar, the system verifies it still has the latest data; if anything changed in the meantime, it rejects the update and recalculates instead of overwriting newer information. Push notifications let CommitmentOS react quickly when Gmail or Calendar changes, while a once-a-minute reconciliation check catches anything those notifications might miss. The system records every event it sees, every decision it makes, and every action it takes on a single audit timeline. The rule throughout the system is: The model interprets; deterministic code acts.

Challenges I ran into

I set a difficult reliability gate: the complete flow—email → detection → acceptance → approval → Calendar plan → conflict → autonomous repair → check-in → completion—had to succeed 10 times in a row on the deployed service. One failure reset the count. For almost two days, I couldn’t finish a streak. In one run, a conflict repair never happened and produced no error. Testing Google’s watch notifications revealed that deliveries could stop after bursts of Calendar changes. I changed the architecture so push became an optimization rather than a dependency: once-a-minute reconciliation now turns a missed notification into a short delay instead of stale state. Another failure exposed a subtler Calendar behavior: Google can retain event IDs after cancellation, so recreating an event under the same ID could attach to the canceled event. The executor now detects and safely revives that event behind an If-Match guard. Eventually, all ten runs passed. After hardening the system, I ran another ten successfully.

Accomplishments that I'm proud of

• Completed 20 full end-to-end runs—10 before and 10 after hardening—with 1,110 acceptance checkpoints and zero duplicate commitments or Calendar events.
• Conflicts were repaired in 7.2 to 10.2 seconds (average 9.1) on the deployed service.
• *Passed all 72 live security probes * and confirmed that rate limits hold up even after restarts.
• Achieved 100% accuracy on 32 extraction cases—including prompt-injection attacks—at about $0.0008 per message.
• *Ran 328 automated tests * and verified that every observation and action could be replayed exactly, byte for byte.
• Every claim is tied to the exact Cloud Run revision that produced it, and you can find the evidence in docs/proof_index.md.
• Built a no-login sandbox where anyone can enter a message and watch it get interpreted, planned, and repaired by the real stack—including live Gemini.
• Built entirely by me in two weeks.

What I learned

• “Exactly once” isn’t just a setting—it’s something the product actually delivers. I proved it by intentionally redelivering observations and actions and confirming the durable state stayed the same. Named tasks, stable event IDs, revision fences, and etag preconditions all came directly from these tests.
• Push latency is an optimization, not a dependency. If notifications are lost, it should only cause a delay—not stale data or failures.
• The architecture itself defines the trust boundary: Gemini interprets language and provides evidence, but only deterministic code decides what can actually act on external systems.
• Most importantly, an agent earns autonomy through proof, not just confidence. Testing against real systems revealed failure modes—like notification throttling and persistent Calendar event IDs—that mocks would have missed.

What's next for CommitmentOS

Next, I plan to add commitment dependencies, learned effort estimates, and support for more sources such as Outlook and Canvas, while preserving the same evidence-first, human-controlled trust model.

Built With

• docker
• fastapi
• firestore
• gemini
• gmail-api
• google-adk
• google-calendar-api
• google-cloud-build
• google-cloud-logging
• google-cloud-pub-sub
• google-cloud-run
• google-cloud-scheduler
• google-cloud-tasks
• google-secret-manager
• oauth-2.0
• pydantic
• python
• react
• typescript
• vite