AI FusionIQ Labs runs on six modules. Billing, CRM, the service desk, the knowledge index, the agent roster, and the internal operations that fail quietly if nobody watches them. Agents do real work in all six.
And I am still the manager of every single one of them.
Every agent reports to me. Every scorecard comes to me. When one underperforms, I decide what happens to it. For a company whose entire pitch is that AI should take the repeatable work off your people, that probably looks like a contradiction, or like I have not finished building it yet.
It is neither. Holding the manager seat is the part of the design I would give up last.
What I got wrong first
My early instinct was to let agents manage themselves. If an agent is underperforming, it should know, and it should step back. That is elegant. It is also the wrong answer, and I talked myself out of it before I shipped it.
An agent that can switch itself off can also switch itself off for the wrong reason, quietly, on a Tuesday, and nobody finds out until a week of work did not happen. The dangerous state in any automated system is not broken. Broken announces itself. The dangerous state is on and unexamined, because that is the state where people stop checking.
So the rule I ended up with is narrower and duller: the scorecard flags, a person decides. An agent can tell me it is struggling. It cannot act on that by itself.
The test I use before any agent runs unsupervised
I used to think the question was how much damage an agent could do. Low stakes first, work up from there. That turned out to be the wrong question, because low stakes still means wrong, just cheaply wrong, and it teaches you nothing about whether the thing is trustworthy.
The question I use now is whether I can undo it. An agent runs without my approval only when all four of these are true:
- Its work can be reversed if it is wrong.
- Nothing it does is visible outside the company until a person has seen it.
- It leaves a record of what it did, good enough to audit later.
- There is a fallback if it stops working entirely.
A handful of agents pass that test today and run unsupervised. The rest prepare work and hand it to a person. That ratio is not a scoreboard I am racing to run up. It is the result of applying the test honestly, and it moves only when an agent earns the next step.
Why the seat stays occupied
There is a version of this where I hand the manager seats to manager agents, and eventually I will, per team, once I can see that each one is doing its job. But the order matters more than the destination.
You cannot delegate oversight of a system you have not personally watched work. If I hand off the manager seat before I know what normal looks like for each agent, I am not scaling. I am just moving the place where I will eventually be surprised.
This is also the single thing I tell clients that I can say from the inside rather than from a slide. Somebody has to own the AI system or it drifts. Not own it in the sense of having bought it. Own it in the sense of being the person whose name is on what it does. That costs real hours every week, and I am paying them.
What I would tell you to do with this
If you are putting AI into your own operations, the thing worth copying is not my architecture. It is the sequence: prove one workflow, keep a person in the loop while it proves itself, make the reversibility test explicit before anything runs alone, and do not hand off the oversight seat until you know what normal looks like.
Everything else, including which tools you pick, is downstream of that. The full version of the argument, with the operating model drawn out, is on the Start Here page.
The part I am still genuinely unsure about: at what point does holding every manager seat stop being diligence and start being the bottleneck I keep warning clients about? If you have run this transition inside your own company, I want to hear where you drew that line.