TL;DR: Sub-agents are useful when they extend judgement. They become risky when they inherit authority. If you cannot explain why the next step exists, stop before the process starts making decisions for you.
I learned this in a content-adoption project with a simple intended outcome. Take reviewed before-and-after evidence and turn it into a clear public story. A visitor needed to understand five things:
What was wrong before.
What work was done.
What changed afterwards.
What the result proved.
Where the evidence stopped.
That was the job. But the workflow grew around the job.
The agent introduced evidence packages, candidate files, revision numbers, cryptographic digests, approval receipts, lifecycle stages, and repeated review gates. During one abandoned phase, the process produced five revision loops with no end in sight.
Each revision looked disciplined, and each review created more evidence that the workflow was being followed.
Yet each pass moved me further away from the thing I actually needed to judge: whether a real visitor could understand the public story.
The problem was not that the sub-agents were bad at the work. They were doing what sub-agents are good at. They followed instructions. They filled gaps. They checked rules. They produced the next artefact.
The problem was that execution detail had started to act like decision authority.
A reviewer PASS could tell me that a candidate matched a policy. It could not tell me whether the policy was still serving the visitor. More gates increased confidence in the paperwork while reducing confidence in the output.
That is the trap.
Sub-agents multiply process. If the process is clear, that can be powerful. If the process is unclear, they multiply the confusion with impressive discipline.
The fix did not begin with another repair step. It began by stopping.
We preserved the abandoned branch so useful work and failure evidence were not lost. Then we returned to the intended outcome and built the visitor-facing story directly.
The new path was smaller by design: one reviewed source report, one concise public story, one consolidated preflight, at most one repair pass, one rendered human approval, normal validation, and Git history.
That was not less rigorous. It put the rigour closer to the decision that mattered.
Could a visitor understand the result in about thirty seconds?
Were the claims accurate?
Were the limitations visible?
Did the page work without internal evidence terminology?
Had I reviewed the rendered result, not only an agent status report?
Keeping the driving seat does not mean manually checking every line of code. It means keeping the decisions that define the work in human hands. Define the outcome in plain language. Understand the path before authorising it. Inspect the real output at meaningful points. Do not rely only on checklists, summaries, and PASS labels.
The operating rule is simple: Do not progress unless you understand the process well enough to explain it and stop it. This improves efficiency and control. It exposes assumptions. It makes boundaries visible. It gives you a clear place to challenge scope, preserve evidence, or reject unnecessary bloat before it becomes part of the work.
Sub-agents can research, implement, compare, test, and review. Let them do that.
But keep the destination, the quality decisions, and the authority to continue in human hands.
Confidence in an output does not come from the number of agents involved. It comes from understanding how the output was produced, seeing that it meets the real objective, and knowing you could have stopped the process when it stopped making sense.
-----------
If you find this content useful, please share it with this link: [https://patrickmichael.co.za/subscribe](https://patrickmichael.co.za/subscribe)