How I built a 10-agent editorial department that runs my blog

What you need if you want to build the same thing:

• A machine to run it on. A mini PC, a Mac mini, or a VPS for a few dollars a month. I use a Geekom A5 and it is plenty (nobody is sponsoring me to say that). I will move to a Mac mini once those can run larger models locally; today they are not powerful enough for what I need.
• A gateway to your model. Hermes or Openclaw. Both let you drive an underlying model, keep improving your own setup over time, and reach you through Telegram, which is how I approve things from my phone. I recommend Hermes: I ran into too many issues with Openclaw, and Hermes has been highly reliable.
• An agent orchestrator. Paperclip, which is open source. This is where the agents themselves live: their instructions, their schedules, and the dispatch between them.
• Model access. A subscription with OpenAI or MiniMax, or direct API billing with whichever provider you prefer. I would point you at DeepSeek first; it is the most effective model for the price I have found.
• A blog, hosted somewhere. I built mine with Lovable, mostly because I also need it to build my own apps, but any website builder will do as long as it can regenerate the site from a repository.

For years I heard the same advice from every direction, and it was good advice: put your work online. Share what you know. Build something that markets you while you sleep.

Fine. I am a freelance SAP consultant. I work fifty-hour weeks. I am married. I train. I sleep, occasionally. Somewhere in there I was supposed to find the hours to build a blog and then keep feeding it with pieces good enough that a finance director would read to the end. Not "post something". Find the topic, research it, draft it, edit it, illustrate it, publish it, and do it again the following week, for months, before the first reader ever shows up.

That was the first problem, and it was not a motivation problem. The time did not exist and was never going to. A solo blog dies because there is no production line behind them, and one person cannot be researcher, writer, editor, designer and SEO technician in the same evening after a client day.

The second reason was less respectable. I had been using Claude daily in my consulting work since Opus 3, and I had become comfortable with it. Chat, prompt, output, useful result. All of it firmly inside my comfort zone. I wanted to build something with an actual architecture underneath: several agents, real orchestration, a system that kept running when I was not typing into a box. The blog did not require that. I wanted the skill.

Two needs pointing at the same object. A blog I had no capacity to staff, and an excuse to build something complicated.

So I went down the rabbit hole. A landing page, then the blog itself, then a personal agent gateway running on a home server, then APIs, then AI writing skills, and eventually the thing this article is about: ten agents running an editorial department while I approve three things a week.

The interesting part of that system is not that agents can write. Everyone knows that by now. The interesting part is the plumbing around them, which is where all of my mistakes are buried: which agent is allowed to do what, where the data lives, what stops the machine from flooding the blog with mediocre articles, and which parts I deliberately left manual because automating them made the output worse.

Where this came from

I described the starting point in an earlier piece, the three ways I write articles now. The short version: without autonomous agents, I wrote by generating a draft and then rewriting it into something that sounded like me. Deleting em dashes. Cutting sentences that parsed correctly and said nothing. Checking every statistic because I could not trust a single one of them. I was doing the hard half of the work after the machine had done the easy half, and I was doing it every single time.

That piece ended with a taxonomy: three methods for three jobs. A hand-written method for opinion pieces where my perspective is the point. A draft-and-rewrite method for one-offs. And an agentic pipeline for everything else. What I gave the pipeline back then was four lines: one agent finds topics, another develops angles, a third writes research files, a final one drafts the article.

Four lines was honest but useless to anyone trying to build it. The gap between "agents work in sequence" and a system that publishes reliably for months is almost entirely made of governance, and that is what I want to unpack here.

One correction to my earlier self. I wrote back then that the pipeline's articles ranked and informed but carried none of my voice, and that this was fine. That was true at the time. It stopped being true, because I kept sharpening the writer agent's instructions over the following months: a voice guide with seven concrete markers, a list of banned vocabulary, a punctuation rule that forbids the em dash outright, a mandatory de-AI pass at the end of the draft. It took several months of rework to get a voice really close to what I could have written myself.

Why one writer agent is not enough

The obvious version of this system is a single agent with a good prompt: give it a topic, get an article. I tried it. The output has a specific failure signature that is easy to recognise once you have seen it twice.

It is filled with confident generalities. It never argues against itself because the same context that produced the claim is the context evaluating it. And it has no idea whether the topic was worth covering, because nothing upstream decided that.

Splitting the work into ten roles is not organisational theatre. Each split buys something concrete.

The first thing it buys is an adversary. The editor challenges the writer, the researcher hunts for counter-arguments before the writer has even seen the angle, and no agent grades its own homework.

The rest of the reasons are technical. Ten agents means ten separate instruction files, each carrying its own role, its own skills and its own tools, instead of one enormous file trying to cover everything at once.

Token efficiency. No stage carries instructions it does not need. The scout hunting for next month's topics has no reason to be reading fifteen kilobytes on how to construct a paragraph, and the writer has no reason to be reading the scoring rules for topic selection. Each agent loads its own file and nothing else, which keeps every run small and cheap.

Reliability. The fewer tools and permitted actions an agent has, the smaller the space of things it can do that you never asked for. The visual designer has no terminal and no permission to touch pipeline statuses; it cannot wander off in a direction that matters, because no such direction is available to it. Narrow scope is a safety mechanism as much as an efficiency one.

Improvability, which is the advantage I underestimated at the start. With one agent per step, I improve a step in isolation and watch what changes. With a single agent producing a finished article end to end, a disappointing result is a mystery: was the topic weak, the research thin, or the writing flat? You cannot fix what you cannot locate. Ten steps means ten places to look, and each one leaves a visible artefact I can read.

Three layers making the system reliable

The system has three layers, and keeping them separate is what makes it debuggable.

The supervision layer is Hermes, running a single powerful model. It runs the scheduled checks, summarises what the agency did, and reaches me on my phone through Telegram, which is where I approve or reject. It has a fallback chain to cheaper models if the primary is unavailable. This layer does no editorial work at all and dispatches nothing; it watches and reports.

The production layer is Paperclip, where the ten agents live and get dispatched. They run on a faster, cheaper model than the supervisor, because their jobs are narrow and heavily specified. Each one is woken by a scheduler, reads its instruction file, does its job, and goes back to sleep. They do not talk to each other directly; the editorial director agent inside Paperclip routes work between them.

The data and publication layer is where the design actually gets decided, and I underestimated it at first.

Why a shared knowledge base, then a Git repo

Everything the agents produce lives in a Notion workspace, and everything that gets published lives in a Git repository. Two different tools for two different reasons.

Notion is the source of truth during production, for three reasons that all matter. It is free at my volume. It is readable by a human on a phone, which means I can look at the state of the entire pipeline while sitting through a one hour status meeting where I am needed for two minutes. And it has a status field that agents can both read and write, which turns out to be the whole trick: the queue is not an abstraction inside a program, it is a column I can see with my eyes. When something goes wrong, I do not read logs. I look at the board and see that four articles are stuck at the same stage.

Git is the publication target for a different reason. An agent producing a Markdown file with a YAML header is doing the simplest possible task: write text into a file, commit it. There is no CMS API to authenticate against, no session to expire, no editor state to corrupt, no rich-text format to mangle. The site regenerates from the repo, so publication is one commit. Every time I have replaced an API call with "write a file and commit it", reliability went up.

The principle underneath both choices: the source of truth is readable by a human, the output format is trivial for a machine. Any time I violated that, I paid for it in debugging.

The org chart

Ten agents, each reporting to an editorial director agent that dispatches work and controls the publication tap.

Agent	Job	Cadence
Evergreen Scout	Finds timeless topics	Monthly
News Scout	Finds current-affairs topics worth a long analysis	Weekly
Deep Researcher	Builds the research dossier: sources, data, counter-arguments	Event-driven, overnight
Long-Form Writer	Writes the full draft in my voice	Mon / Wed / Fri
Structural Editor	Fixes structure and argument; protects the voice	Mon / Wed / Fri
Visual Designer	Selects images from the bank and specifies placement	Timer plus event
SEO Architect	Metadata, final assembly, commit to the repo	Mon / Wed / Fri
Editorial Director	Dispatches, escalates, throttles publication	Several cycles a day
Memory and Analytics	Writes entries, tracks published performance	On demand
Repurposing Agent	Turns a published article into other formats that will be used later by social media agents working in another Paperclip agency	On demand

Two structural rules make this org chart hold together.

Every agent has its own instruction file containing its role, its scope, its scoring rules where relevant, and, importantly, an explicit list of its own failure modes. Writing down what an agent must avoid turned out to be more effective than writing down what it should do. "Never propose a trend wearing an evergreen costume" corrects behaviour that no amount of positive instruction reached.

And every agent has a hard scope boundary. Agents are helpful by disposition, which sounds good and is a genuine hazard. Left alone, an agent that finds a blocked task belonging to someone else will do that task, badly, and invent whatever status field it needs to record the fact. The instruction that fixed this is blunt: if the task is not yours, comment on it, escalate, and leave it exactly where it is. Being stuck and visible beats being unblocked by the wrong hands.

The nine stages

An article moves through nine stages, and only nine. The list is closed:

Idea → Angle → Research → Drafting → Editing → Visuals → SEO → Published → Repurposed

Each stage has exactly one owner, which is what makes a stuck article diagnosable at a glance:

The nine stages, their owning agents, and the three points where the chain stops and waits for me.

That the list is closed matters more than the list itself. I discovered this the hard way, watching the pipeline stall several times because an agent had hallucinated a status. Given room, agents invent intermediate states to describe their own progress: "research complete", "ready for review", "final pending". Each invention breaks every query written against the field, and the pipeline board becomes fiction. Every agent's instruction file now carries the exhaustive list of allowed values and an explicit instruction never to create another one. If an agent needs to record a nuance, it writes a comment; the status field is not its diary.

The part I did not automate

Images took the longest to stabilise, and the honest answer is that they are still not fully automatic.

Fully generative visuals failed on consistency. Ask a model for an image per article and you get eleven different visual identities across eleven articles, which reads as amateurish faster than a bad sentence does. Generation is also where an agent will happily produce something off-brand and confidently report success.

What works now is a two-part arrangement. I produce the images myself, either generating them with Gemini or OpenAI's image tools, or finding them online, and I curate them into a small public image bank hosted on Git. Public specifically so the agents can reach the raw files without any authentication step, which removes an entire class of failure. Every file name is an explicit description of the concept the image represents rather than an opaque identifier, so the bank is self-documenting.

The designer agent then does one narrow job: read the article's central argument, match it against the concepts in the bank, and pick one image, or two at most, or zero if nothing fits. Its instructions say plainly that no image beats a wrong image, and that matching must be conceptual rather than topical. It never generates, it selects, and it writes a placement specification for the assembly step.

On this link in the chain, the human supplies the raw material and the agent only chooses. I could probably automate it one day, but I spent days trying to get consistent output from image models and I still need three or four attempts before I get a picture I am willing to publish. That failure rate is far too high to sit inside an automation pipeline; every article would need me to come back and check anyway, which defeats the point. I stopped considering that a failure of automation. Selection is a judgement task with a bounded set of options, which agents do well; production of a consistent visual identity is not, and forcing it produced worse output than doing it myself once a month.

Where a human is still worth interrupting

Three approval points, and only three.

Gate 1, the angle. Before any research happens, I approve the direction. What I am approving is two things at once: the angle itself, and the article type the scout assigned to it (explainer, trend analysis, product review, contrarian piece, or narrative profile), because that type dictates the structural method the writer will follow later. This is the cheapest possible place to kill an article. Rejecting an angle costs one agent cycle; rejecting the same article after a research dossier and a two-thousand-word draft costs six.

Gate 2, the research dossier. Before writing begins, I read the sources, the data points, the counter-arguments and the open questions. This is the gate that protects factual quality, because everything downstream inherits whatever is in that dossier. If the evidence is thin, the article will be thin no matter how well it is written.

The side effect I had not anticipated is how much this step cuts hallucination. Ask an agent to write a finished article containing data and it will invent numbers, because producing a complete piece is the task and the figures are just material it needs. Give one agent a single job, finding and verifying sources, and the output becomes something I can trust; it has nothing else to optimise for, and its instructions tell it that an honest "I could not verify this" is a valid deliverable.

Gate 3, the finished article. I read the assembled piece, with its images in place, exactly as a reader would see it. Then it publishes, or it does not.

Three gates map onto the three ways an article goes wrong: wrong subject, weak evidence, poor execution. Adding a fourth would slow the chain without catching a fourth failure mode; removing any of the three lets a class of failure through to publication.

One implementation detail that cost me a rebuild. A gate is an approval field, never a pipeline stage. My first version encoded approvals as stages, and the result was predictable in hindsight: agents started setting articles to approval-flavoured statuses themselves to indicate they were finished, which quietly meant the machine was approving its own work. Now the stage says where the article is in production and the approval field says what I decided; only I write to the second one. An agent may set an approval field to "pending", meaning "presented for your review". Nothing an agent does can set it to approved.

Flow rules, and the WIP limits I removed

My first version had a work-in-progress limit per agent, borrowed straight from kanban. It was the wrong tool here and I removed it.

The problem is that a per-agent cap propagates backwards. One agent at its limit blocks whatever feeds it, which blocks the stage before that, and a chain designed to run at one article per week stalls because a single middle link is momentarily full. The limits were protecting against something real, but they were protecting at the wrong place.

Because there are really two opposite failures, and both are fatal to a blog.

The first is a continuous robotic flood: agents run, agents produce, and the blog receives four articles in a week, then nine the next. Readers notice the smell immediately, and any authority the blog had is gone.

The second is quieter and it kills more solo projects: a backlog swelling at the gates. Agents keep producing, work piles up waiting for my approval, and one Sunday I open the board, see fourteen articles awaiting review, and never open it again. A system whose queue grows faster than my attention is a system I will abandon within a month.

The fix is to constrain both ends and let the middle run free. At the entry, the idea backlog is hard-capped at ten. Every scout must count what is already there before adding anything, and if the backlog is at ten it adds nothing that cycle and retires stale ideas instead. At the exit, publication is throttled to a fixed monthly ceiling, enforced by the editorial director as the last checkpoint before the commit. In between, no limits at all: anything I have approved keeps moving.

Capping the input protects my review time. Capping the output protects the blog's rhythm. The middle of the chain is not where the problem was.

What it actually costs

Less than most people assume, and the number depends entirely on one choice.

I started with a cheap, fast model for the agents. Running the full ten-agent chain on something in the class of DeepSeek's fast models never cost me more than five dollars a month. That is the honest figure for a blog publishing one to two articles a week, ten agents, research included.

The other route, which is what I moved to, is to point Hermes at a model you already pay a flat monthly subscription for. Several providers now allow this outside of per-token API billing, including MiniMax and OpenAI. The arithmetic changes shape: instead of a bill that scales with output, you have a fixed line item you were probably already paying, and chances are this system will not max out the subscription you already have.

Everything else in the stack is free. The knowledge base is a personal Notion workspace. The repository and the image bank are free Git hosting. The site regenerates itself from the repo. There is no CMS licence, no SEO SaaS subscription, no stock photography account.

For comparison, commissioning a researched two-thousand-word article on a technical subject from a competent freelancer runs somewhere between two hundred and five hundred euros. And that assumes I could find one. Finding an SAP consultant is already hard; finding an SAP consultant turned professional writer, who knows FICO, module architecture and project management well enough to write about them without embarrassing me, is not a hiring problem I can solve at any price. Good luck with that search.

I am not claiming the machine matches a specialist writer who knows my field. I am saying the gap has narrowed enough that, for the article I would otherwise never have written because I had no evening free, the comparison is not against a freelancer's draft. It is against nothing at all.

What I would tell anyone building this

• Never trust an agent's self-report. Verify the artefact. Agents confabulate completion with total confidence, and a status field saying "done" is not evidence that anything was written. Check the blocks on the page, the word count in the file, the commit in the repo. Be ready for what that implies: checking becomes your main activity, even though you still drop your own ideas into the pipeline now and then. It feels thankless when you are used to building things, and it is the price of the arrangement.
• Governance goes on individual agents, not on the whole system. One global rule I added to fix one agent's behaviour froze a different agent entirely. Write the constraint into the instruction file of the agent that needs it.
• Close every enumerated field. Any status or category an agent can write to needs an exhaustive list of permitted values and an explicit ban on inventing new ones, or your queries silently stop matching reality.
• The human source of truth beats the elegant one. A board I can read on my phone caught more problems than any monitoring I could have built, because I actually look at it.
• Debug at scale in three moves: audit the full population first, fix the root cause, pilot the fix on exactly one item, verify it, then run the batch. Every time I skipped the pilot I multiplied a mistake by twelve.
• Automate selection, not taste. Agents choose well from a curated set of options and produce inconsistent output when asked to invent within an aesthetic. Keep the curation manual and the selection automatic.

Conclusion and next steps

The first weeks cost me a lot of hours. Building the agency, writing ten instruction files, discovering the failure modes one stall at a time; none of that was quick. What it costs me now is close to nothing, which is precisely why I had an evening free to write this article.

Running the agency takes about as long as reading two articles a week and adjusting them. Under an hour, most weeks.

That reclaimed time goes somewhere. I keep building products, Levee among them: a vibe-coded AI writing assistant I use when I want to write with my heart, still assisted, but with my hands on the keyboard.

The other direction is the more interesting one. Now that my blog produces high-quality articles on a steady rhythm, it has become a knowledge base on top of a publication. The next step is a second Paperclip agency whose agents take that content and turn it into social media posts. It markets my freelance profile while I am working, and it gives me a reason to talk to people in my field who are worth talking to.

If you want to build your own, I put the full specification into a 66-page kit: the architecture, the ten instruction files, a Notion template to duplicate, and a starter repository to fork. It is here.