The Claude Agent SDK for Marketing: A Practical Guide to Building Marketing Agents

The Claude Agent SDK is a library that puts Claude Code inside your own code. Your application gets the same agent loop, the same built-in tools, and the same context management. You write a prompt and a short list of allowed tools. From there the model reads files, searches the web, runs commands, and edits work on its own. The loop is the product: the model picks the next step, not your code. It ships for Python and TypeScript. For a marketing team the point is narrow and useful. You stop wiring a model into a workflow one call at a time. You hand over a defined job instead, and the agent carries it from the research through to something you can read and approve.

Anthropic first shipped it as the Claude Code SDK and renamed it the Claude Agent SDK in 2025, as teams put it to work well beyond coding. Installing it takes one line: npm install @anthropic-ai/claude-agent-sdk for Node, or pip install claude-agent-sdk for Python 3.10 or later, and the docs walk through the first run (Agent SDK overview). The TypeScript package ships a native Claude Code binary, so you do not install Claude Code separately.

The agent runs inside your own process, on your files and your services, and you decide what it may touch. Out of the box it can use built-in tools like Read, Write, Edit, Bash, Glob, Grep, WebSearch, and WebFetch, so it starts working without you writing any tool-handling code.

The difference that matters for marketing is plain. A chatbot answers a prompt. An agent does the work. Ask the SDK to find your three closest competitors’ new pricing pages and summarise what changed, and it runs the search, fetches the pages, reads them, and returns the summary. You never write the glue in between, and the same job that took an analyst a morning now returns a draft in minutes.

The gap between marketing teams has moved from access to execution. Everyone can prompt a model. Far fewer have a workflow that runs without them, and that is the case for building an agent in 2026. The year's major reads point one way from three directions. Stanford measures capability climbing fast. HubSpot finds marketers calling AI the biggest disruption to the job in 20 years, with most already using it for content. Microsoft describes the person's role moving toward directing work and owning the outcome. The consequence for a small team is concrete. Agents join tools that were never built to talk to each other, and they let the same headcount carry more work without a bigger budget.

Marketing teams should care because adoption stopped being the advantage. Generative AI reached 53% adoption in three years, faster than the PC or the internet, and AI agents now complete 66% of real computer tasks, up from 12% a year earlier, by Stanford’s 2026 AI Index (Stanford HAI, 2026). Using AI is now table stakes; the edge has moved to agents that own a workflow.

Marketers feel the shift. In HubSpot’s 2026 report, 61% call AI the biggest disruption to marketing in 20 years, and 80% already use it for content (HubSpot, 2026). Microsoft’s 2026 Work Trend Index frames it plainly: as agents take on execution, people gain room to direct the work and own the outcome (Microsoft, 2026). That is the operator model, and an agent is what makes it affordable.

Most marketing stacks are a pile of parts, tools that each do one thing and none of which connect. A marketing agent is the connective layer: it reads from one system, acts in another, and checks its own output against your rules before a person looks. One operator can run a weekly competitor brief, a repurposing pass, and a first-draft queue on a budget that is not growing.

Choose by who runs the tool loop. The Agent SDK runs it inside your own application, which fits when the job touches your files, your CMS, and your data. The Anthropic API, also called the Client SDK, gives you direct model access and leaves the loop to you. The Claude Code CLI runs it interactively in a terminal. That suits exploring an idea by hand. Managed Agents put the agent and its sandbox on Anthropic's infrastructure, for production work you would rather not operate. None of these cancels the others out. The comparison below sets the four side by side. The question underneath it never changes: how much of the plumbing you want to own, and where the work should run.

For marketing work the choice usually comes down to three questions. If the job runs on your own servers and touches your CMS and data, start with the Agent SDK. If you want a long-running production agent without operating any infrastructure, look at Managed Agents. If you are exploring an idea by hand, the CLI is the fastest path.

A common route is to prototype with the SDK, prove the workflow, then move long-running jobs to Managed Agents once they earn the move (Managed Agents overview). The two share the same model and tools, so the work translates across without a rewrite.

Six pieces of the SDK carry marketing work: built-in tools, the Model Context Protocol, subagents, hooks, permissions, and sessions. That list is the whole vocabulary you have to learn. Each one maps to a job a marketing team already knows, so read them as roles rather than features. Something does the work. Something reaches your other systems. Something splits a job up. Something enforces a rule. Something sets the limits. Something keeps continuity between runs. The names are new, the jobs are not, and that gap is why the SDK looks harder from the outside than it is. Together these six are the reason one operator can run work that used to need a small team.

• Built-in tools. Read, Write, Edit, Bash, WebSearch, and WebFetch mean an agent can research a topic and draft against it without you writing any tool code.

• Model Context Protocol (MCP). MCP servers connect the agent to your CMS, analytics, CRM, ad platforms, and databases (modelcontextprotocol.io), so it reads and acts across the stack instead of working blind.

• Subagents. Define a researcher, a writer, and a fact-checker, each with its own instructions and tools, and the main agent delegates to them the way a lead delegates to a team.

• Hooks. A PreToolUse or PostToolUse callback runs your own code to validate, log, or block an action before it ships. This is where a brand-voice rule becomes enforcement.

• Permissions. Pre-approve safe tools and gate the rest. A research agent gets read-only access; a publishing agent needs sign-off before anything goes live.

• Sessions. Context persists across exchanges, so you can resume a campaign mid-flight or fork it to test two angles from the same starting point.

One block sits under all of them: the context layer. The SDK loads your .claude files and CLAUDE.md, so your voice rules, ICP, and positioning travel with every run. This layer earns its place before any automation, because it is what keeps the output on brand.

Build these five first: a competitor monitor, a content repurposer, an SEO brief writer, an ad-copy variator, and an inbox triage agent. They share a shape. One job each, read-mostly tools, and a draft at the end instead of a published thing. That shape is what makes them cheap to run and safe to ship early. Choose by where the manual version is dullest and most repeatable, because that is where an agent pays back fastest. The interesting work is rarely the right first target. Ambition can wait. A first build should be boring enough that a bad run costs you a discarded draft and nothing else.

1. Competitor monitor. Watches rival pricing, launches, and messaging on a weekly cadence, and files a change brief.

2. Content repurposer. Turns one long piece into a set of derivatives, a summary, a thread outline, and a newsletter draft.

3. SEO brief writer. Researches a query, reads the ranking pages, and drafts a structured outline with sources attached.

4. Ad-copy variator. Generates on-brand headline and description variants for testing, within your voice rules.

5. Inbox triage agent. Reads inbound notes, tags them by intent, and drafts a first reply for a person to send.

How far you push each agent is a choice, and the maturity ladder below is the safe order. Begin at drafts, where the agent proposes and a person disposes. Add multi-step chains and a schedule once a guardrail is proven. Reserve multi-agent setups, where subagents split research, writing, and review, for workflows you already trust. Earn each rung before you climb to the next.

Your first agent should be a weekly competitor scan, and it fits in about fifteen lines. You give it three things: a prompt describing the job, the web tools it needs to research, and an MCP server pointed at your CMS. It searches, reads what it finds, writes a brief, and saves that brief as a draft for you to approve. Nothing goes live. This is the smallest build that still does real work, which makes it a better start than something ambitious you cannot debug. The TypeScript below is the entire shape. Read it for the structure rather than the syntax. The same four parts show up in every agent you build after this one.

import { query } from "@anthropic-ai/claude-agent-sdk";

for await (const message of query({
  prompt:
    "Scan our 3 competitors' pricing pages, summarise what " +
    "changed this week, and save the brief to the CMS as a draft.",
  options: {
    allowedTools: ["WebSearch", "WebFetch", "Write"],
    mcpServers: {
      cms: { command: "npx", args: ["-y", "@your/cms-mcp"] },
    },
  },
})) {
  if ("result" in message) console.log(message.result);
}

Four moves do the work. The prompt states the job in plain language. allowedTools pre-approves what the agent may use. The mcpServers entry plugs it into your CMS. Then the agent loop runs until it has a result. Keep the first agent small: one job, read-mostly tools, and a draft as the output.

Iterating is the same loop you already use for content. Read the message stream to see which tools the agent called, tighten the prompt where it wandered, and add a hook when you need a hard rule. Anthropic ships example agents, an email assistant and a research agent, that follow this exact shape and make a good second read (example agents on GitHub). A content repurposer is the natural next build: same structure, a different prompt and a different MCP server.

This article is the output. My marketing system runs as a set of engines, each an agent of the shape described above. Three of them made this page. Create-Articles researched the sources and wrote the answer-first structure. Create-Images built the figures as typed components, holding to one visual register. Create-Compiler then checked every field, every source, and every voice rule, and one failure would have stopped publication. All three read the same context layer, which holds the voice rules, the ICP, and the positioning. That shared layer is why the page sounds like the brand and not like a generic model. The Claude Agent SDK is that loop, packaged so your team can build with it.

This is the operator model in practice. The human sets the strategy and the bar. The agents do the work. A validation step prices the evidence behind every claim, so a number without a source does not ship. Nothing here published itself. Each run ended at a draft I reviewed, which is the same gate I would put on any agent that touches a public channel.

Three controls, and a brand needs all three. Permissions decide which tools an agent may use at all. Hooks run your own code before or after each action it takes. A human approval step sits between any output and a public channel. Set them before the first real run, not after the first bad one. An agent with permissions but no hooks can still do an approved thing badly. An agent with hooks but no human gate will eventually ship something you would not have signed. Put together, they change the worst case. A failure becomes a draft you reject on a Tuesday rather than a correction your audience reads.

1. Permissions. Pre-approve safe tools with allowedTools and require approval for the rest. A read-only research agent never receives Write or Bash, so it cannot change or publish anything by accident.

2. Hooks. A PreToolUse hook can block a publish that fails a brand-voice check. A PostToolUse hook can log every change to an audit file, so you have a record of what the agent did and when. Your rules become enforcement instead of hope.

3. A human in the loop. End every run at a draft. The model proposes, a person disposes, and the brand keeps a clear owner for what ships.

These are the same controls that make agentic marketing safe to run at scale. For the wider view on oversight, hallucinations, and bias, the case for guardrails in agentic marketing sits alongside this guide.

Plan on API-key billing from day one. Anthropic does not allow consumer claude.ai logins to power products built on the SDK, so the account you chat in will not carry your agent. Enterprise teams can point the same SDK at Amazon Bedrock, Google Vertex AI, or Microsoft Azure, which keeps it inside the cloud you already buy. Cost tracks how much an agent reads and how much it says. A tight, read-mostly agent stays cheap. A long and chatty one does not. Prototyping one agent is inexpensive enough to test against a real workflow this week, and that test beats any estimate. The harder question is not the bill. It is whether the workflow has a named owner for the approval step.

Getting started takes three steps: install the SDK, set an API key from the Claude Console, and run a small agent (Quickstart). You pay per token through the API, so a read-only research agent costs little and a multi-agent system costs more. Match an agent’s ambition to the value it earns.

Install is npm install @anthropic-ai/claude-agent-sdk, then export ANTHROPIC_API_KEY from the Console. For enterprise setups, the SDK also runs on Amazon Bedrock, Google Vertex AI, and Microsoft Azure, so it fits the cloud you already buy. One rule to plan around: Anthropic does not allow consumer claude.ai logins to power products built on the SDK, so budget for API-key billing from the start.

On cost, the levers are simple. Read-mostly agents and tight prompts keep token use low. Long, chatty runs and large context windows cost more, so watch the message stream on early builds and trim what the agent does not need. Prototyping a single agent is cheap enough to test on a real workflow this week.

Some work does not need an agent. A single summary or a one-time rewrite is faster as an API call or a CLI prompt. If a workflow has no clear owner for the approval step, build that owner first. Agents multiply whatever process you point them at, so a shaky process returns a faster, shakier result.