"We have agents" is about as informative as "we have software". The question is what they do, when they run and who notices when one stalls.
Ours grew into a fleet step by step. Not planned but grown: every single one came into being because a job was too regular to do by hand and too ambiguous to pour into a script.
This piece describes the groups, not each individual. A list of all the names would be an enumeration without insight.
The Rule Behind The Split#
An agent has one job. Not two.
That sounds like bureaucracy and is the reason the fleet works. An agent meant to check analytics and also watch competitors does both mediocrely, and when the result is poor you do not know which half caused it.
Two agents with one assignment each are sharper and, more importantly, judgeable separately. You can improve one without touching the other.
The Groups#
Leadership are agents that summarise rather than work themselves. They read what the others produced overnight and turn it into a report of what needs attention. Without that layer you would get a pile of separate notifications in the morning and read none of them.
Engineering looks at the code and the systems. What has grown, where warnings pile up, which dependency has a known hole, where the architecture has drifted from what is documented.
Content covers research, topic proposals, drafts, review. Always with separate roles for writing and reviewing, because an agent reviewing its own text finds nothing.
Visibility covers search engine standings, mentions in AI answers, visitor numbers, what competitors are doing. This group runs for our own sites and for client sites.
Operations handles servers, backups, certificates, containers, cost. The most thankless group, because its best day is the one where it reports nothing.
Review consists of agents whose only purpose is to attack the others' work. They write nothing and build nothing. They look for faults in whatever just got finished.
The last group is the one that delivers most.
Why The Reviewer Needs A Role Of Its Own#
A model that built something and is then asked whether it is good says yes. Not out of malice, but because it just built the thing the way it thought was right.
A reviewer with its own assignment behaves differently, especially when the assignment is not "review" but "refute". The hardest findings come from that group, including on things that had already passed other checks.
It gets better still when the reviewer comes from a different model family than the builder. Two models from the same house make similar mistakes and overlook each other.
What Happens At Night#
Most of it runs when nobody is around. That has a practical reason: an agent that takes a long time for a pass is in the way during the day, and nobody likes waiting for a report.
In the morning the result is there. Not as raw data but as text with what stands out. A report consisting of numbers without interpretation stops being read after two weeks.
What They Are Not Allowed To Do#
None of these agents sends a mail to a client. None changes anything on a client site without a human in between. None deletes anything.
That is the hardest boundary in the whole setup, and it is deliberately enforced technically rather than merely stated as an instruction. An instruction is a request. A tool an agent does not have in the first place is a boundary.
The Number, And Why It Is Not Here#
It would be easy to name a figure. It sounds good and is almost always misleading.
Count files and you get a large number that includes helper parts and sub-agents which never run alone. Count only what starts on a schedule and it is fewer. Count what produces something daily that a person reads and it is fewer still.
All three numbers are correct and mean different things. So we would rather name the groups and what they do. Anyone who needs a figure should always ask what was counted.
