I set out to build a handful of AI agents to run Soundtrak's marketing and sales. Somewhere in the build I stopped, looked at what was actually sitting on my disk, and realised the agents were the smallest part of it. The real thing was everything around them. Here is where I started, where I ended, and what it taught me.

Where I started

I started the way anyone reaching for AI starts. I opened Claude.ai and I built agents. One to run a campaign, one to write the copy, one to sign it off. When something was not good enough my fix was to make the agent cleverer with a sharper prompt or a better example to copy. I had a library of agents that was growing, and sometimes I would stitch them together in a workflow, but it had problems.

There were several challenges stopping me from the real productivity that AI promises.

The first was the chat box itself. I was asking Claude.ai to produce a full go-to-market campaign, a strategy, a customer insight, three creative concepts, a plan, and dozens of finished assets. All of it came back as a wall of chat, .md files and the occasional HTML render. For projects of this size, it becomes near impossible to review the firehose of data an AI produces by scrolling a transcript. There is too much of it, moving too fast, and reading it all properly takes longer than doing the work yourself. The chat box was a fine place to talk to the machine. It was a hopeless place to review the output of the machine.

The second was the shape of the output. A single-shot output, from a single or a handful of chat inputs, was not giving me the output I needed. One prompt to a finished campaign sounds like the dream, and it demos beautifully, but a campaign is not one decision. It is a strategy call, then an insight call, then a creative call, then dozens of copy and design calls stacked on each other. When the whole run lands finished in one shot, you cannot steer it, evolve it as new information arrives, or pivot when you have got something not quite correct. You get handed the last thing in a chain you never watched being built, and there is little way to determine the cause and effect for the output. Did the insight generate a poor key message, or was it the creative brief, or was it the production itself?

The third was the agents themselves. I had a library of them, way too many, overlapping in role. Two agents that both wrote copy. Three that all thought they owned review. I would ask for a task and the output sometimes looked like they had been squabbling, direction lost, the asset a mess. The lesson from the edition before this one was that fewer, clearer agents beat more clever ones.

Put together I had a group of competing agents, I could not review the firehose of data that was being created, and no ability to understand cause and effect. The answer was not another agent, nor a better workflow. The answer was to build the thing the agents were meant to sit on, the system.

Where I ended

What I built is a system of agents, best-practices, tools, loops and evaluations, stage-gates, HTML operating surfaces, audit and version control via a GitHub repo. All designed to maximise the role AI plays, whilst truly keeping the human in the loop. Specifically designed for marketers building GTM campaigns and assets.

It looks nothing like a chat, or a workflow, and building trustworthy agents was the smallest part of the design.

Yes there are the agents, seven of them, each with one clear role and no overlap. There are the tools they call to help them do the work, generate a visual, render a page, run a sub-edit, publish to a specific channel, so the agent decides which tool to use. This also helps with the limitations of the context window size by not calling information unless it is needed. There are the evals, the checks that grade an output before a human ever sees it, so a poorly written piece of copy or an off-brand tile or a blacklisted term is caught by the system and not by me. There are reference files the agents read at decision time, so frameworks and best practices are referenced where the work happens and don't just stay in my head. And there are the HTML operator surfaces, not .md files, designed to help the actual review. The campaign dashboard, a campaign styleguide or moodboard, the campaign plan, the asset gallery, the review cards, each one a purpose-built HTML page that turns a wall of output into something a person can review.

The Soundtrak Campaign Dashboard for a live campaign: on the left, the Campaign DNA and a Phases and Artifacts table listing each phase with its status, window, human time and AI cost; on the right, the To Do list of decisions waiting at each gate.

The Campaign Dashboard, one of those HTML operator surfaces. The Phases and Artifacts table lays out the gates the work passes through; the To Do list on the right is the decisions still waiting at each gate. The real screen, not a mockup.

And then there are the phases. This is the part I had most underrated. The work does not run in one shot any more. It passes through gates, a brief gate where the campaign manager 'grills' the human in the loop to determine why they are really running the campaign. A creative design gate where the creative design agent uses customer insights and divergent/convergent thinking to come up with a creative direction. A campaign plan gate, an asset gate, a rollout gate, ending with a campaign reporting gate. Each gate or phase is a place where the AI work stops and waits for a decision (by the human-in-the-loop) before it continues. The phases are what solved the single-shot problem. I am no longer judging the last link in an unwatched chain, instead I steer the campaign at every gate, and I can evolve or pivot at any one of them.

I also realised I was building the system whilst rolling out a campaign. I would find a bug, look to improve the HTML interface, add a best-practice, or improve the briefing process. So I built a retrospective in the system, where the system files tickets on its own faults. When the AI hits a rough edge mid-build, a missing rule, a surface that reads wrong to a human, an argument two agents keep having, it does not get lost mid chat and forgotten when the session ends. It gets raised as an enhancement ticket, dropped in a backlog for me to triage later, deliberately kept apart from the campaign it interrupted. The machine notices its own faults and queues them.

There is more, version controlling via a GitHub repository rather than a local drive that could be misplaced, lowering the reliance on memory files that change over time, deterministic rules when they mattered, using a shared store, creating an audit history, but that is for another edition of The Debrief.

What it taught me

My unit of thinking has moved from an agent and a workflow, to an engineered AI system. I stopped asking "what should this agent do?" and started asking "what does the system need to do?"

I started with the outcome, the process I wanted to build and then back-filled the AI system. I wanted to build better, faster, scalable GTM campaigns. It didn't start with I need more agents, a better prompt, a tighter role, or cleverer instruction.

So here is the lesson, laid plain. If you are wiring AI into your own go-to-market, build a system, not a library of agents. The agents are the part everyone reaches for first, because they are easy (every AI marketing consultant is offering them up for free). The real game is everything around them, and above all in the phases they must pass through.

An AI chat works beautifully right up until the session closes and takes its context with it. A system you can steer at every gate, wind back when you are wrong, and trust to run when you are not watching.

The evidence