Actions With Receipts: What It Takes to Let AI Touch Your Real Tools
The gap between advice and execution is where most decisions die. Closing it means letting AI write to your real systems — which is only acceptable if every action is approved, provable, and reversible.
Every decision process has the same leak at the end. The analysis is done, the call is made, everyone agrees on the three things that need to happen — and then those three things go into somebody's notes and one of them happens.
The obvious fix is to let the system do the work. Draft the message, file the issue, update the doc, schedule the review. The obvious fix is also, to anyone who has operated a real business, an obviously terrifying idea. Software that can write to your systems on the strength of its own reasoning is one bad inference away from an embarrassing email to your largest customer.
So the interesting question is not "can AI take actions." It has been able to for years. The question is what has to be true before a sensible person would let it. We think there are four answers, and all four have to hold at once.
1. Nothing happens without your approval
The default is that actions are proposed, not performed. Your board can say "I'll draft the note to the customer and file the follow-up" — and then it stops, and shows you exactly what it intends to do, and waits.
This sounds like it removes the value. It does not, and the reason is worth being precise about: the expensive part of most small tasks is not the execution, it is the composition. The blank page, the recall of who needs to be told, the decision about tone. Handing you a finished draft that you approve in four seconds captures nearly all of the value and none of the risk. The approval step costs you almost nothing and buys you the thing that makes the whole feature usable.
For genuinely routine, low-blast-radius actions you can widen the gate and let them through. That is your call to make, per action type, and it is reversible.
2. Every action is traceable to a reason
An action with no provenance is indistinguishable from a bug. So every action carries its lineage: which decision produced it, which expert proposed it, on what reasoning, approved by whom, at what time, with what result.
This matters most in the moment you least want to be doing archaeology. Something looks wrong, and the question is what touched this and why. An audit trail that answers that in ten seconds is the difference between a curiosity and an incident.
It also matters for the slower question. Six months on, reviewing whether a decision worked, you want the chain intact: this was the call, this was the reasoning, these were the actions it produced, this is what happened. That is a complete record of a decision rather than a memory of one — the machine-readable version of the discipline in The Decision Journal.
3. It is reversible
Approval is not enough on its own, because approval is a human process and humans approve things at speed while thinking about something else.
So writes that can be reversed come with an undo window — thirty seconds from execution to take it back, with the reversal performed by the same integration that made the change. Not "mark it as undone in our records." Actually put it back.
Thirty seconds is a deliberate number. It is long enough to cover the real failure mode — the immediate wait, no that lands about two seconds after you click — and short enough that the system is never holding a large population of half-committed actions. It is the wrong shape for changing your mind next week; that is a new decision, not an undo. The undo window exists for the mis-click, which is the mistake that actually happens.
The honest limit: some actions cannot be reversed by anyone, including you. A sent email is sent. Where that is true, the system says so before you approve rather than after, and those actions never get the wider gate.
4. It notices when something is off
The last layer is the one you hope never fires. Write activity is watched for patterns that do not look like normal use — a burst of writes, an unusual spread of recipients, a sudden change in what is being touched. When something trips, the affected actions get escalated back to requiring explicit approval for a day, and you get told why.
This is a fail-closed design on purpose. The bad state is not "the system was too cautious for an afternoon." The bad state is discovering next month that something was writing where it should not have been.
The part nobody wants to hear
All four of these make the product slower than the demo version of itself. A version with no approvals, no audit, and no undo would look dramatically more impressive in a thirty-second video, and it is the version we are not going to ship.
The reason is a straightforward asymmetry. The upside of a governed action layer and an ungoverned one is nearly identical — the work still gets done, you tapped approve. The downside is not remotely identical. One of them has a worst case of "that took an extra four seconds." The other has a worst case that requires an apology to a customer, and possibly a lawyer.
Anything that writes to your real systems is holding your reputation. Governance is not friction added to that; it is the thing that makes it a reasonable trade at all.
How this shows up in practice
A board sitting ends with a verdict and an action plan. The plan is not prose — it is items, with owners and dates, and the ones the system can execute are marked as such. You work down the list approving what you want done. What gets done is recorded against the decision that produced it.
Then the loop closes on the far side: when the follow-up window comes around, the board asks how it went, and the record it is asking against includes what was actually executed, not just what was recommended. Advice that was never acted on and advice that was acted on and failed are two completely different data points, and a system that cannot tell them apart cannot learn from either. That is the mechanic in The Board That Remembers.
Where to look
The full detail on data handling, isolation, and retention is on the trust page. The catalogue of what can be connected — and what each connection can and cannot do — is on the integrations page. If you would rather drive the whole thing from your own stack, the platform page covers the API and tooling surface.
And if you want the short version: your board can do the work. It just has to ask first, show you what it did, and be able to take it back.