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 three answers, and all three have to hold at once.
1. A write is a preview you confirm
The default is that writes are proposed, not performed. Your Chief of Staff can say "I'll draft the note to the customer and file the follow-up" — and then she stops, shows you exactly what she would write, marked as needing your review, and waits for your confirm.
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 confirm in four seconds captures nearly all of the value and none of the risk. The confirm step costs you almost nothing and buys you the thing that makes the whole feature usable.
Writes are narrow on purpose. There are five kinds: a Notion page, a Google Doc, a Slack message, a Linear issue, and a Gmail draft. The Gmail one is a draft — you send it. Writing to your tools is on Pro and above; reading is how she grounds an answer, and she says what she read.
2. Every write is traceable to a reason
A write with no provenance is indistinguishable from a bug. So every one carries its lineage: which decision produced it, which expert proposed it, on what reasoning, when you confirmed it, and what came of it.
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. A record 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 writes 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 says what it cannot take back
There is no undo window, and we would rather say so than imply one. The safeguard is the confirm, and it comes before the write, not after. A preview is where you catch the wrong recipient, the wrong tone, the wrong page.
Some actions cannot be reversed by anyone, including you. A sent email is sent. That is why Gmail writes stop at a draft you send yourself, and why a mistake you spot afterwards is a new decision, not an undo.
The part nobody wants to hear
All of this makes the product slower than the demo version of itself. A version with no confirm step and no record 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 write and an ungoverned one is nearly identical — the work still gets done, you tapped confirm. 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's memo ends with a first move, and the first move becomes a commitment with a date. When the move is a write she can prepare — a Notion page, a Slack message, a Linear issue — she prepares it as a preview, and you confirm it or leave it. Nothing is written until you do. What gets written 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: she can prepare the work. You confirm it, and the record shows what happened.
