Build the Content Company from Scratch with Paperclip AI

Last post was the map. This is the territory.

The Content Company was one of five patterns I sketched in Paperclip Lets You Build an AI Company. This post is the full build: actual config, role by role, with the delegation chain wired and the failure modes documented. If you want something you can fork and run this week, this is that post.

The Content Company takes a topic and a target audience. It produces a polished draft. Five agents do the work — Orchestrator, Strategist, Researcher, Writer, Editor. The structure is not complicated. The details are.

The chain is simple. The thing that took me three attempts to get right is how the brief travels through it. Everything else — the prompts, the tools, the model choices — matters a lot less than getting that one thing right.

The first version was a sequential pipeline pretending to be a company. Each role passed its output to the next as a message. The Researcher got the Strategist's brief as text. The Writer got the Researcher's findings plus the brief. The Editor got the draft.

The Editor's system prompt said something like: review the draft and improve it.

It improved the draft. It also improved it away from what the Strategist had decided. The Editor had taste; it had no north star.

Here's what drift actually looked like in practice. The Strategist produced this angle:

> Most developers reach for a pipeline when they need an organization. The failure mode isn't technical — it's structural. No amount of prompt engineering fixes a coordination problem.

By the time the Editor evaluated the draft, its implicit north star had become something like:

> Agent pipelines have technical limitations that better architecture can address.

Same topic. Different claim. The first is arguable and specific. The second is vague enough to be inarguable — and therefore useless. The writing was cleaner. The piece was worse.

What broke: the Editor evaluating against its own taste instead of the brief.

The fix seemed obvious: include the brief in every downstream message. Researcher, Writer, Editor — each one gets the original brief prepended to their input.

This worked better. The Editor now had the brief. But by step four, it was evaluating against a shadow of it.

Each agent had handled the brief as a conversational input. The Researcher referenced it. The Writer paraphrased its success criteria while drafting ("this piece should help engineers understand structural failure modes"). The Editor received both the brief and the Writer's paraphrase and, when they differed, unconsciously deferred to the more recent interpretation.

The Strategist's original success criterion had been:

> The reader should finish the piece able to name one specific structural failure mode they have experienced and explain why it was organizational, not technical.

By the Editor's pass, this had softened to:

> The piece should be informative about agent architecture.

I didn't catch this until I ran three sessions back to back and compared the Editor's notes against the original brief. The Editor was flagging things the Strategist hadn't asked for and ignoring things it had.

What broke: treating the brief as a message to be passed, not a persistent object to be injected fresh at every step.

The fix is architectural, not prompt-level. The brief doesn't travel through the chain as a conversational message. Every agent after the Strategist has the brief injected into its context independently — pulled directly from the Orchestrator's store, not forwarded from the previous step.

The chain still passes work products (research packet, draft). The brief is always fresh, always the Strategist's original language, always the same document that every agent is accountable to.

That's the version that works. Here's how to build it.