It Takes Them Days to Prepare a Campaign

A comms person told me that preparing a campaign takes days.

Not writing it. Preparing it. Deciding what the campaign is about, which messages matter, which channels carry which message, who approves what, and only then producing anything. The writing is the part everyone talks about, and it is not where the days go.

I have built enough AI tools to know the reflex that follows: point a model at the writing. I want to describe why I did not, what I found when I looked at the market first, and how that finding turned into an architecture with four agents in it instead of the ten I started with.

What already exists, and where each one stops

Before writing code I used Claude as a product manager and went through the category properly. The honest result is not the one a founder wants: the market is crowded. It is genuinely crowded, and most of the products are good.

Writing assistants generate a post from a prompt. They start after the decision about what to say has been made, which means they start after the days.

Social schedulers hold a calendar and publish on time. They assume the content already exists and someone already decided what belongs on which channel.

Brand voice tools keep the tone consistent. They operate on a draft you bring them.

Analytics products tell you what performed. They speak after everything is over, in a dashboard nobody feeds back into the next campaign.

Each one is competent at its slice. Line them up and the shape of the gap is obvious: the slices do not connect. A human carries the campaign from one to the next, re-explaining the context at every handoff, and the re-explaining is most of the days. Strategy lives in a doc, the calendar lives in a scheduler, the drafts live in a writing tool, the results live in analytics, and nothing that learns from the last campaign reaches the tool that starts the next one.

Nobody owns the line. That was the gap, and it is an unglamorous one, because building it means building four things that each already exist in better-funded versions elsewhere. The bet is that the connection is worth more than any single slice.

I know I believed that from the start, because it is written down. The first line of the plan file in my initial commit, November 2025:

End-to-end workflow combining multi-agent AI content generation with approval workflows and multi-channel publishing, something Jasper can't publish, and Sprout Social can't generate.

That sentence has aged well. Almost nothing else in that file did.

Strategy first, because that is where the days are

I did not design strategy-first, though I remembered it that way until I went back and read the file. The flow in that November plan was Brief → AI Generate (3 variants) → Review → Schedule/Publish. It starts at the brief, which is to say it starts after the days have already been spent. I had diagnosed the problem correctly in the value proposition at the top of the file and then designed for a different one twelve lines later.

Strategy became the first stage in August, nine months later, and it arrived as a bug report against my own product. The plan generator went straight from a campaign objective to finished content. It never read the strategy at all, and it left the human nowhere to disagree with the crew short of deleting pieces after the fact. Watching that, the missing stage was obvious: the decisions have to exist, and be editable, and be settled, before anything downstream derives from them.

So the first stage is strategy. Not a content brief. The actual decisions: what this campaign is for, the core messages, the audience, what success would look like.

The system produces a strategy, the human edits it, and then it locks. Locking is the part I would defend hardest. Everything downstream is derived from the strategy, and a strategy that can change quietly after the pieces exist gives you content that no longer matches the plan it came from, with nothing announcing the drift.

From there the line runs: the mix, where the crew proposes which pieces go on which channel and the human drops, adds, and retargets before anything is written. Then production, where the pieces actually get drafted. Then a retrospective that judges what happened against the strategy locked at the start, using the same numbers the campaign page shows.

Four stages, each one a place the human can stop. That is the pipeline the market was missing, and every architectural decision after this point is a consequence of wanting it.

And then, a year in, an audit of my own product found this:

Strong ends joined by a middle that leaked. Content silo'd away from campaigns, the human gate bypassable in one click, and the entire measure and adjust half write-only and invisible to every agent prompt. Arrows had been built as endpoints and pages rather than as connections.

I had built the market's disease into my own product. The campaign existed, the drafts existed, the metrics existed, and the connections between them were pages a human clicked rather than data any agent could read. The database schema supported a join from content to published post to performance snapshot, and no code anywhere walked it. The analyst could not see what had performed, so a replan was as uninformed as the first plan.

Believing the connections are the product does not build them. Endpoints are what you produce feature by feature, and each one demos well alone. The seam exists only if something crosses it: not whether the pages link, but whether the last stage's output reaches the first stage's prompt.

I started with too many agents

My first design had ten agents, and I can list them exactly, because they were files:

blog_writer_agent          press_release_writer
email_newsletter_agent     twitter_thread_agent
executive_quote_agent      linkedin_post_agent
content_strategist         content_brief_analyst
brand_voice_enforcer       seo_optimizer

It felt right at the time. Each one had a clean job description and a tidy prompt.

The plan file is more honest about where they came from than my memory was. Half the roster is annotated (reused), lifted wholesale from a previous project of mine, and the rest are marked (new) or (adapted), which means they were built to match the shape of the ones I already had. The architecture was not designed for this product. It was inherited, and then extended in the inherited style.

Read the left-hand column again, though. Six of the ten are one writer per format. That is not a division of labor. It is a lookup table wearing an architecture's clothes, and every entry in it exists because a model once needed to be told very specifically what a press release was and how it differs from a LinkedIn post.

Then the models got better, and the design stopped making sense.

The rest of the list is the same story told differently. A brand voice enforcer and an SEO optimizer are checkers that run after the writing, which is what you build when you do not trust the writing to come out right the first time. A content brief analyst is a pre-processor for the same reason. All of it was compensating for weakness, and those constraints softened underneath my architecture. A design built to route around a limitation becomes ceremony the moment the limitation lifts.

The ten went in with the very first commit, in November. They came out the following June, replaced by four: a strategist, a writer, an editor, and an analyst. One writer, not six, because format is an instruction now rather than a job. No enforcer and no optimizer, because a checker bolted onto the end is worse than an editor that reads the draft against a standard. Only the strategist survives the cut by name.

Four is not a compromise number. It is what remains when every agent that existed to work around model weakness is removed and every agent that exists for a structural reason stays.

Why they still need separate contexts

Here is where I expected to collapse further and could not. If four agents fit in one model's head, why not one agent and one long prompt?

I tried. The output got worse, and it got worse in a specific way: strategy reasoning bled into the copy. A model that had just worked through the campaign's messaging pillars would write drafts that sounded like they were still arguing for the strategy rather than executing it. Explaining and persuading leaked into text that was supposed to simply be the thing. In the other direction, once it was deep in copywriting, its strategic thinking got noticeably more decorative.

Separate contexts fixed it. The strategist sees the brief and the organization's memory. The writer sees the locked strategy and the piece it is writing, not the deliberation that produced the strategy. The editor sees the draft and the standard it is judged against, not the writer's reasoning about the draft.

So the pipeline is not a workflow diagram drawn for the reader's benefit. It is context isolation, and the stages exist because each one needs a different, deliberately narrow view. The handoffs between them are typed objects rather than prose, so what crosses each boundary is exactly what the next stage needs and nothing else.

The number of agents is a question about the model. The number of contexts is a question about the work.

That distinction is the one I would keep from the whole build. Model improvements collapse agents. They do not collapse contexts, because contexts are boundaries in the problem, not in the tool.

The build, which is the boring part

The crew runs on the Agent SDK. The frontend is Next.js, chosen for the least interesting reason available: I know it well. Claude's design skills did the site's visual design, and that part went almost exactly as advertised, which is the least I have to teach about it.

The whole thing runs on a single spot instance at six to eight dollars a month, with the database hosted elsewhere so the box holds no state and a reclaim costs a few minutes. None of that was the hard part. The hard parts were the pipeline's shape, what crosses each seam, and about a hundred and fifty commits of making the system honest about what it does and does not know. That is what the rest of this series covers.

I have written before that I wrote a plan and the work steered it. This is the sharper version of the same finding. The plan's diagnosis survived nine months and every one of its solutions was replaced: not the stack, not the agent roster, not even the order of the stages. What lasted was one sentence about a gap, written before any code existed.

The one-liner: the tools all worked, and the gap between them was the product.

This is the first of a series on building an agent-assisted communications platform. The rest, the orchestration layer, the memory system, the deploy path, and ten more, are written up as architecture docs at commscrew.ai/docs/architecture.

The views expressed here are my own and are not related to or reflective of my work or any organization I am affiliated with.