The Agent Roster: How One Person Runs A Marketing Department With Specialist AI Agents

I used to run my marketing out of one long chat thread. Research, draft, edit, self review, publish, all in the same context, all with the same model wearing five different hats in a row. It worked, technically, the way a level one character can still clear the tutorial: badly, and only because nothing was trying very hard yet. It produced the exact flavor of AI content everyone can spot on sight: confident, generic, and reviewed by nobody but the thing that wrote it.

The fix was a department. I split the work into narrow agents that each do one job, gave every agent a written charter, and put a read only critic between every draft and the outside world. It is a pattern borrowed straight from how a real marketing team is structured: someone researches, someone writes, someone reviews, and the reviewer never also holds the pen.

Why one agent doing everything fails quietly

Self review is lenient by nature. A person grading their own homework goes easy on it without even noticing, and a model doing the same thing inherits the same blind spot: whatever it just wrote sounds right to the part of it that is now reviewing it. The only way I have found to kill that leniency is to make the reviewer a different agent, with a different job, that never gets credit for the writing being good. It only gets credit for catching what is wrong.

The second failure is scope creep inside a single thread. Ask one chat to research, write, and judge its own claims for compliance risk, and it will happily do all three badly rather than any one well, because nothing in the conversation tells it where its job ends. A written charter fixes that, the same way a real employee's job description does: it makes it obvious what is and is not theirs to decide.

The pattern: critics never touch the pen

Every department I run splits into two kinds of agent. Executors produce something: research, a draft, a design. Critics review something and are not allowed to fix it themselves. A critic returns a verdict, a score, and a list of located problems with a suggested fix each, then hands it back. It never edits the file. That one rule is what keeps the review honest, because the moment a critic can also patch the thing it is grading, it starts grading its own patch.

It is a structural problem, not a trust problem with the model. Give any reviewer edit access and the fastest path to a clean looking result is to quietly fix the small stuff instead of flagging it, which erases the paper trail of what was actually wrong. You have built a boss with infinite HP that also holds the potion, and it will use it on itself every single time. Read only access forces every finding into the open.

Three starter agents you can copy

Below are three charters adapted from the ones I actually run: a critic, a researcher, and a writer. They are templates, not drop-in code for any one tool. Copy the shape and translate it into whatever your framework expects: a markdown agent file with YAML frontmatter, a JSON tool definition, a system prompt block, whatever your setup uses. The critic below is written in the actual frontmatter shape so you can see exactly what that translation looks like and paste it straight into a compatible agent file.

1. The critic (read only, blocking; ready to paste as an agent file)

--- name: content-critic description: Independent read only critic that reviews marketing drafts for clarity, accuracy, and brand fit. Returns a score, located findings, and one fix per issue. Never rewrites, never publishes. model: [pin the exact model your tool uses, written out, never left on "default"] tools: read files, search files (no write, no edit, no send) --- You are a strict, fair critic of marketing copy. You never rewrite. You return a verdict, a score, and a list of findings, each with a location, the problem, and a fix. ## Charter reviews: drafts, ad copy, landing page copy, email copy never: rewrites the piece, ships the piece, invents an issue it cannot point to refuses: strategy calls, pricing calls, legal risk calls (route those to a human) stance: review every piece as if a stranger wrote it, no self review leniency ## Output contract verdict: PASS or BLOCK score: 0 to 100 findings: list of location, issue, fix routed_out_of_lane: anything outside this charter, named and handed off

• Why critics never rewrite: the moment a reviewer can patch the file, small problems get quietly fixed instead of flagged, and you lose the record of what was actually wrong. Read only access forces every finding into a list a human can see.
• Why the charter names a refusal list: without an explicit "refuses" line, a critic will happily rule on legal risk or pricing because nothing told it that was out of bounds. Naming what it must not touch is what keeps the lane narrow.
• The routed_out_of_lane field matters as much as the findings: it is the critic saying "I saw something, it is not mine to judge, here is who should look" instead of either ignoring it or overstepping.

2. The researcher (read only, no fabrication)

name: market-researcher role: read only research and synthesis model: [pin one model explicitly] tools: read files, web search, web fetch (no write, no send) charter: gathers: real, current, sourced information only cites: every number and every named claim with its source and the date it was checked never: fabricates a statistic, a quote, or a source when_no_data: says "no data found," never guesses a plausible sounding number hands_off: findings only, does not draft copy, does not decide strategy output_contract: findings: list of claim, source, date checked gaps: anything that could not be verified, named plainly confidence: a 1 to 10 rating on each claim

• Why the "never fabricates" line is load bearing: a research agent under a deadline will smooth over a gap with a plausible number if nothing stops it. "No data found" has to be an explicitly acceptable answer in the charter, or the agent will quietly prefer a wrong answer to an honest gap.
• Confidence ratings per claim, not per report: a research output that is 90 percent solid and 10 percent shaky reads as entirely solid if you only score the whole thing. Rating each claim separately is what lets a human spot the one line that needs a second look.

3. The writer (executor, drafts only)

name: content-writer role: drafts copy from research and brand voice model: [pin one model explicitly] tools: read files, write files, edit files (no send, no publish, no deploy) charter: drafts_from: approved research plus the brand voice file, never memory alone keeps: every source the researcher supplied attached to the draft never: publishes, sends, or deploys anything itself hands_off: the draft goes to the critic agent before any human reads it output_contract: draft: the piece itself sources_used: list of everything cited self_flagged_uncertainty: any claim the writer is not fully sure of

• Why every agent gets an explicit model pin, not "whatever is default": a default drifts under you the moment your provider ships a new one, and a premium reasoning model on a routine drafting job burns budget for nothing. Pin the model per agent, on purpose, and change it on purpose.
• Why the writer cannot publish: giving the drafting agent a send or deploy tool collapses the whole department back into one agent doing everything, just with extra steps. The write tool stops at the file. A human, or a separate publish step, decides what goes live.
• self_flagged_uncertainty exists because a writer that sounds confident about everything is lying about something: forcing it to name its own weak spots gives the critic a head start instead of starting from zero.

How the three connect

The researcher gathers and cites. The writer drafts from that research plus a brand voice file, never from its own memory of what sounds right. The critic reviews the draft and can only block it or pass it, never touch it. A human reads the critic's verdict, not the raw draft, before anything goes anywhere near a customer. That is the whole department: three narrow jobs, one direction of handoff, and exactly one place where a human has to look before it ships.

It requires writing down, in plain language, what each agent is allowed to do and what it must refuse, then actually enforcing the tool limits so it cannot cheat on its own charter. No large team, no complicated framework. That is the part most setups skip, and it is the part that makes the difference between an agent roster and one chat window with extra steps.