Hub and Spoke Agent Architecture for Marketing Operations

Most marketing teams treat AI agents as solo operators. One Claude window, one task, one output. The pattern enterprise martech needs is hub and spoke, where one coordinator agent owns routing across specialist sub-agents handling lead scoring, content QA, campaign launches, and competitive research.

This post breaks down the coordinator pattern for marketing operators running multi-agent workflows in production. Six refinements move a toy script to a system you would ship inside a real martech stack.

TL;DR

Hub and spoke architecture puts one coordinator agent at the center of your marketing AI stack. Sub-agents never talk directly to each other. The coordinator owns task decomposition, dynamic routing, result aggregation, and observability. Apply six refinements (better decomposition, dynamic selection, research partitioning, refinement loops, observability, refactoring) to ship the pattern in production.

Key Takeaways

• One coordinator agent routes work between specialist sub-agents for marketing tasks like lead scoring and campaign QA
• Sub-agents never communicate directly with each other, giving you a single observability and control layer
• Narrow task decomposition wrecks output quality when the coordinator misses entire dimensions of a problem
• Dynamic selection beats static pipelines when not every workflow needs every sub-agent
• Research partitioning stops two agents from duplicating the same work and burning tokens
• Refinement loops let the coordinator re-delegate when initial coverage is weak
• The coordinator is your single point for logging, tracing, and error handling across the system

What Is Hub and Spoke Agent Architecture?

Hub and spoke is a multi-agent pattern where one coordinator agent sits at the center and every specialist sub-agent communicates only through the coordinator. The coordinator owns routing, context-sharing, and result aggregation. Sub-agents have no direct lines to each other.

For marketing operators, the coordinator handles incoming requests like “score this lead,” “audit this campaign,” or “research this competitor.” Specialist sub-agents handle one dimension each. The coordinator decides which sub-agents to call, what context to pass, and how to combine outputs.

Why Does the Coordinator Own All Routing?

The coordinator owns four jobs in a hub and spoke setup. Task decomposition breaks the request into sub-tasks. Task delegation picks which sub-agents handle each piece. Result aggregation pulls outputs back into one coherent response. Sub-agent selection happens based on query complexity, not a fixed pipeline.

Sub-agents stay stateless. They receive context, return output, and forget the rest. This isolation is what makes the pattern observable and debuggable in production marketing systems built on Anthropic or similar foundation models.

Action item: Map your current marketing AI workflows and find the tasks with implicit coordinator logic baked into one giant prompt. Those workflows are your candidates for hub and spoke refactoring.

How Do You Avoid Narrow Task Decomposition?

Narrow decomposition is the most common coordinator failure. The coordinator breaks a request into sub-tasks but misses entire dimensions of the problem. Each sub-agent only sees its isolated piece, so none of them flag what is missing.

Example: a coordinator asked for “comprehensive competitor analysis” delegates research on pricing, features, and positioning. Missed dimensions include customer reviews, churn signals, ad spend trends, partnership announcements, and hiring patterns. The aggregated output reads complete but covers 40% of the surface area.

The fix runs in two places. First, prompt the coordinator to expand the decomposition before delegating. Second, add a coverage tool the coordinator calls after aggregation to catch gaps.

What Does a Better Decomposition Prompt Look Like?

Use this prompt to force self-reflection before delegation:

SYSTEM: You are a marketing research coordinator orchestrating specialist sub-agents.

<context>
Request: {{USER_REQUEST}}
Available sub-agents: {{SUB_AGENT_LIST}}
</context>

Before delegating, generate an initial list of research angles.

Then MUST ask yourself:
1. What stakeholder perspectives are missing?
2. What data sources have I not considered?
3. What dimensions are required for a complete answer?

Add angles to cover those gaps. Only then begin delegating.

Output: JSON array of sub-tasks with assigned sub-agent and scope.

The self-reflection step catches gaps before delegation locks in a partial view.

Action item: Add a coverage check tool to your coordinator. After aggregation, force the coordinator to score coverage against a dimension checklist before submitting the final output.

When Should Dynamic Selection Beat Static Pipelines?

Static pipelines run every sub-agent for every request. Dynamic selection lets the coordinator skip sub-agents when a workflow does not need them. For marketing workflows with variable complexity, dynamic selection saves tokens and time.

Example: a lead scoring coordinator has three sub-agents (firmographic match, behavioral signal, intent signal). A lead with rich intent data does not need behavioral signal processing. A lead with no firmographic match should skip the other two and route straight to disqualification.

Build dynamic selection by giving the coordinator routing guidance. Not a static decision tree. Heuristics the coordinator applies based on observed input.

What Does Dynamic Routing Guidance Look Like?

Copy this prompt and adapt the routing rules to your stack:

SYSTEM: You are a lead scoring coordinator routing to specialist sub-agents.

<routing_guidance>
- If the lead has a clear firmographic match, run intent signal sub-agent only
- If the lead is from an unknown company, run firmographic enrichment sub-agent first
- If the lead has no behavioral data, skip behavioral sub-agent and note the gap
- Never invoke a sub-agent unless its output answers a real question for this lead
</routing_guidance>

Lead data: {{LEAD_RECORD}}

Decide which sub-agents to invoke. Justify each decision in one sentence. Then invoke.

This pattern turns the coordinator into a router with judgment, not a fixed pipeline runner.

Action item: Audit your current AI marketing workflows for forced full-pipeline runs. Find three workflows where dynamic selection would cut token spend by 30% or more.

How Do You Partition Research to Prevent Agent Overlap?

If you send three research sub-agents the same brief, you get three overlapping answers and triple the token spend. Partition the scope so each sub-agent owns a distinct slice with no overlap.

Partitioning works through structured planning before delegation. The coordinator generates a JSON array of partitions. Each partition has a topic, a scope, and an excluded list. The coordinator delegates one partition per sub-agent and validates non-overlap before any sub-agent runs.

How Do You Structure Marketing Research Partitions?

Use this prompt to generate a partition plan before any sub-agent fires:

SYSTEM: You are a marketing research partitioning planner.

<request>
{{RESEARCH_BRIEF}}
</request>

Generate a JSON array of non-overlapping research partitions.

Each partition object MUST include:
- "topic": short label
- "scope": what is covered
- "excluded": what is NOT covered (assigned to other partitions)
- "agent": which sub-agent handles this partition

Rules:
1. Partitions MUST cover all dimensions of the request
2. No two partitions share a covered aspect
3. Output JSON only

Example output:
[
  {
    "topic": "competitor pricing",
    "scope": "list pricing, discount tiers, pricing pages",
    "excluded": "value perception (handled by reviews partition)",
    "agent": "pricing_research"
  }
]

Print the partition JSON before any sub-agent runs. This gives you a human-readable audit trail of how the work was divided.

Action item: Before delegating to multiple research sub-agents, force the coordinator to output a partition table. Reject runs where two partitions share scope.

What Does a Refinement Loop Add to Agent Output?

Most coordinators run one pass. Request comes in, sub-agents run, aggregation happens, output ships. A refinement loop lets the coordinator evaluate coverage after aggregation and re-delegate to fill gaps before final submission.

The loop has four states. Initial delegation runs the first pass. Coverage evaluation scores the aggregated output against expected dimensions. Gap delegation fires sub-agents only for missed dimensions. Final submission ships the output when coverage scores high enough or max iterations are hit.

What Does a Refinement Loop Prompt Look Like?

Use this structure for any coordinator handling high-value workflows:

SYSTEM: You are a marketing campaign QA coordinator with refinement loop logic.

<workflow_state>
Phase: {{CURRENT_PHASE}}
Iterations remaining: {{MAX_ITERATIONS}}
Current coverage: {{COVERAGE_REPORT}}
</workflow_state>

Phase logic:

1. INITIAL: Invoke each sub-agent once for assigned partitions
2. EVALUATE: Call evaluate_coverage tool with sub-agent outputs
3. REFINE: If coverage_score < 0.85 AND iterations_remaining > 0:
   - Identify gaps from evaluate_coverage output
   - Invoke sub-agents ONLY for identified gaps
   - Re-run evaluation
4. SUBMIT: Call submit_final tool only when coverage_score >= 0.85
   OR iterations_remaining == 0

NEVER call submit_final before at least one evaluation pass.

Output: Tool calls only, no prose.

Set max iterations to 3 or 4. Beyond those bounds the loop hits diminishing returns and token waste outpaces output gains.

Action item: For your highest-value AI marketing workflows (campaign launches, lead enrichment, content audits), add a coverage evaluation step with one refinement pass before output.

Why Is the Coordinator Your Observability Layer?

In hub and spoke, every message between sub-agents passes through the coordinator. This makes the coordinator the natural choke point for logging, error capture, and context control.

Without a coordinator, sub-agents talk directly to one another. You lose the ability to trace what was said. You miss errors silently. You have no enforcement on what context crosses agent boundaries. The coordinator solves all three problems in one place.

What Should You Log at the Coordinator Level?

Log five things at every coordinator step:

• Timestamp and request ID for every sub-agent invocation
• Inputs passed to each sub-agent with partition scope attached
• Outputs returned from each sub-agent
• Token counts and latency per sub-agent call
• Coordinator reasoning between tool calls

Persist logs to a file, not stdout. Use structured JSON logs so you parse them downstream into your observability stack (Datadog, Honeycomb, or a simple BigQuery sink).

How Do You Control Context Between Sub-Agents?

The coordinator decides what context each sub-agent receives. Pass the full request to all sub-agents and you waste tokens and risk scope creep. Pass only partition-scoped context and sub-agents stay focused.

Build a context filter in the coordinator. For each sub-agent invocation, strip context to only what the partition requires. Log the filtered context so you audit later.

Action item: Add structured JSON logging to your coordinator. Capture request ID, sub-agent name, input, output, tokens, and latency for every call. Pipe to your existing analytics warehouse.

How Do You Port a Coordinator to the Claude Agent SDK?

Building a coordinator with the raw Anthropic SDK works but generates verbose code. JSON tool definitions. Manual message loops. Custom state management. The Claude Agent SDK collapses everything into decorators and a managed loop.

The SDK gives you three wins. Tool decorators replace JSON tool schemas. An internal MCP server hosts tools without external infrastructure. A managed agent loop replaces your while loop with built-in iteration control.

What Does the Tool Definition Look Like Before and After?

Raw SDK requires JSON tool definitions plus separate handler functions. The Agent SDK uses a decorator pattern:

from claude_agent_sdk import tool, ClaudeSDKClient

@tool(name="evaluate_lead_fit", description="Score lead against ICP criteria")
async def evaluate_lead_fit(lead_id: str, criteria: dict) -> dict:
    # tool logic here
    return {"score": 0.85, "reasoning": "Strong fit on size and stage"}

The decorator captures the schema from the function signature. No separate JSON file. No manual binding.

What Does the Agent Loop Look Like Before and After?

Raw SDK requires a while loop with manual tool call parsing, message threading, and exit conditions. The Agent SDK runs the loop for you. You define tools, set the system prompt, pass the user message, and consume results.

Shorter codebase. Fewer bugs. Easier to refactor later when you add new sub-agents to your marketing stack.

Action item: Port one production coordinator from raw SDK to Claude Agent SDK. Measure lines of code reduction and time to add a new sub-agent. The delta justifies the port across your whole stack.

What Marketing Workflows Fit the Coordinator Pattern?

Five marketing workflows where hub and spoke pays off immediately:

• Lead scoring with firmographic, behavioral, and intent sub-agents pulling from HubSpot or Salesforce
• Campaign QA with copy review, tracking validation, and brand compliance sub-agents
• Competitive intelligence with pricing, positioning, and signal monitoring sub-agents
• Content production with research, drafting, editing, and SEO optimization sub-agents
• Multi-channel campaign launch with email, paid, social, and CRM update sub-agents

Each workflow has one orchestration entry point and multiple specialist outputs. The coordinator pattern fits because the work decomposes cleanly into independent slices.

How Do You Refactor a Working Coordinator?

A coordinator built in one file gets messy fast. Tools, prompts, logging, and state mix together. After three iterations the file becomes unreadable. Refactor before you ship.

Apply five refactoring moves:

• Move all prompts to markdown files in a prompts directory
• Move each tool to its own file in a tools directory
• Move logging logic to lib/logger.py with helper functions
• Move partition planning to lib/partitions.py as a stateless class
• Move the coordinator class to lib/coordinator.py

After refactoring the main entry file should be under 50 lines. Imports, environment loading, data loading, and one call to the coordinator. Everything else lives in modules.

What Prompt Drives an AI-Assisted Refactor?

Run this against your working coordinator. Review output before applying.

SYSTEM: You are a Python refactoring engineer.

<codebase>
{{CURRENT_CODE}}
</codebase>

Refactor this coordinator agent codebase following these rules:

1. Move all prompts to /prompts directory as .md files
2. Move all tools to /tools directory as separate .py files
3. Move logging to lib/logger.py with helper functions log_partition(), log_reasoning(), log_error()
4. Move partition logic to lib/partitions.py as a stateless class with static methods
5. Move the coordinator class to lib/coordinator.py
6. Main.py should be under 50 lines

NEVER use module-level constants. Pass configuration explicitly.
NEVER inline prompt strings. Load from .md files.

Output: List of files created with their full contents.

Most AI-assisted refactors miss edge cases on first pass. Test against three sample inputs before merging.

Action item: Refactor your largest coordinator into the file structure above. Verify the refactored version produces identical output to the original on three sample inputs.

Final Takeaways

Hub and spoke is the right pattern for marketing AI workflows where one request decomposes into specialist work.

Sub-agents stay stateless. The coordinator owns routing, context, aggregation, and observability across the full system.

Narrow decomposition is the most common coordinator failure. Build self-reflection and coverage checks into the coordinator prompt and tool surface.

Dynamic selection saves tokens. Research partitioning prevents duplicate work. Refinement loops fill gaps. Observability lives at the coordinator layer.

The Claude Agent SDK reduces coordinator code by 60% or more compared to raw SDK. Port your production coordinators when stability matters more than maximum control.