A team of agents for all of marketing

Derrick’s marketing runs on a team of Claude agents: seven areas of work, each with written roles and rules, and each with a pilot that checks the output before anything goes out. I co-founded Derrick, a B2B data enrichment and prospecting tool used by more than 30,000 people, and I built this system. This chapter describes how it is organised, the rules that keep it honest, and what broke, with dates. The goal is that you can copy the parts that fit a smaller setup.

Seven levers, each with a pilot

We call each area a lever. Each one has its own instructions, its own agents and one pilot, an agent or a skill whose only job is to check what the lever produces.

Lever	What the agents do
SEO	Plan the week, write and improve pages, run bounded tests
LinkedIn	Draft the week’s posts in the founder’s voice
Video	Prepare video content
Analytics	Read the numbers the other levers depend on
Newsletter	Prepare the edition
Outbound	Source, enrich, write and push prospecting campaigns
Feature factory	Generate new data functions for the product

There was an eighth. A Reddit lever was started, then cancelled in October 2026. Stopping a lever is a valid outcome.

The LinkedIn lever has its own chapter, and the outbound lever became a published Claude Code plugin. Its flow is import (sourcing from an ICP, five possible paths), enrichment that stops at the first usable signal, a message written in the user’s voice, a sequence the agent recommends and the human builds in the sending tool, a push with a check so it never overwrites a lead already in an active campaign, and a weekly review that classifies replies with the quote and crosses them with the A/B variant and the type of signal.

Who decides and who executes

Inside the SEO lever, a Head of SEO agent plans the week and gives verdicts. Writer and optimiser agents produce and improve pages. An experimenter agent runs bounded tests, for example on 10 pages, and every test gets a dated verdict at four weeks. Nobody keeps a test running because it is “looking promising”.

Two technical rules shape this. The strongest model goes to the lead agent and the experts, where judgement matters. A small, fast model handles purely mechanical sub-tasks such as find and replace or searching files. And a sub-agent cannot spawn another sub-agent, so delegation is organised from the top: the lead agent splits the work, the sub-agents return results, nothing branches further down.

The layout below is simplified, not the literal tree, but it shows the principle that matters: a fact lives at the lowest level shared by everything that uses it, and higher levels point to it instead of copying it.

marketing/
  CLAUDE.md              # shared rules, points to the files below
  facts/product.md       # the only place prices and features live
  build-log.md
  levers/
    seo/
      CLAUDE.md          # SEO rules, points to facts/product.md
      experts/head-of-seo.md
      experts/experimenter.md
      tests/register.yaml
    linkedin/
      voice.md
      archetypes/

Product facts live in one file. A script checks that a feature exists before any content cites it, and counts (number of features, number of pages) are always computed, never typed by hand. A hard-coded count is correct the day you write it.

The rules that keep it honest

Most of the work went into rules. These are the ones I would keep if I had to start over:

Rule	Why
Every outgoing text passes a mechanical lint, then a judge in a blank context	Catches banned words, wrong prices and competitor names, then tone and claims
An agent never grades its own work	It will find its own output convincing
Frozen briefs are re-run after any change to a writer skill	A “small” instruction change can break three other cases
A weekly scorecard compares output and outcome	Pages shipped and traffic are two different numbers
A durable lesson is written into the expert’s instructions	A lesson in a ledger alone is forgotten by the next run
Agents read a digest of big files, with secrets and personal data removed	Raw CSVs and logs waste context and leak data
Routines check their tools first, and stop if one is missing	An improvised fallback produces confident garbage
A routine proposes; publishing or sending needs a written exception	The human stays on the button
Every notable build is logged with what, why and the lessons	The “why” is gone a month later

Two points about routines are easy to miss. Run every new routine once by hand: otherwise it can sit blocked on a permission prompt nobody sees and never run. And a frozen routine looks exactly like a resting one, so a script checks that each routine actually ran when it should have. Both are detailed in the routines chapter.

What broke along the way

This is the part I find most useful to share, because several of the rules above came from incidents like these.

Date	What happened	What changed
2026-11-05	One of the Head of SEO agent’s own exports counted only about a third of the real clicks, and a production stop had been decided on a false zero (details)	Check that totals match before combining two exports
2026-11-05	Replayed on the corrected data, one of three old verdicts turned out wrong, and a routine update had spoiled a test by touching pages under test	Declaring pages under test is useless if the routines do not read the declaration
2026-11-09	A data service passed its health check while every real query failed (details)	A health check must exercise the real path
2026-11-09	The whole agent organisation existed in one copy, on one laptop (details)	Backed up to a private repository, customer data excluded, push blocked if a secret appears
2026-11-10	A LinkedIn post said “filter, then enrich”, but the column’s play button also enriched, and billed, hidden rows (details)	Fixed in the product; any gesture a post promises is checked in the product first

A smaller one from 1 November 2026 belongs here too. A feature only appeared once its prerequisites were met, so most users never saw it. It is now always shown, with an explanation of what it needs.

The measurement incident is the one I would retell to anyone, because every chart looked plausible. Measuring what an agent brings in goes deeper on choosing instruments you can trust.

What to copy if you start smaller

You do not need seven levers. One lever with a pilot, a lint and a build log already gives you most of the benefit. The SEO results that came out of this system are in the Derrick case study.

A sensible order:

1. Pick the lever where the work is most repetitive and the output easiest to check.
2. Write the facts file and the banned list before the first prompt.
3. Add the lint, then the judge, then the frozen briefs.
4. Run the routine by hand, then on a schedule, proposing only.
5. Start the build log on day one, with what, why and the lesson.

Your next step: write down the one lever you would hand to agents first, the pilot that will check it, and the one number in your weekly scorecard that would tell you to stop it.