The social post describes two Tuesdays. On the first, a customer writes back angry, and you learn that a reminder never went out. On the second, you read an AI-drafted message, change one line, and click yes. The software involved could be identical in both cases. What differs is who owns the outcome, and that difference matters more than most conversations about AI tools admit.
Most of the discussion about AI at work focuses on capability: what the model can write, how fast it summarizes a thread, how well it reasons through a spreadsheet. Those questions are real, but they skip a more practical one. When an AI system acts on your behalf, who is accountable for what happens next? If the answer is "nobody in particular," you will eventually find out the hard way, usually from a customer.
Two ways the same tool can fail
Consider the reminder that never went out. An AI assistant was set up to follow up on overdue invoices, but nobody defined what "overdue" meant for accounts on a payment plan. The agent did exactly what it was built to do, which was nothing for those accounts, because nobody had told it otherwise. The failure sat in the gap between configuration and expectation, and no one was watching that gap.
Now consider the draft. The assistant writes a reply to a long-standing client who asked about a renewal. The draft is mostly right. It promises a date that is a day too early. You catch it, fix it, and send it. The outcome is correct because a person was positioned to decide before anything left the building.
The second case is not a story about AI being safe. It is a story about where the decision was made. A review step turned the assistant from an autonomous risk into a drafting tool with a human at the point of consequence.
Deciding which actions need a yes
Not every action deserves the same scrutiny. Reading a report, summarizing a thread, or pulling a list of accounts that have not replied in seven days carries little risk. Sending money, deleting records, emailing a customer for the first time, or changing a price carries a lot. A sensible setup separates these explicitly.
A practical way to start is to list the five or so actions in your business that would cause real damage if taken incorrectly, then require approval for those and only those. Everything else can run with logging and a clear way to review what happened. The goal is not to slow the assistant down across the board, which teaches people to click through approvals without reading them. The goal is to make the approval meaningful by keeping it rare.
Check what the agent can see
Before any AI tool touches your database or inbox, count what it cannot see. A reminder agent that cannot read payment-plan status will send reminders to people who are current. A reporting assistant that reads yesterday's export will show numbers that disagree with the live dashboard. Write down the fields, systems, and exceptions the tool lacks access to, and treat that list as part of the spec.
Reading the bill as an engineer would
Ownership also extends to cost. Token usage is not an abstraction. Long threads, large attachments, and repeated context all add up. Look at the cost of a single typical question, then at the cost of the worst question your team asked this month. If you cannot explain the difference, you do not yet own the spending, and surprises will follow.
What ownership looks like in practice
Owning the outcome means a few concrete habits. Someone is named for each automated workflow. Someone reviews the log on a schedule, not only after a complaint. Corrections given to the assistant are kept and checked, so the same mistake does not return next month. And when a customer writes an angry reply, the team can trace back through the chain to find which step had no owner.
The same AI can produce the first Tuesday or the second. The difference is not in the model but in whether a human decided, in advance, which decisions were theirs to make. Start there, and the tool becomes useful instead of risky.