The generalist problem
I started with one agent doing almost everything: research, code, operations, content, inbox work, and the occasional attempt to explain my own business back to me.
It worked surprisingly well. That was the problem.
One confident thread can blur discovery into implementation and implementation into verification. The same context that helps an agent remember why it made a decision also makes it more likely to defend that decision. Asking the builder whether the build is good is still self-review, even when the builder has a charming name and a very large context window.
I split the work, not the personality
Hermes profiles made the practical separation cheap. Each profile gets its own configuration, memory, sessions, skills, cron jobs, and gateway state. I used that boundary to create distinct operating roles rather than copies of one omnipotent assistant.
One role coordinates and owns the business context. A research role collects public evidence but cannot contact prospects. A builder takes one approved task and changes code. A verifier reads the deployment and test evidence without inheriting the builder’s story. Sensitive financial work sits in its own lane. Scheduled scouts can stay silent when nothing changed.
The names are decoration. The authority boundaries are the product.
Handoffs happen through artifacts
The agents do not need a virtual conference room. They need explicit inputs and outputs.
A research run leaves cited evidence. A coding run leaves a diff, tests, a source revision, and a handoff. A deployment run leaves the live URL and provenance. A verifier either accepts that evidence or returns a concrete defect. The next role reads the artifact, not a motivational summary from the previous model.
For recurring implementation work, the contract became intentionally narrow: one task per run, isolated worktree, bounded permissions, focused tests, source and deployed revision checks, then independent QA. If there is no actionable task, the correct output is silence—not an agent inventing busywork to justify its cron slot.
Profiles are not a security fairy
Separate memory and skill directories reduce contamination. They do not automatically create operating-system isolation. On a normal host, external command-line tools may still see the same user-level credentials unless the environment is configured more strictly.
So the boundary also needs tool restrictions, separate credentials where necessary, read-only APIs, push blocking, approval gates, and explicit rules about which profile may touch which data. A profile is a useful state boundary. It is not a reason to stop threat-modelling.
The result is less magical and more autonomous
Splitting the system did not make the underlying models more intelligent. It made failure legible.
I can see whether research was weak, routing was wrong, implementation drifted, deployment mismatched the source, or verification was too shallow. I can improve the procedure attached to that role instead of stuffing another paragraph into one giant system prompt.
That is the contradiction at the centre of useful autonomy: the system becomes more independent when each part is allowed to do less.