I wanted to know if AI sub-agents could do more than generate text. Not draft a paragraph here and there, but actually run a content operation. So I let them run this blog for a week: research, drafting, SEO cleanup, and publishing prep, with me staying in the loop but not touching every sentence.
The experiment was real, the results were mostly good, and the failures were exactly where you would predict if you have ever managed a team. This is the full account: the setup, what worked, what broke, and the fixes that turned the experiment into the pipeline this site still uses.
The setup
One agent researched topics and gathered angles. A second turned the research into first drafts. A third ran an SEO pass over each draft. A fourth prepared posts for publishing. Each ran as an isolated sub-agent with its own session, spawned from the main agent and reporting back when done, which is the pattern now documented in the sub-agent content pipeline guide.
I stayed in the loop the whole week. Nothing went live without me looking at it, which turned out to be the single most important design decision of the experiment.
Mechanically, the week ran on OpenClaw’s sub-agent model. Spawning was non-blocking, so research could run while I reviewed the previous draft. Results arrived back in the main session as completion events rather than messages I had to chase, and when something looked wrong I could inspect a run with the sub-agent tools instead of guessing from the final output. The pattern is simple to describe and harder to keep disciplined: every stage is one isolated run with one brief, and the human sits at the merge point where the outputs come together.
What worked
The first good surprise was speed. Topics that would normally take me an hour to outline appeared in minutes. The second was consistency. Once I gave the system a clear structure, posts came back with a similar tone, format, and level of depth, which made the whole process easier to manage instead of harder.
Ranking what actually saved time:
- Topic research and angle comparison
- Headline variations on demand
- First-draft writing from a structured brief
- SEO cleanup: titles, meta, internal links, readability
- Formatting for WordPress
The system was fast and consistent. That was never the problem.
What went wrong
Quality drift was the first issue. A few drafts drifted too generic and needed stronger direction; I had not been specific enough about the reader and the promise. One post leaned too hard on summary language and needed more concrete examples. Another time the SEO pass improved the structure but flattened the voice, and I spent longer restoring the personality than the pass had saved.
The deeper problem was handoff quality. If the research agent returned loose notes, the writing agent had to guess. If the writing agent got too creative, the SEO pass had to clean up too much. Weak output at one stage multiplied the work at every stage after it, which is the same failure pattern you get with a human team that does not write things down.
Where the workflow broke down
Every break I saw traced back to the brief. A vague brief produced vague research, vague research produced guessing writers, and guessing writers produced cleanup work downstream. The fix was not better models or more agents. It was tighter prompts and explicit acceptance criteria between stages, so each agent knew what done meant before it started:
That formula, objective, output, write scope, and verification, is now the house style for every sub-agent task on this site. It did not exist before the experiment. It is the single biggest improvement the week produced.
What I would do differently
Three changes, in order of impact. First, a real outline step between research and drafting, because a good structure catches most generic-draft problems before they exist. Second, a final editorial checkpoint before publish that checks voice, examples, and claims, not just SEO boxes. Third, define the audience before the first draft starts: who the post is for and what they should be able to do after reading it. The more specific the brief, the less cleanup required later. That seems obvious now, but it matters enormously in practice.
The diagram maps the whole week onto one page:
How to run the same experiment
If you want to try this yourself, the version that produced the least regret was the one that scaled up slowly:
- Start with one stage, research. Give it a concrete brief with an output file and a verification line, and run it for a few days before adding more.
- Add the draft stage only after the research outputs are consistently usable. Loose research will poison every stage downstream, so fix stage one before trusting stage two.
- Keep the human gate from day one. Review every output in the main session before it moves on; that is where the standard gets set, and agents cannot set it for you.
- Write the acceptance criteria into the brief, not into your head. If a stage hands back work you have to reject, the brief was the problem, not the agent.
- Scale stages only when the handoffs are boring. Boring handoffs are the goal: each stage should be predictable enough that your attention moves to the editorial decisions.
That last point is the one I keep coming back to. A pipeline is working when the interesting part is the content again.
The honest takeaway
Could AI sub-agents run a blog for a week? Yes, mostly. Should they do it without human review? No, and the answer is not close. The best result came from using them like a small content team, not a fully autonomous replacement. They were fast, useful, and surprisingly good at structure, but the human still had to steer: set the angle, set the standard, catch the generic drafts, and decide what went live.
What changed afterward is the part I would emphasize. The rough edges did not kill the idea; they refined it. The lessons became the pipeline: concrete briefs with verification, a human gate before publish, and sub-agents used for what they are best at. That is the system behind the content on this site today, and it is the pattern covered end to end in how to use OpenClaw sub-agents for content creation and when sub-agents beat parallel tasks.
The system is strong enough to help a lot. It is not strong enough to disappear the editor, and that is the point.
Run Your Own Sub-Agent Content Team
A content pipeline needs agents that run reliably around the clock: research at night, drafts by morning, human review before publish. ClawTrust provides managed OpenClaw hosting so your sub-agent team works on schedule with automatic scaling and no DevOps overhead.
This post contains affiliate links. If you buy through them, I may earn a small commission at no extra cost to you.
About The Author
I tried something similar with a different agent framework and the results were all over the place. Did you find that the sub-agents needed a lot of manual prompting to stay on task, or did they mostly self-correct?
This was the first writeup I’ve seen that makes sub-agents feel practical instead of sci-fi. I’m curious whether you’d still use them for smaller blog tasks after seeing the token usage.