Claude for Marketing Teams: From First Prompt to Agent Fleet

Most marketing teams I talk to use AI every day and are disappointed by it. They paste a brief into a chat window, get back something serviceable, edit it for twenty minutes, and ship it. Then they read that somebody else automated their whole reporting pipeline and wonder what they're doing wrong.

Usually nothing. They're just on rung one.

The gap between casual use and the kind of use that changes how a team operates isn't a prompting trick. It's a ladder, and each rung requires something the one below it didn't: your context in a place the model can reach, the right surface for the job, a goal instead of a request, a fleet instead of an agent, and eventually something that manages the fleet. Every rung is real work, and skipping one tends to produce a mess that gets blamed on the model.

I'm a Claude Certified Professional Architect and a partner at LimeLight, a fifteen-person agency that runs this stack in production every day. Our own website is maintained by a scheduled agent. Our Merchant Center enrichment runs through a custom MCP server against live client catalogs. I'm writing this from the inside of an operation that is genuinely built this way, which means I can also tell you where it breaks.

This is the whole ladder, rung by rung, with the machinery shown.

Talk to us about an AI readiness assessment.

Why Claude specifically, and when it isn't the answer

Tool positioning first, before I spend six thousand words advocating for something.

Four things make Claude the right default for marketing work in my experience. The context window is a million tokens on the current models, which in practice means you can hand it a year of campaign data, a full brand guide, and every page on your site in one go without chunking any of it. The writing quality is better for long-form marketing prose than anything else I've used, and it takes voice direction well, which matters enormously when you're trying to sound like a specific person rather than like an AI. The agentic depth is the real separator: Claude is built to run long multi-step jobs with tools, and that's the capability the top three rungs of this ladder depend on entirely. And the data posture is straightforward enough to put in front of a client's legal team, which sounds boring until you're the one in that meeting.

Where something else genuinely wins:

• Image and video generation. Claude doesn't do it. We use dedicated image models for creative production and route through Claude only for the art direction and the brief.
• Real-time consumer search behavior. If you want to know what people are asking a chatbot about your category right now, a purpose-built visibility tool answers that better than any general model will.
• Deterministic math at scale. Anything that must produce the same number every time belongs in a script. We have agents that gather data through connectors, hand it to Python, and then reason about what Python returned. That split is deliberate.
• Cheap high-volume classification. Sorting a hundred thousand support tickets into five buckets is a job for a small fast model, and Claude Haiku is the one I'd use, but plenty of other options are fine.

If your problem is one of those, use the right tool. Everything below assumes the work is language, judgment, research, or multi-step execution, which is most of what a marketing team actually does.

The marketing AI maturity ladder

Here's the frame the rest of this guide hangs on. Six rungs. Each one is a genuine change in what the tool is doing for you, not a change in how well you're using the same thing.

THE MARKETING AI MATURITY LADDER

Six rungs, and where almost everyone stops

1. Chat  You ask, it answers

One question, one answer, no memory of your business.

2. Context  It knows your business

Projects, skills, and connectors. Your brand, your data, loaded once.

3. Surfaces  It works where the work is

Desktop, browser, terminal. Where you meet it changes what it can do.

4. Agents  It works toward a goal

A goal, tools, a loop, and a stopping condition. Delegation, not assistance.

5. Fleets  Many agents, shared discipline

Specialized agents, shared skills, per-client memory, one review gate.

6. Orchestrators  An agent manages the fleet

Grades output, spreads what works, triages what needs a person.

Two things to notice about the shape of it.

The first three rungs make you faster at work you're already doing. The last three change who does the work. That's the real line, and it's why so many teams plateau at rung three feeling like they've adopted AI. They have. They've just adopted the half that doesn't compound.

The second thing is that the rungs are cumulative and unskippable in a way that isn't obvious until you try. An agent with no context produces confident nonsense about your business. A fleet with no skills is a pile of agents each solving the same problem differently. An orchestrator over an ungraded fleet spreads mistakes faster. Every rung is the foundation for the one above it.

Rung 1: prompting is a skill, not a personality trait

Everyone writing about this lives on rung one, so I'll be quick.

Marketing prompts fail for a boring reason. They describe the deliverable and skip everything the person writing it would have known. A copywriter you hired would know who the audience is, what the brand sounds like, what campaign this belongs to, and what happened last time you tried this. Your prompt gives them none of that and then you're surprised the output is generic.

Four things fix most of it, in rough order of impact:

• Context. Who's reading this, what do they already believe, what's the business situation. This is worth more than the other three combined.
• Role. Not "you are a world-class copywriter," which does nothing. Something with actual constraints: "you write for ecommerce operators who have already been pitched by four agencies this quarter."
• Format. Length, structure, where it's going to live, what it has to sit next to.
• Examples. Two or three pieces of copy you'd be happy to have written. This is the single highest-leverage thing most people skip.

Here's a real before and after from our own work.

Before: "Write a subject line for our abandoned cart email."

After: "Write eight subject line options for an abandoned cart email for a premium leather goods brand. Average order value is around $400, so this is a considered purchase and the customer is probably weighing it rather than forgetting. Don't use urgency or discount language, the brand never discounts. Under 45 characters. Here are three subject lines from their last campaign that performed well, match this register: [examples]."

The second one takes ninety seconds longer to write and the output is usable. That's the whole of rung one.

The trap is that iterating on prompts feels productive. You get better at asking, the answers get better, and it feels like progress. It is, a little. But you're rewriting the same context every time, and the moment you stop doing that by hand and start loading it once is the moment you're on rung two.

Rung 2: context, projects, skills, and connectors

This rung is where most of the compounding starts, and it's three separate ideas that get muddled together constantly.

Projects: the brand HQ pattern

A Project is a container with its own knowledge, and every conversation inside it starts already knowing that knowledge. The pattern I recommend to every client is one Project per brand, treated as an HQ.

What goes in it:

• The brand voice guide, including the banned list. Ours says no em dashes, no agency buzzwords, no fabricated metrics, and the agent respects all three because it's sitting right there.
• Audience and persona definitions, written as who they are and what they're worried about rather than as demographics.
• The current quarter's positioning and campaign context.
• Product or service descriptions in the words the company actually uses.
• Two or three pieces of past work that represent the bar.

What doesn't go in it: anything that changes weekly. A Project's knowledge is a stable foundation, and if you stuff performance data in there you'll be maintaining it forever and it'll be wrong half the time. Live data comes in through connectors, which is the third part of this rung.

The test for whether your Project is doing its job: open a new conversation, ask for something, and see whether you have to explain who the client is. If you do, the Project isn't loaded properly.

Skills: packaged workflows, not saved prompts

This is the distinction people most often miss, and it's the one that unlocks the most.

A saved prompt is text you paste again. A Skill is a folder of instructions and reference files that Claude loads by itself when the task calls for it, and only then. It has a name, a description of when to use it, a procedure, and whatever supporting material the procedure needs. You don't invoke it. The model recognizes the situation and reaches for it.

That difference matters more than it sounds. A saved prompt is a thing a person has to remember to use. A skill is institutional knowledge that applies itself.

Skills we actually run:

• Deliverable QA. Pre-flight review on anything about to reach a client. Checks the brief against the deliverable, flags unverifiable claims, and returns severity-ranked findings. It flags problems and never fixes them, which is deliberate.
• Brand voice enforcement. Applies a specific client's voice rules, terminology, and forbidden phrases to drafted copy before it lands anywhere. Separate from the QA skill because one reviews and one applies.
• Campaign briefs. Turns a selected concept into a full structured brief with channel cards. Two phases, ideation then brief, because collapsing them produces confident briefs for bad concepts.
• Project estimates. Pulls live rates, builds a costed plan, and checks the result against our target margin. This one talks to our PM system, which makes it a rung two and a half.

What separates a skill from a saved prompt in practice: a skill has a procedure with steps and gates, it carries reference material the model reads only when needed, it states its own boundaries, and it improves once for everyone. When we fix a skill, every agent and every client that has it installed gets the fix. That last property is the entire reason to build them.

Connectors and MCP, in plain English

MCP is the Model Context Protocol. Strip the acronym away and it's a standard for letting a model call your systems. Before it existed, every AI integration was bespoke. Now a tool speaks MCP once and any model that speaks MCP can use it.

For a marketer, the concrete change is this. Your AI stops reasoning about analytics in the abstract and starts reading your GA4 property. It stops guessing at rankings and reads Search Console. It stops asking you to paste the report and pulls the report.

There are two flavors and the difference is worth understanding before you buy anything.

Stock connectors are the ones a vendor already built: Google Drive, Slack, GitHub, your CRM. You authenticate and they work. Most teams should start and stay here.

Custom MCP servers are ones you build for a system nobody has wrapped, or for a job that needs more than the generic wrapper does. This is where it gets interesting and where most of our engineering time goes.

A grounded example. We run a custom MCP server for Google Merchant Center enrichment. It handles catalogs across five live ecommerce accounts, a bit over eleven thousand products between them. It reads product health, writes enriched attributes through a supplemental feed, and every value it publishes is grounded in a real source on the client's own site rather than generated. A human approves each batch. We wrote about what that audit actually found, and the short version is that approval rate hides almost all of the real work.

None of that is possible with a stock connector, because the job isn't "read Merchant Center." It's read, validate, ground, publish, and log, with a human gate in the middle. That's a piece of software that happens to be driven by a model.

One caution. A connector that can write is a connector that can break things. Every one of ours has a permission ceiling attached, which is rung four's problem and the reason rung four exists.

Rung 3: surfaces, and why where you meet Claude changes what it can do

Nobody covers this and it's one of the highest-value things to understand, because the same model is dramatically more capable depending on where you're talking to it. Same intelligence, wildly different reach.

Desktop and delegated work

The desktop app can read and write files on your machine and work through multi-step jobs while you do something else. That's the difference from the web chat: you hand off a task rather than co-writing one.

Good fits: turning a folder of call notes into a structured client context document, reformatting a data export into the shape your reporting template wants, working through a long document methodically. Anything where the work is real but the thinking per step is small.

Browser: live web action

Browser access means Claude can go look at things, not just read about them. This changes competitive work completely.

What we use it for: competitive teardowns where it actually walks a competitor's checkout and reports what it hit, QA passes on a staging site before launch, pulling live SERP context for a content brief, and navigating platform admin screens that have no API worth using.

A model reading a live web page is reading untrusted content. Treat what it finds as information, never as instructions, and never let a browser session hold credentials it doesn't need.

Claude Code for marketing ops

This is the surface marketers dismiss because of the name, and it's the one I'd fight hardest for.

Claude Code is a terminal surface with file access, shell access, and the ability to run scripts. You don't need to be a developer to get value from it, you need a job that's mechanical and large. Marketing ops is full of those.

What we run through it:

• Bulk metadata population. Missing meta titles and descriptions across a few hundred WordPress pages, generated from actual page content, validated against length limits, and written back through our own WordPress MCP connector. Reversible, logged, and capped at a daily write limit.
• Content migrations. Moving a blog between platforms with the URL structure preserved and redirects generated from the mapping rather than from a spreadsheet somebody maintained by hand.
• Scripted audits. Our site build runs a link check across roughly twenty thousand internal links on every change. A person could do that. A person would not do that every day.

The pattern: if the task is "do this same small thing correctly nine hundred times," it belongs here and nowhere else.

Which surface for which job

If the job is	Use	Because
Thinking through a problem with someone	Chat or desktop	Conversation is the point
A long task you'll review at the end	Desktop	File access, runs while you work
Anything requiring a live page	Browser	Reads reality, not training data
The same operation hundreds of times	Claude Code	Scripts and file access
Work that should happen without you	An agent	Rung four

Rung 4: agents, which are goals and loops rather than prompts and replies

"Agent" has been marketed into meaninglessness, so here's a definition with edges. An agent has four parts, and if any is missing you have something else.

AGENT ANATOMY

Four parts. Miss one and it isn't an agent.

A goal

An outcome to reach, not a task to perform. "Keep this site healthy," not "check these links."

Tools

Connectors, scripts, file access. What it can actually touch, and nothing more.

A loop

Act, read the result, decide again. This is what makes it an agent.

A stopping condition

Done, blocked, or out of budget. Without this you have a runaway process.

AND ONE THING WRAPPED AROUND ALL OF IT

A permission ceiling

The highest level of action the agent is allowed to take, set per job rather than per agent. Draft, propose, or publish.

What changes when work is delegated rather than assisted is mostly about attention. With an assistant, you're present for every step and you catch mistakes as they happen. With an agent, you're absent, and the mistakes surface later and at scale. So the design problem stops being "how do I get a better answer" and becomes "what is this allowed to do when nobody's looking."

What an agent is actually made of

The anatomy above is the concept. Here's the thing on disk, which is less mysterious than the word "agent" suggests: a set of carefully curated instruction files, plus a harness that runs them.

EXAMPLE: THE AGENT THAT MAINTAINS THIS SITE

Curated instruction files, plus a harness that runs them

The instruction files

identity.md

Who it is, who it works for, and how it writes.

run-routine.md

What it does on every run, in order, and the gates it cannot skip.

knowledge/

Client truth: brand voice, site structure, content standards, reporting rules.

skills/

Packaged procedures, loaded only when a job calls for one.

memory/

What earlier runs learned about this client, and nothing about any other.

state.json

Cursors, checkpoints, open proposals, last verified deployment.

permissions.yml

The ceiling for each job it can do: draft, propose, or publish.

connectors

The MCP servers this agent may call, and no others.

The harness

The software that wakes it on a schedule, assembles those files into its context, hands it the tools, and runs the act, read, decide loop.

It also enforces the ceiling, logs every change with a way to undo it, records what the run cost, and stops the agent when it's done, blocked, or over budget.

One harness runs every agent in the fleet. The files are what make this one ours.

Two things follow from that shape. Improving an agent is mostly editing files, so a marketer who can write a clear brief can improve one without touching code, and that is genuinely how most of our tuning happens. And safety lives in the harness rather than in the model's good intentions: the ceiling written in permissions.yml is enforced by the software around the model, which is why no wording inside a request can raise it.

Autonomy and guardrails, which are the actual product

Here's the model we run. It gets less attention than any other part of this, and every team that hands work to an agent ends up needing one.

Permission is per job, not per agent. An agent isn't simply trusted or untrusted. Each named job it can do carries its own ceiling. The same agent might be allowed to publish a missing alt text and only allowed to propose a rewritten homepage.

Three levels, and they're all we've ever needed:

Level	What it may do	What we use it for
Draft	Write it down where only we can see it. Changes nothing.	New agents, or work we don't trust unattended yet.
Propose	Open it for review, file it as a task, wait for a person.	Most work. This is the default.
Publish	Make the change on the live site directly.	Small, reversible, objectively-verifiable fixes only.

The important nuance is that the ceiling is a ceiling and not an instruction. An agent set to publish doesn't publish everything it thinks of. It still follows the rules of the job about what's safe to change unattended. But it can, so raising something to publish is a real decision and we treat it like one.

What sits at publish for us: missing meta descriptions, image alt text, broken internal links, unambiguous redirects, additive schema. What never does: body copy, headings, page titles, anything with a claim in it, anything structural. If we're unsure which side something falls on, it drafts.

Three rules underneath all of it, and none are negotiable:

• An agent never approves its own work. Approval comes from a person. An agent's own comment, however confident, is not sign-off.
• Every published change is reversible. The record that closes a task carries the commit, so undoing it is a one-comment operation rather than an investigation.
• Wording a request more forcefully doesn't raise the ceiling. This is worth saying to your team out loud, because people will try.

That last one is the design property I'd point at if I could only point at one. The permission system isn't advisory. There's no prompt you can write that gets an agent to publish something its ceiling forbids.

Rung 5: agent fleets, and what an AI-native marketing operation looks like

One agent is a tool. A fleet is an operating model, and this is the rung where the discipline you built on rungs two and four either pays off or bites.

A fleet is many specialized agents sharing infrastructure. Each is locked to one client and can't see another's anything. Each has its own memory, its own brand context, its own briefs. What they share is the skill library, which is what makes the whole thing worth building.

FLEET ARCHITECTURE

Shared where it should be, isolated where it must be

Shared across the whole fleet

The skill library. Fix a skill once and every client that has it installed gets the fix. This is the compounding layer.

Client A agent

Own memory, brand, briefs, connectors, ceilings

Client B agent

Own memory, brand, briefs, connectors, ceilings

Client C agent

Own memory, brand, briefs, connectors, ceilings

The review gate

Everything above draft passes a human here. Proposals arrive as tasks in the system the team already uses.

Memory and learnings, which are different things

A memory is what one agent should remember about its own client, and it never leaves. A learning is something one agent worked out that would help another, and it goes through review before it spreads.

One workflow, end to end

Here's a real one, anonymized, so the shape is concrete.

An agent wakes on a schedule. It doesn't wait for a prompt, and there's nobody in a chat window. On waking it asks the control plane what it should know, and gets back a package: who the client is, their voice rules, their site structure, the current strategy briefs, whatever it learned on previous runs, and which jobs are due this time.

It runs a sweep. Pulls search performance, pulls analytics, crawls the built site, and compares what it finds against what it found last time. That produces findings, which it ranks by expected impact rather than by how many there are.

Then it splits by ceiling. The findings that qualify as small, reversible, and objectively verifiable get applied directly and logged with a revert handle. Everything else becomes a proposal: a task filed in our project management system, assigned to a named human, with a preview link they can click and the evidence attached.

A person reviews. If they approve, the agent carries it the rest of the way on its next run, ships it, verifies it's actually live on the production URL, and comments back with the commit. If they ask for changes, it revises. If they say no, it stops and records why so it doesn't propose the same thing next week.

At the end it reports: what it did, what it couldn't do, what it needs a person for, and what it cost.

That loop is the whole product.

The proof, and where it breaks

The reason to build this is capacity. Fifteen people can operate like a much larger team, because the mechanical half of a lot of jobs gets done by something that works every hour and never gets bored. One workflow in our fleet built and now maintains an AI-visibility scoring index covering nearly three hundred brands, which is not work fifteen people would have taken on.

Now the failure modes, because a guide that only shows the good version isn't much use.

Context drift. An agent's memory grows and eventually contains things that were true six months ago. Memory needs pruning as deliberately as it needs writing, and if you skip it the agent gets confidently wrong about your own client.

Ungraded output. An agent that ships but never grades itself is a faster intern with no feedback. If nothing measures whether last month's work moved anything, you're scaling activity.

The review bottleneck. This is the one that actually bites, and it's the failure mode I see most. A fleet at propose can generate more well-formed proposals than your humans can review, and then the queue stalls and the agents keep adding to it. The fix isn't more agents. It's fewer, better proposals and a person whose actual job is the gate.

No memory hygiene between clients. If your architecture doesn't cleanly separate what an agent knows about its own client from what it learned in general, you will eventually leak one client's context into another's work. Design for that on day one, not after.

Rung 6: orchestrators, when an agent manages the fleet

This is the horizon rung, and the easiest place in this guide to overclaim, so I'll keep it to what we have running.

The orchestrator layer is management hierarchy applied to software. Once you have enough agents that no person can read every run, you need something that reads them for you. Concretely, an orchestrator does four things:

• Grades output. Scores what agents produced against a rubric, so quality is a number that moves rather than a feeling.
• Propagates learnings. When one agent works out something that generalizes, the orchestrator is what carries it to the others, through a review gate rather than automatically.
• Triages for human attention. Out of a hundred runs, surfaces the four a person needs to look at today.
• Adjusts priorities against goals. Notices that an agent has spent three weeks on something that isn't moving and reallocates.

Ours is called Nora, and she is the part of this stack we put the most research time into. She runs above the fleet with a simulated marketer's brain wired into the systems the team actually works in. She attends meetings. She assigns tasks and follows what happens to them. She triages risk across live work and sends the alert before anyone has gone looking for it. She answers in Slack, keeps a schedule, and revises her own instructions as she learns what holds up. Every agent below her produces something. Her job is to read what they produced and decide where the humans should spend their attention.

The human role shift is the interesting part. You stop reviewing every output and start reviewing the reviewer. Your attention moves from "is this piece of work good" to "is the thing that judges work still judging it correctly." That's a smaller job and a more leveraged one, and it's also a genuinely harder skill.

What I won't tell you is that this rung is finished. Nora is better this month than she was last month, because we are still working out how far an agent like this can go. Anyone describing their orchestrator layer as done is describing a roadmap.

No sci-fi framing is warranted here. It's an org chart, expressed in software, with a person still at the top of it.

I've written up that layer on its own, including what it costs and the point at which a team actually needs one: AI agent orchestration.

The economics: model choice, tokens, and routing

This is the section every CFO asks for.

The first thing to understand is that there are two completely different budget lines and people conflate them constantly.

Seats are what your team pays to use Claude as a tool. As of today, that's $0 for Free, $17 a month for Pro on annual billing or $20 monthly, from $100 a month for Max, and $20 per seat per month for Team on annual billing or $25 monthly, with a premium Team seat at $100 annually or $125 monthly. Team covers 2 to 150 people. Enterprise is $20 per seat plus usage at API rates. Those are the published numbers at claude.com/pricing and worth re-checking, because they move.

Usage is what your agents cost to run, and it's metered per token through the API. That's the line that scales with what you build, and it's the one people don't budget for.

Current published API rates:

Model	Input per million tokens	Output per million tokens	Use it for
Claude Opus 5	$5	$25	Strategy, long agentic runs, anything where being wrong is expensive
Claude Sonnet 5	$3	$15	Most production work. Near-Opus quality, meaningfully cheaper
Claude Haiku 4.5	$1	$5	Classification, extraction, routing, high-volume simple jobs

Sonnet 5 is running at introductory pricing of $2 and $10 through August 31, 2026, so check the models overview before you build a forecast on the sticker price.

Now the question people actually ask: what does one job cost?

A technical SEO audit across a few hundred pages, run as an agent with real connector reads, lands in the low single-digit dollars per run on Sonnet. Run daily, that's a rounding error against the salary of the person who'd otherwise do it monthly. A deep research task with a lot of reading and a long output on Opus is more like a few dollars a run. A classification pass over ten thousand records on Haiku is cents.

The number that surprises people is that the expensive part is almost never the model. It's the wasted runs: agents re-reading the same context every hour because nobody set up caching, or working on things nobody asked for.

Three levers, in order of how much they matter:

• Route cheap tasks to cheap models. The instinct is to use the best model everywhere. Don't. Extraction, classification, and routing on Haiku cost a fifth of Sonnet and are just as good at those jobs. Reserve the top tier for judgment.
• Cache the stable context. If every run re-reads the same brand guide and site structure, you're paying full price for the same tokens over and over. Prompt caching makes repeated context read at roughly a tenth of the price. On a fleet running hourly this is the single biggest line-item change you can make.
• Cap spend per agent. Ours pause at a monthly ceiling rather than running past it. This has saved us from exactly the runaway you'd expect, and it converts an unbounded risk into a known number.

The governance version of all this: an agent nobody can price is an agent nobody can budget. Every run in our fleet reports what it cost, which means the conversation about whether a given agent is worth it is a conversation with numbers in it.

What this means for your team

AI deletes the machine-work parts of marketing jobs. Formatting a report, writing the fourth variant of a subject line, pulling numbers into a deck, the first pass on a competitor teardown, populating metadata. All of it, and faster than most people expect. The jobs themselves stay.

What that exposes is uncomfortable. Some roles were mostly machine work with a thin layer of judgment on top, and those roles change a lot. Some roles were mostly judgment with machine work attached as tax, and those get better immediately.

The AI-native marketing team has a different shape. Fewer producers. More editors, orchestrators, and strategists. The person who was writing eight blog posts a month is now responsible for whether twenty are any good, which is a harder job and a more valuable one, and not everyone wants it.

Three things become scarce, and they're what I'd hire for now:

• Judgment. Knowing which of five plausible options is right for this client, this quarter. Models are good at generating options and bad at knowing which one matters here.
• Taste. Being able to look at competent work and say it isn't good enough, and say why. This is rarer than it sounds and it's the whole job of a review gate.
• Client trust. Nobody has ever built it through a channel that scales, and I don't think anyone will.

The teams that struggle with this are the ones treating AI as a headcount question. The teams that do well treat it as a leverage question: same people, more output, higher floor on quality, and a real conversation about what the people should be doing with the time.

One prediction I'll commit to. Within two years, "can you operate an agent" will be a line on marketing job descriptions the way "can you use a spreadsheet" is now. Not build one. Operate one: brief it, review it, correct it, know when to stop trusting it.

How we build this with brand marketing teams

Everything above is what we run for ourselves. The larger half of our work is building the same ladder inside brand marketing teams, and the reason those teams call us is almost always rung two. Seats are bought, people are prompting well, and none of it compounds, because the context, the packaged workflows and the guardrails don't exist yet in a form you could hand to a new hire, let alone to an agent.

What we do, in the order we do it:

• Load your context once. We build the brand HQ: voice guide with the banned list, personas, current positioning, product language, and the few pieces of past work that set the bar. In-house teams consistently underestimate this step, and everything above rung two reads from it.
• Package the workflows your team repeats. Your briefing process, your QA checklist, your reporting assembly, written as skills your people can run and your agents can load. Fix one and every brand, market and region running it gets the fix on the next run.
• Wire the stack you already have. Stock connectors where a vendor built one, custom MCP servers where nobody has, which in practice means your PIM, your feed, your DAM, or the internal system that has never had an API worth using.
• Set the ceilings and build the gate. Permission per job, a review queue that lands in the project management tool your team already opens, and named people on it. This is what lets an agent program survive its first mistake.
• Run it beside your team, then hand it over. We operate the fleet while your people learn to brief it, review it and correct it. The finish line is that they own it.

Scale is the whole reason to do it this way. A brand running six markets, forty landing pages a quarter and one overloaded content lead cannot hire its way level with that. Put the mechanical half of the work on something that runs every day to a consistent standard, and the judgment half concentrates on the people who have judgment. That trade is available to an in-house team on the same terms it was available to us.

We're a fifteen-person agency, so we won't claim we've rolled this out at a hundred brands. We built it for ourselves first, in production, on our own site and our own client delivery, which means what we bring you has already survived contact with real work instead of arriving as a framework off a slide.

A 90-day adoption roadmap

Here's what I'd actually do. The gates between the phases matter more than the activities.

Days 1 to 30: prompting, one Project, two connectors.

Get the whole team to a professional prompting standard, which takes about a week of deliberate practice and not a training program. Build one Project for your most important brand and load it properly. Connect two data sources, and pick the two you look at most, which for most marketing teams is analytics and whatever holds your documents.

Gate: can someone on your team open a fresh conversation and get usable on-brand output without explaining the brand? If not, your Project isn't done. Don't move on.

Days 31 to 60: your first three skills, and one surface beyond chat.

Pick the three workflows your team repeats most and package them as skills. Not the most impressive ones. The most repeated ones. Then add one surface: desktop if your bottleneck is long documents, browser if it's competitive and QA work, Claude Code if it's bulk operations.

Gate: are the three skills boring and reliable? Do they produce the same quality output on a Tuesday as they did the day you built them? If a skill still needs babysitting, fix it before you build a fourth.

Days 61 to 90: one supervised agent workflow, and a measurement baseline.

One agent. One job. Set it to propose, never to publish, and route its proposals to a named person whose job includes reviewing them. Pick something with a clear success measure, which usually means a maintenance or monitoring job rather than a creative one.

Gate, and this is the important one: don't build agents until your skills are boring. An agent is a skill running unattended. If the skill needs a human watching it, an agent version of it will produce unattended mistakes at whatever cadence you set.

What I'd explicitly not do in the first ninety days: build a fleet, build custom MCP servers, or set anything to publish. Those are all right eventually and all wrong early.

Get an architect-led read on where your team actually sits on this ladder, and what the next rung costs.

Questions we get

What's the difference between Claude and ChatGPT for marketing work? The practical differences that matter for marketing are context window size, writing quality on long-form, and agentic depth. Claude's current models carry a million tokens of context, which means a full brand corpus fits without chunking, and the agentic tooling is built for long multi-step runs. For casual chat the difference is smaller than the discourse suggests. For building an operation, it's large. Compare the current specs at the models overview.

What is MCP? The Model Context Protocol is an open standard for connecting AI models to your tools and data. It means an integration written once works with any model that speaks the protocol, instead of every tool needing a bespoke connection.

What are Claude Skills? A skill is a folder of instructions and reference files that Claude loads by itself when a task calls for it. It differs from a saved prompt in that it has a procedure, carries its own reference material, and applies automatically rather than being pasted. See the Agent Skills documentation.

What's the difference between an agent and an assistant? An assistant responds to requests. An agent works toward a goal using tools in a loop until it's done, blocked, or out of budget. The practical difference is whether you're present while it works.

What does it cost to run Claude for a marketing team? Two lines. Seats at published plan pricing, currently $20 per seat per month for Team on annual billing. Usage metered per token for anything agentic, which for a typical maintenance agent running daily is low single-digit dollars per run. Check current plan pricing, since it changes.

Can Claude access our analytics, CRM, and CMS? Yes, through connectors. Common systems have stock connectors you authenticate once. Anything unusual needs a custom MCP server, which is a software project rather than a configuration step.

Do we need developers to do this? Not for rungs one through three. Rung four is possible without engineering for simple cases and much better with it. Rungs five and six are engineering projects, and anyone who tells you otherwise is selling something.

Is our data safe? Anthropic's commercial terms state that they don't train on business customers' data by default, and enterprise agreements carry additional retention and privacy commitments. Verify against the current commercial terms before you make a representation to a client or a legal team, because policies change and this answer will age.

What should we automate first? The thing your team does most often that has an objectively right answer. Metadata, reporting assembly, link maintenance, data extraction. Automate the things with a checkable output before the things with a subjective one.

What is an agent fleet? Multiple specialized agents sharing a skill library and a review gate, with per-client isolation of memory, context, and permissions. The shared skills are what make it compound. The isolation is what makes it safe.

What is an AI orchestrator agent? An agent whose job is managing other agents: grading their output, propagating what works, triaging what needs human attention, and adjusting priorities against goals. It's the layer above a fleet, and it's the newest of the six rungs.

Where to start

The ladder in three sentences. Rungs one through three make your existing team faster at existing work. Rungs four through six change who does the work at all. Almost every team stops at three and concludes AI is useful but oversold, which is a correct conclusion about rung three.

The gap between teams isn't the tools. Everyone has access to the same models at the same prices. It's the operating discipline: whether your context lives somewhere the model can reach, whether your workflows are packaged or improvised, whether permission is designed or assumed, and whether a person is genuinely reviewing the output rather than nominally owning it.

That's buildable. It just isn't a purchase.

If you want a read on where your team sits and what the next rung would take, start a conversation. We'll do it as an architect-led assessment against the ladder above, and you'll leave with a specific next rung rather than a strategy deck.