title: "Agents propose, you approve: why every AI change should be a diff" slug: "agents-propose-you-approve" dek: "Most agent systems execute first and monitor after; Lycato makes every agent action a git diff that sits unmerged until you read it." audience: "Solo and small-team founders running company operations with AI agents, who want leverage without giving up the ability to say no." tags: [ai-agents, git, guardrails, founder-ops, code-review]

Execute now, ask forgiveness later

A founder on r/AI_Agents put it plainly in a thread titled "autonomous agents are overrated": the damage these systems cause isn't exotic. It's boring and irreversible. A calendar wiped because an agent decided a "clean up old events" task meant deleting everything before doing the actual work. An email sent to the wrong recipient because the agent autocompleted an address from a similar name in the CRM. None of that requires a rogue model. It only requires an agent with write access and nothing between "decide" and "do."

That gap is the default architecture, not an edge case. A Hacker News thread on agent design named it directly: most agent systems are fail-open. The default posture is to execute, then let a human find out later that something went wrong — via a log line, a Slack ping, or an "undo" button that may not actually undo anything. Monitoring gets bolted on after the fact. Permission is implicit until someone notices it shouldn't have been.

A large company can absorb that model. There's a platform team watching logs, a rollback runbook, headcount to catch the occasional incident. A solo founder running finance, CRM, and investor comms through agents has none of that. You are the platform team. And by the time you're monitoring, the calendar is already gone.

The hard part was never the model

The more interesting argument isn't about capability, it's about where the trust boundary sits. Another thread, "stop selling autonomous agents to businesses", makes it directly: businesses don't actually want autonomy, they want leverage with a checkpoint. One commenter there put the mechanism plainly: "treat AI output like a contractor's PR — you wouldn't merge it without reviewing every line."

That's not a metaphor Lycato invented. It's the model the market keeps arriving at on its own, because it's the same model every engineer already uses for code. We built an entire discipline — pull requests, code review, CI gates — around the premise that even a senior engineer's change needs a second pair of eyes before it touches production. Then agent tooling gave AI write access to calendars, inboxes, and bank-connected accounts with none of that discipline, mostly because the interface was chat, not a diff, so the analogy never got made concrete.

Fail-closed, by construction

Lycato inverts the default. A company's state — CRM, ledger, decisions log, obligations and compliance deadlines, investor updates, KPI snapshots, cap table — lives as plain markdown files in one git repo. When an agent wants to change something, it doesn't call an API and mutate a record. It proposes a diff against those files. The diff sits unmerged until you review it and merge it yourself, the same way you'd handle a pull request from a contractor.

A reconciliation agent watching your Mercury feed, for example, might open something like this:

--- a/money/ledger-2026-07.md
+++ b/money/ledger-2026-07.md
@@ -14,3 +14,7 @@
 | 2026-07-02 | Stripe payout | +$8,140.00 | reconciled |
 | 2026-07-03 | AWS | -$412.18 | reconciled |
+
+## Proposed by agent: reconcile-agent, 2026-07-06
+| 2026-07-05 | Wire, "J SMITH CONSULT" | -$3,000.00 | needs review |
+> No matching entry in CRM or vendor list. Flagging instead of guessing a category.

Nothing here executed. No money moved, no vendor got an email, no compliance item got marked done. It's text sitting on a branch, waiting in Cockpit's Review surface — or in plain git diff if you'd rather read it there. You approve by merging. You reject by not merging. If you merge something and change your mind later, git revert undoes it, and the repo's history shows exactly what was proposed, by which agent, and when a human signed off.

What this actually buys you

The point isn't that agents stop making mistakes. They will still misread a wire description or miscategorize a KPI. The point is where the mistake lives. In a fail-open system, the mistake is an action already taken, discovered downstream, after the calendar is empty. In this model, the mistake is a line in a diff — either caught on review or not, but either way attributable. git log says which agent proposed what and whether a human approved it. That's a different conversation with your co-founder or your accountant than "the agent did something and we're not fully sure what."

It also decouples the number of agents from the amount of standing trust you extend. You can run one agent watching Stripe, one drafting investor updates, one triaging the inbox, all at once, without granting any of them write access to anything. Every one of them terminates at the same gate: your merge.

What Lycato doesn't do

Lycato doesn't make the review meaningful for you. If you rubber-stamp every diff without reading it, you've rebuilt fail-open with extra steps. The gate is structural. Whether you actually use it is still on you.

It also doesn't score diffs as safe-to-skip. Reviewing every proposed ledger line or CRM update is real friction for a founder already short on time, and Lycato doesn't currently offer a confidence threshold that lets you auto-merge the "low-risk" ones. That's deliberate, not an oversight — "this one's probably fine" is exactly the fail-open failure mode again, just with a nicer UI around it.

And Lycato isn't a compliance officer or a bookkeeper. The obligations log tells you a filing is due; it doesn't file it, and it won't tell you if the categorization is wrong for tax purposes. It's a substrate for keeping the record straight, not a substitute for knowing what belongs in the record.

The takeaway

An agent working on your company will eventually get something wrong. That's not really in question. What's in question is whether the mistake arrives as an action already taken — a deleted calendar, a wire to the wrong account — or as a diff sitting in front of you, unmerged, waiting for ten seconds of attention before it becomes real. Build the system so it's always the second one.