Inspiration

We kept hearing about AI agents that can "manage your life" but every single one of them just... does stuff. Cancels your subscriptions, moves your money, edits your calendar. No review, no undo, no proof it did the right thing. That scared us. So we asked: what if we treated life decisions the way good engineers treat code? What if an AI agent had to open a pull request before it could change anything about your life?

What it does

Life.git is local-first change control for personal AI. Agents can look at your bank transactions, subscriptions, and calendar, then propose changes like "this streaming service hasn't been used in 47 days, flag it for review." But they can't just do it. Every proposal goes through deterministic verification, an independent reviewer checks the math, and nothing merges without CI passing and a human saying yes. It's Git for your life decisions, complete with branches, receipts, and reverts.

How we built it

The whole thing runs on a strict trust pipeline. CSV and ICS files get parsed into canonical events. Domain analyzers (finance, subscriptions, calendar) produce structured change requests with source hashes, calculation chains, and evidence bindings. A deterministic verifier checks every claim against policy without importing any AI model. The git engine handles branching, merging, and reverting with full audit trails. On top of that sits a Live Orchestra mode where three real AO worker agents run in isolated worktrees, open actual GitHub PRs, and get reviewed by an independent verifier before anything can merge. The dashboard is React, the backend is pure Node with zero external runtime dependencies, and every single claim traces back to a specific cell in a specific file with a specific hash.

Challenges we ran into

Getting the preflight system to produce actually helpful error messages instead of cryptic COMMAND_FAILED:git:128 was a real journey. We had to handle cases like repos with no commits, no remote, wrong branch, dirty worktree, and SHA mismatches, each with its own distinct actionable message. The review parser was another beast. Our first version used substring matching to check if a review passed, which meant "not approved" could technically register as "approved." We rewrote it to use structured JSON parsing with exact field matching and SHA binding. And making the integration tests stable under CI load required rethinking how we detect server readiness, capture child process output, and handle cleanup timeouts.

Accomplishments that we're proud of

132 tests pass deterministically across unit, integration, policy, adversarial, and replay suites. The verification pipeline is completely model-free, so no AI can talk its way past a policy check. Every financial claim traces to an exact source hash and row locator. The independent reviewer is genuinely independent, with its own identity, not a copy of the worker's session. And fixture mode is contractually unable to unlock real merge, so test evidence can never be confused with real AO evidence. The whole system fails closed on unknown states instead of guessing.

What we learned

That the hardest part of building trustworthy AI systems isn't the AI part. It's the boundary between trusted and untrusted data. Every piece of output from an agent, a CLI tool, or a GitHub API is untrusted input that needs strict parsing. We learned that substring matching on review verdicts is a security hole. That parallel preflight checks can mask root causes when they all fail for the same reason. That integration test timeouts need to account for the slowest CI runner, not your fast laptop. And that honest labeling (saying "fixture" when it's a fixture, "human capture required" when it is) matters more than making the demo look polished.

What's next for Life.git

Adding more life domains like health data and housing expenses. Building a real mobile-friendly review UI so you can approve or reject proposals from your phone. Exploring multi-person households where two people might have conflicting calendar or budget proposals that need semantic conflict resolution. And eventually, once the trust model is proven solid, carefully adding opt-in external effects with multi-party approval, so the system could actually cancel that unused subscription, but only after two humans and a verified receipt chain say it's safe.

Built With

Share this project:

Updates