This week's work inside our own operations was not a new agent or a new capability. It was a line: which decisions an AI agent can act on the moment it sees them, and which ones have to stop and produce something a person reads before anything happens.
Why the line has to be explicit
Our own bench of AI specialists already does real work: drafting content, running weekly ad diagnostics, keeping records in sync across every project we run. None of that is new. What was missing was a written rule for where judgement stops and a person's sign-off starts, rather than each agent, or each of us, deciding case by case whether a given action felt safe enough to just do.
The rule we landed on is simple to state and harder to keep honest under pressure: anything that changes what we charge, what we promise a client, or what goes out publicly under our name gets a written decision record and a person's approval first, no matter how confident the agent producing it is. Everything else, the routine, reversible work, can proceed on its own and get logged for review after the fact.
Stating the rule is the easy part. Checking whether your existing systems actually follow it is where you find out what you have been letting slide.
Two places we had already broken it
Writing the rule down surfaced two places where our own systems did not meet it yet.
The first was noise. Every automated routine we run posted a status update to the same channel whether it succeeded or not. A channel that says "all good" every single day trains you to stop reading it closely, which means the one day it should say something else, it arrives with exactly the same visual weight as every boring success message before it. We changed this: routines now interrupt only when something actually needs a decision, and a small number of genuinely urgent situations now reach a phone directly instead of waiting in a channel nobody is watching in real time.
The second was reach. One of our own agents is responsible for keeping every project we run in sync, and until this week it would push its updates to all of them automatically at the end of a working session. That is convenient right up until a single bad output can land in a dozen places before anyone looks at it. That flow now stops for a person to preview what changed and approve it before anything gets pushed. It is the old security idea of least privilege applied to an agent: give each system only the access it needs to do its job, and nothing standing beyond that.
Neither of these was a disaster waiting to happen. Nothing had gone wrong yet. That is exactly why they were worth finding: the cost of fixing an over-broad permission before it causes a problem is a few hours of work. The cost of fixing it after is whatever the mistake actually was, plus the trust it cost you.
What this is worth to a reader who is not us
If you are handing more decisions to an AI system this year, the useful moment to draw this line is before the first bad push, not after it. Sort what you are automating into two piles: things where a mistake is annoying, and things where a mistake is expensive, public, or hard to undo. The first pile can run on its own and get checked later. The second pile needs a person in the loop every time, and that has to be a rule you wrote down in advance, not a feeling you have about how well things have gone so far.
Automating a task and automating the decision to act on it are two different things. The first saves you time. The second is where the actual risk lives, and it is worth a written answer before you need one, not after.
If you want a quick read on how your own operation handles this, the Hexagram Diagnostic takes eight minutes and scores The Intelligence, the pillar that covers measurement and AI operations. The AI marketing consulting page explains how we run our own bench, and the full team shows who owns what.
