AI Agents in Production: Agentic Marketing Operations

Table of Contents

1. Why Agentic Marketing Operations Matter
2. Core Architecture Patterns for Production AI Agents
3. Agent Design: Autonomy vs. Control
4. Real-World Deployment Patterns
5. Operational Quirks and Failure Modes
6. Observability, Evals, and Cost Control
7. Security and Compliance in Agentic Systems
8. Building Your First Production Agent
9. Scaling Beyond the MVP
10. Next Steps: From Proof of Concept to Production

---

Why Agentic Marketing Operations Matter

Marketing teams run on repetition. Campaign setup, audience segmentation, performance reporting, lead scoring, ad optimisation, and customer journey orchestration are all fundamentally procedural tasks that follow patterns. Yet most teams still execute these through a combination of manual work, brittle spreadsheets, and point-tool integrations that break whenever a vendor changes their API.

AI agents change this equation. Unlike traditional automation (which executes a fixed workflow) or basic AI assistants (which answer questions), agentic AI systems can reason about marketing problems, decide which actions to take, execute those actions across multiple platforms, and adapt when conditions change. An agent doesn’t just run a campaign; it observes performance, adjusts targeting, pauses underperforming variants, and escalates anomalies to humans in real time.

The business case is concrete. Teams deploying agentic marketing operations report: 30–40% faster campaign launch cycles, 15–25% improvement in campaign ROI through real-time optimisation, 50%+ reduction in manual reporting overhead, and significantly improved data quality because agents enforce consistent tagging and naming conventions across platforms.

But production agentic systems are not simple. They require careful architectural thinking, rigorous testing, and operational discipline. This guide walks through the patterns, code-level decisions, and real-world quirks that separate successful deployments from expensive failures.

---

Core Architecture Patterns for Production AI Agents

The Agentic Loop: Perception, Reasoning, Action

Every production AI agent follows a core loop: observe the environment, reason about what needs to happen, take action, and repeat. In marketing operations, this looks like:

1. Perception: Ingest campaign performance data (impressions, clicks, conversions, spend), audience data (size, engagement, churn), and business context (budget, goals, constraints).
2. Reasoning: The agent’s language model processes this data, evaluates multiple possible actions (pause this variant, increase budget for that audience, create a new segment, escalate to human), and decides on the next step.
3. Action: Execute the decision by calling APIs (Google Ads, Meta, Salesforce, HubSpot, Klaviyo) to modify campaigns, create audiences, send alerts, or log decisions for audit trails.
4. Reflection: Log what happened, capture outcomes, and feed those back into the next perception cycle.

This loop runs continuously—typically every 15 minutes to 2 hours depending on campaign velocity and business requirements. The key architectural decision is where the reasoning happens and how you structure the data flowing through that loop.

Synchronous vs. Asynchronous Architectures

Most teams start with synchronous agents: a request comes in (human or scheduled), the agent runs its loop, and returns a result or status. This is simple to build and debug, but it creates latency and cost problems at scale.

Production systems typically migrate to asynchronous event-driven architectures:

• Event Stream: Campaign performance events (e.g., “campaign X had a 2% conversion rate drop”) flow into a message queue (Kafka, AWS SQS, Google Pub/Sub).
• Agent Workers: Stateless agent processes consume events, run reasoning, and emit action events.
• Action Executors: Separate services consume action events and call external APIs with retry logic and rate limiting.
• State Store: A database (PostgreSQL, DynamoDB, Firestore) tracks agent decisions, campaign state, and audit trails.

This pattern decouples reasoning from execution, makes the system resilient to API failures, and allows you to scale the reasoning layer independently of the action layer. It also makes it trivial to replay events and debug agent behaviour.

The Role of Tool Definitions

An agent is only as good as the tools it can call. In marketing operations, tools typically include:

• Campaign Management: Create, pause, resume, delete campaigns; adjust budgets; modify targeting.
• Audience Operations: Segment audiences; upload customer lists; create lookalike audiences; apply exclusions.
• Reporting: Query performance metrics; generate summaries; compare variants.
• Business Logic: Check budget remaining; validate against business rules; escalate decisions that exceed thresholds.

Each tool is defined as a schema that the agent can understand. Here’s a simplified example:

{
  "name": "adjust_campaign_budget",
  "description": "Increase or decrease the daily budget for a campaign based on performance",
  "parameters": {
    "type": "object",
    "properties": {
      "campaign_id": {"type": "string", "description": "The unique ID of the campaign"},
      "new_daily_budget": {"type": "number", "description": "New daily budget in cents"},
      "reason": {"type": "string", "description": "Why we're adjusting the budget"}
    },
    "required": ["campaign_id", "new_daily_budget", "reason"]
  }
}

The agent reads these schemas, understands what each tool does, and decides which tools to call based on the marketing problem at hand. This is where agentic AI differs fundamentally from rule-based automation: the agent isn’t executing a predefined workflow; it’s reasoning about which tools to use and in what order.

Prompt Engineering for Marketing Agents

The system prompt is the agent’s operating manual. A good system prompt for a marketing agent includes:

• Role and Constraints: “You are a marketing operations agent. You can only adjust campaigns within 15% of their current budget without human approval. You must always provide a reason for your actions.”
• Business Context: “Our goal is to maintain a 3.5% conversion rate while maximising revenue. We have a total monthly budget of $50,000. We prioritise customer acquisition over retention this quarter.”
• Safety Guidelines: “Do not pause campaigns that are performing above target. Do not adjust budgets more than once per 6 hours. Always escalate decisions affecting more than 10% of total spend.”
• Output Format: “Respond with a JSON object containing your decision, the tools you’re calling, and your reasoning.”

The prompt is not static. As you learn what works and what fails, you’ll iterate on the prompt. Many teams version their prompts like code, track changes, and A/B test different prompt variants against historical data.

---

Agent Design: Autonomy vs. Control

The Autonomy Spectrum

There are three broad levels of agent autonomy in production systems:

Level 1: Recommendation Agents (Low Autonomy) The agent observes data, reasons about actions, and presents recommendations to humans. Humans approve or reject each action. This is the safest approach but requires human bandwidth and introduces latency.

Level 2: Constrained Autonomous Agents (Medium Autonomy) The agent can execute actions automatically, but only within predefined guardrails. For example: “Pause campaigns performing below 2% conversion rate, but only if spend is less than $500/day. Escalate anything else.” This is the sweet spot for most marketing teams.

Level 3: Fully Autonomous Agents (High Autonomy) The agent makes all decisions without human approval. This is rare in production marketing systems because the stakes are high (you can burn budget fast) and regulatory/compliance requirements often demand audit trails.

Most teams start at Level 1, move to Level 2 once they understand the agent’s behaviour, and rarely move to Level 3. The key is making the transition explicit and measurable.

Guardrails and Safety Mechanisms

Production agents need hard constraints that can’t be overridden by the language model. Here’s how to implement them:

Hard Limits in Code

def adjust_campaign_budget(campaign_id, new_budget, reason):
    # Hard constraint: never exceed 150% of previous budget
    current_budget = get_campaign_budget(campaign_id)
    max_increase = current_budget * 1.5
    
    if new_budget > max_increase:
        return {"status": "rejected", "reason": f"Budget increase exceeds 150% limit"}
    
    # Hard constraint: never go below $10/day
    if new_budget < 1000:  # in cents
        return {"status": "rejected", "reason": f"Budget below minimum threshold"}
    
    # Constraint passed; proceed
    return execute_budget_change(campaign_id, new_budget, reason)

These constraints sit in your tool definitions and are enforced before the agent can call the tool. The agent never sees a world where it successfully violated a constraint.

Approval Workflows For higher-stakes decisions, implement an approval layer:

if decision_impact_score > APPROVAL_THRESHOLD:
    # Send to human for approval
    approval_task = create_approval_request(
        decision=decision,
        impact=decision_impact_score,
        assigned_to=find_responsible_stakeholder()
    )
    return {"status": "pending_approval", "task_id": approval_task.id}
else:
    # Auto-execute
    return execute_decision(decision)

The impact score is typically a function of spend magnitude, audience size, or business criticality.

Handling Agent Hallucinations in Marketing

Language models sometimes invent data or make up tool calls. In marketing operations, this is dangerous. An agent might claim a campaign has a 5% conversion rate when it actually has 0.5%, or it might try to call a tool that doesn’t exist.

Defend against this with:

1. Strict Tool Validation: Every tool call is validated against the schema before execution. If the agent passes invalid parameters, reject the call and ask the agent to retry.
2. Data Grounding: Always fetch fresh data before reasoning. Don’t rely on data from earlier in the conversation.
3. Reasoning Traces: Require the agent to show its working. If it claims a conversion rate, ask it to cite the data source.
4. Fallback to Human: If the agent makes the same mistake twice, escalate to a human.

---

Real-World Deployment Patterns

Pattern 1: The Marketing Data Lake + Agent Workers

This is the most common production pattern. Your marketing data (from Google Ads, Meta, Salesforce, etc.) flows into a central data warehouse or data lake. Agent workers query this data, reason about actions, and emit decisions to an action queue.

Architecture:

• Data Ingestion: Scheduled jobs (daily or hourly) pull data from marketing platforms into a data warehouse (BigQuery, Snowflake, Redshift).
• Agent Trigger: An event or schedule triggers agent workers (running on Kubernetes, Lambda, or Cloud Run).
• Reasoning: The agent queries the data warehouse, runs LLM reasoning, and decides on actions.
• Action Execution: Actions are enqueued and executed by separate services that call external APIs.
• Audit Log: Every decision, action, and outcome is logged to a database for compliance and debugging.

This pattern scales well because reasoning is decoupled from action execution. You can have 10 agent workers reasoning in parallel while a single action executor carefully throttles API calls to respect rate limits.

Pattern 2: Real-Time Streaming Agents

For high-velocity campaigns or real-time bidding optimisation, some teams deploy agents that consume event streams and make decisions with sub-second latency.

Architecture:

• Event Stream: Campaign events (impressions, clicks, conversions) flow into Kafka or Kinesis in real time.
• Stateful Agent: An agent maintains state (current campaign performance, budget spent, etc.) and consumes events.
• Immediate Decision: When an event triggers a decision (e.g., “this audience segment just hit our cost-per-acquisition limit”), the agent decides immediately.
• Action: Actions are sent directly to the platform (e.g., reduce bid for this segment) with minimal latency.

This pattern is powerful but operationally complex. You need careful state management, exactly-once processing guarantees, and extensive monitoring. Most teams don’t need this level of sophistication; the daily/hourly pattern is sufficient.

Pattern 3: Agent-as-a-Microservice

Some teams expose agents as HTTP services that other systems can call. For example, your CRM might call the marketing agent to ask, “Should we increase spend on this customer segment?”

Architecture:

• Agent Service: A containerised agent service (on Kubernetes, Cloud Run, or ECS) exposes a REST API.
• Request/Response: Callers POST a marketing question (e.g., {"campaign_id": "123", "question": "should we increase budget?"}).
• Agent Reasoning: The agent queries data, reasons, and returns a decision.
• Caller Integration: The caller integrates the response into their workflow.

This pattern is useful for cross-functional integration but introduces latency and requires careful rate limiting. Each request to the agent service incurs an LLM call, which costs money and takes time.

---

Operational Quirks and Failure Modes

Quirk 1: API Rate Limits and Backpressure

Marketing platforms have strict rate limits. Google Ads allows ~50 API calls per second per account. Meta allows ~200 calls per minute. If your agent tries to execute 1,000 actions simultaneously, you’ll hit these limits and get throttled.

Solution: Implement a token bucket rate limiter in your action executor:

from collections import deque
import time

class RateLimiter:
    def __init__(self, max_calls_per_second):
        self.max_calls = max_calls_per_second
        self.calls = deque()
    
    def wait_if_needed(self):
        now = time.time()
        # Remove calls older than 1 second
        while self.calls and self.calls[0] < now - 1:
            self.calls.popleft()
        
        if len(self.calls) >= self.max_calls:
            sleep_time = 1 - (now - self.calls[0])
            time.sleep(sleep_time)

Queue actions and execute them at a rate that respects platform limits. This introduces latency (actions might take 10–30 minutes to execute) but prevents API errors.

Quirk 2: Data Staleness and Consistency

Marketing data is often delayed. Google Ads data is typically 2–4 hours behind real time. Meta data can be 24 hours behind. If your agent makes decisions based on stale data, it might miss real-time performance changes.

Solution: Be explicit about data freshness in your agent’s context:

{
  "data_snapshot_time": "2025-01-15T14:00:00Z",
  "data_freshness_hours": 2,
  "note": "This data is 2 hours old. Real-time performance may differ."
}

For high-frequency decisions, use real-time data sources (conversion pixels, server-side tracking) instead of relying on platform APIs.

Quirk 3: Cascading Failures Across Platforms

Marketing stacks are interconnected. A campaign in Google Ads targets an audience from Salesforce. If the Salesforce API is down, the agent can’t fetch the audience, so it can’t make decisions about the campaign.

Solution: Implement graceful degradation:

def get_campaign_data(campaign_id):
    try:
        google_data = fetch_google_ads_data(campaign_id)
    except APIError:
        google_data = get_cached_google_data(campaign_id)
        log_warning("Using cached Google Ads data; live API unavailable")
    
    try:
        salesforce_data = fetch_salesforce_audience(campaign_id)
    except APIError:
        salesforce_data = None
        log_warning("Salesforce unavailable; proceeding without audience data")
    
    return combine_data(google_data, salesforce_data)

When a data source is unavailable, use cached data or skip decisions that depend on that data. Never let one API failure cascade into a system-wide outage.

Quirk 4: Agent Drift and Prompt Decay

Over time, the behaviour of your agent will drift. The LLM model might be updated, your prompt might become outdated, or the agent might learn bad patterns from repeated mistakes.

Solution: Implement continuous monitoring and prompt versioning:

1. Track Agent Decisions Over Time: Log every decision, action, and outcome.
2. Measure Performance: Compare agent-driven campaigns to control campaigns. If the agent’s campaigns underperform, investigate why.
3. Version Your Prompts: Treat prompts like code. When you update the prompt, increment the version and A/B test the new version.
4. Automated Retraining: Periodically retrain your agent’s reasoning on recent data to prevent drift.

Most teams find that agents need prompt updates every 4–8 weeks as business conditions change.

Quirk 5: Cost Explosion from Excessive API Calls

If your agent is poorly designed, it can rack up massive API costs. An agent that calls the Google Ads API 100 times per minute will cost thousands of dollars per month.

Solution: Implement cost tracking and budgets:

class CostTracker:
    def __init__(self, monthly_budget_usd):
        self.monthly_budget = monthly_budget_usd
        self.costs_today = 0
        self.costs_this_month = 0
    
    def can_call_api(self, api_name, estimated_cost):
        if self.costs_this_month + estimated_cost > self.monthly_budget * 0.9:
            log_alert(f"Approaching monthly API budget. Halting non-critical calls.")
            return False
        return True

Set hard budgets for API calls and monitoring. When you approach the budget, pause non-critical operations.

---

Observability, Evals, and Cost Control

Observability for Agentic Systems

Unlike traditional software, agents are probabilistic. The same input might produce different outputs on different runs. This makes debugging hard. You need comprehensive observability.

Key Metrics to Track:

1. Agent Execution Metrics:

   • Number of decisions made per hour
   • Distribution of decision types (pause campaign, increase budget, create audience, etc.)
   • Decision latency (time from trigger to decision)
   • Tool call success rate (% of tool calls that succeeded)

2. Business Metrics:

   • Campaign ROI (agent-driven vs. control)
   • Budget utilisation (% of available budget spent)
   • Conversion rate trends
   • Cost per acquisition

3. Operational Metrics:

   • API call volume and cost
   • Error rates (API failures, validation failures, hallucinations)
   • Escalation rate (% of decisions requiring human approval)
   • Audit log completeness

Implementation: Use a combination of structured logging, time-series databases (Prometheus, InfluxDB), and dashboards (Grafana, Datadog). Every agent decision should log:

{
  "timestamp": "2025-01-15T14:30:00Z",
  "agent_id": "marketing_agent_v3",
  "decision_type": "pause_campaign",
  "campaign_id": "123",
  "reason": "Conversion rate fell below 2% threshold",
  "tools_called": ["pause_campaign"],
  "execution_time_ms": 1240,
  "status": "executed",
  "outcome": "campaign paused successfully"
}

Building Evals for Agent Behaviour

Evaluations (evals) are tests that measure whether your agent is behaving correctly. Unlike traditional software testing, evals for agents are often fuzzy because correct behaviour is contextual.

Types of Evals:

1. Correctness Evals: Does the agent make the right decision given specific data? For example: “Given a campaign with 1% conversion rate and $5,000 spent, the agent should recommend pausing it.”

2. Safety Evals: Does the agent respect guardrails? For example: “The agent should never increase a campaign budget by more than 50% in a single decision.”

3. Consistency Evals: Does the agent make the same decision when given the same data twice? (It should.)

4. Regression Evals: Does the agent’s performance degrade when you update the prompt or model? Compare new agent behaviour to baseline.

Implementation: Build a test suite with historical data:

def test_agent_pauses_underperforming_campaign():
    """Agent should pause campaigns with <2% conversion rate."""
    campaign_data = {
        "campaign_id": "test_123",
        "conversion_rate": 0.015,  # 1.5%
        "spend_today": 250,
        "status": "active"
    }
    
    decision = agent.decide(campaign_data)
    
    assert decision["action"] == "pause_campaign"
    assert "conversion rate below threshold" in decision["reason"]

def test_agent_respects_budget_limits():
    """Agent should never increase budget by more than 50%."""
    campaign_data = {
        "campaign_id": "test_456",
        "current_budget": 1000,  # $10/day
        "performance": "excellent"
    }
    
    decision = agent.decide(campaign_data)
    new_budget = decision.get("new_budget")
    
    assert new_budget <= 1500, "Budget increase exceeds 50% limit"

Run these evals automatically whenever you update the agent. Track eval pass rates over time. If pass rates drop, investigate before deploying.

Cost Control: LLM Inference Budgets

Every agent decision involves an LLM API call (to OpenAI, Anthropic, Google, etc.). At scale, this adds up. A team running 1,000 agent decisions per day at $0.01 per decision costs $10,000 per month.

Cost Control Strategies:

1. Batch Decisions: Instead of deciding on each campaign individually, batch them: “Evaluate all 50 campaigns and decide which ones to adjust.” This reduces API calls by 50x.

2. Caching: If you’ve already decided on a campaign in the last 6 hours and nothing has changed, use the cached decision instead of calling the LLM again.

3. Smaller Models: Use smaller, cheaper models (Claude Haiku, GPT-4 Mini) for routine decisions and reserve larger models (GPT-4, Claude 3 Opus) for complex reasoning.

4. Local Inference: For simple decisions (e.g., “is this campaign underperforming?”), use a small local model instead of calling an API.

Example: Batched Decision Making

def decide_on_campaigns_batch(campaign_list):
    """Evaluate multiple campaigns in a single LLM call."""
    prompt = f"""
    You are a marketing agent. Review the following campaigns and recommend actions.
    Return a JSON array with one object per campaign.
    
    Campaigns:
    {json.dumps(campaign_list)}
    
    For each campaign, decide: pause, increase_budget, decrease_budget, or no_action.
    """
    
    response = llm.complete(prompt)
    decisions = json.loads(response)
    
    return decisions  # 50 campaigns, 1 API call, ~$0.05

This approach reduces cost by 50x compared to deciding on each campaign individually.

---

Security and Compliance in Agentic Systems

Authentication and Authorization

Your agent needs credentials to call marketing platforms. Storing these credentials securely is critical.

Best Practices:

1. Use OAuth 2.0: Never store plaintext API keys. Use OAuth tokens that can be revoked and rotated.
2. Secrets Management: Store credentials in a secrets manager (AWS Secrets Manager, HashiCorp Vault, Google Secret Manager), not in code or environment variables.
3. Least Privilege: Give the agent only the permissions it needs. If it only adjusts campaign budgets, don’t give it permission to delete campaigns.
4. Audit Trails: Log every API call the agent makes, including who authorised it and when.

Data Privacy and Compliance

If your agent handles customer data (email addresses, phone numbers, behavioural data), you have privacy obligations.

Compliance Considerations:

1. GDPR (EU): If you process data on EU residents, you need consent and data processing agreements.
2. CCPA (California): California residents have rights to know, delete, and opt out.
3. PIPEDA (Canada): Similar to GDPR for Canadian residents.
4. Australian Privacy Act: If processing Australian data, you need to comply with APPs (Australian Privacy Principles).

When building agentic systems that handle customer data:

• Get explicit consent before using data for agent-driven decisions.
• Document your data processing (what data the agent uses, how long it’s retained, who has access).
• Implement data minimisation (only collect and use data you need).
• Provide a way for customers to opt out of agent-driven decisions.

SOC 2 and Audit Readiness

If you’re selling to enterprise customers, they’ll ask for SOC 2 Type II certification. Agentic systems add complexity to SOC 2 audits because you need to demonstrate control over agent behaviour.

Audit-Ready Practices:

1. Audit Logging: Every agent decision must be logged with timestamp, user, action, and outcome. These logs must be immutable and retained for at least 1 year.
2. Change Management: Document every change to agent prompts, tool definitions, and guardrails. Use version control (Git) for prompts.
3. Access Controls: Restrict who can deploy agents, modify prompts, or approve escalated decisions.
4. Incident Response: Document procedures for handling agent failures or security incidents.

For teams pursuing SOC 2 compliance, PADISO’s AI Quickstart Audit provides a fixed-scope, fixed-fee diagnostic of your AI architecture and compliance readiness in just 2 weeks.

---

Building Your First Production Agent

Step 1: Define the Problem Narrowly

Don’t try to build a general-purpose marketing agent that does everything. Start with a specific, high-impact problem:

• “Pause underperforming Google Ads campaigns”
• “Create lookalike audiences from our top customers”
• “Generate daily performance reports and flag anomalies”

Choose a problem where:

• The cost of failure is low (you can undo the agent’s actions easily).
• The potential upside is clear (time saved, revenue gained, cost cut).
• You have clean data to work with.

Step 2: Build the Data Foundation

Before writing any agent code, ensure you can reliably fetch the data the agent needs:

1. Set up data ingestion: Scheduled jobs that pull data from marketing platforms into a data warehouse or lake.
2. Validate data quality: Check that data is complete, accurate, and timely. Missing data is a common cause of agent failures.
3. Create a query API: Build a simple service that agents can call to fetch campaign data, audience data, etc. This decouples the agent from the data layer.

# Example: Simple data API
from fastapi import FastAPI
from datetime import datetime, timedelta

app = FastAPI()

@app.get("/campaigns/{campaign_id}")
def get_campaign_data(campaign_id: str):
    """Fetch current performance data for a campaign."""
    data = query_warehouse(f"""
        SELECT campaign_id, impressions, clicks, conversions, spend, status
        FROM campaigns
        WHERE campaign_id = %s AND date >= %s
    """, [campaign_id, datetime.now() - timedelta(days=7)])
    
    return {
        "campaign_id": campaign_id,
        "metrics": aggregate_metrics(data),
        "data_freshness": "2 hours"
    }

Step 3: Define Tools and Guardrails

Decide exactly what actions the agent can take. For the “pause underperforming campaigns” example:

Tools:

• pause_campaign(campaign_id): Pause a campaign.
• escalate_decision(campaign_id, reason): Send a decision to a human for approval.

Guardrails:

• Only pause campaigns that have been running for at least 7 days (to avoid pausing campaigns still in learning phase).
• Only pause campaigns with spend > $100 (to avoid pausing tiny test campaigns).
• Never pause campaigns that are part of a multi-campaign bundle.
• Always log the reason for pausing.

Step 4: Write and Test the Agent

Start with a simple synchronous agent:

import anthropic
import json

class MarketingAgent:
    def __init__(self):
        self.client = anthropic.Anthropic()
        self.tools = [
            {
                "name": "pause_campaign",
                "description": "Pause a campaign that is underperforming",
                "input_schema": {
                    "type": "object",
                    "properties": {
                        "campaign_id": {"type": "string"},
                        "reason": {"type": "string"}
                    },
                    "required": ["campaign_id", "reason"]
                }
            }
        ]
    
    def decide(self, campaign_data):
        """Decide whether to pause a campaign."""
        prompt = f"""
        You are a marketing operations agent. Your job is to decide whether to pause underperforming campaigns.
        
        Pause a campaign if:
        - Conversion rate is below 2%
        - Cost per conversion exceeds $50
        - Click-through rate is below 0.5%
        
        Do NOT pause if:
        - Campaign has been running for less than 7 days
        - Total spend is less than $100
        - Campaign is part of a test or experiment
        
        Campaign data:
        {json.dumps(campaign_data, indent=2)}
        
        Decide whether to pause this campaign or leave it running.
        """
        
        response = self.client.messages.create(
            model="claude-3-5-sonnet-20241022",
            max_tokens=1024,
            tools=self.tools,
            messages=[{"role": "user", "content": prompt}]
        )
        
        # Extract tool calls from response
        decisions = []
        for block in response.content:
            if block.type == "tool_use":
                decisions.append({
                    "action": block.name,
                    "params": block.input
                })
        
        return decisions

# Test the agent
agent = MarketingAgent()
test_campaign = {
    "campaign_id": "test_123",
    "conversion_rate": 0.015,  # 1.5%
    "cost_per_conversion": 75,
    "click_through_rate": 0.003,
    "spend_total": 500,
    "days_running": 14
}

decisions = agent.decide(test_campaign)
print(json.dumps(decisions, indent=2))

Test this agent against historical data. Does it make sensible decisions? Does it respect guardrails?

Step 5: Deploy with Monitoring

Deploy the agent to a staging environment first. Run it in read-only mode (it logs decisions but doesn’t execute them). Monitor:

• What decisions would it make?
• How often would it escalate to humans?
• What’s the cost of the agent’s API calls?

Once you’re confident, deploy to production with human approval required for the first 100 decisions. Gradually reduce approval requirements as you build confidence.

---

Scaling Beyond the MVP

From Single-Agent to Multi-Agent Systems

Once your first agent is working, you’ll want to add more agents for different tasks. This introduces coordination challenges.

Multi-Agent Architecture:

• Campaign Optimisation Agent: Adjusts budgets and targeting for existing campaigns.
• Audience Creation Agent: Creates new audiences based on customer data and performance.
• Reporting Agent: Generates daily summaries and alerts.
• Budget Allocation Agent: Distributes monthly budget across campaigns.

These agents need to coordinate. For example, the Campaign Optimisation Agent shouldn’t increase budgets if the Budget Allocation Agent is about to reallocate budget.

Solution: Implement a shared state store and event log:

class AgentCoordinator:
    def __init__(self, state_store, event_log):
        self.state = state_store  # Shared state across agents
        self.events = event_log   # Immutable log of all decisions
    
    def execute_agent_decision(self, agent_name, decision):
        """Execute a decision, checking for conflicts with other agents."""
        # Check if another agent has already modified this campaign today
        recent_changes = self.events.query(
            campaign_id=decision["campaign_id"],
            since=datetime.now() - timedelta(hours=24)
        )
        
        if recent_changes:
            # Another agent recently modified this campaign
            # Log a warning and skip this decision
            log_warning(f"Skipping decision from {agent_name}: campaign recently modified by {recent_changes[0]['agent']}")
            return False
        
        # No conflicts; execute the decision
        self.events.log(agent_name, decision)
        return True

Handling Agent Conflicts and Interference

When you have multiple agents, they can interfere with each other. For example:

• Campaign Optimisation Agent increases budget for campaign A.
• 30 minutes later, Budget Allocation Agent decreases budget for campaign A because it needs to fund campaign B.
• Campaign Optimisation Agent sees the decrease and increases it again.
• Loop repeats.

Solutions:

1. Mutex Locks: When one agent is modifying a campaign, lock it so other agents can’t modify it simultaneously.
2. Decision Buffering: Don’t execute decisions immediately. Buffer them for 1 hour and deduplicate conflicting decisions.
3. Agent Hierarchy: Define an order of precedence. Budget Allocation Agent decisions override Campaign Optimisation Agent decisions.
4. Explicit Coordination: Have agents communicate explicitly: “Campaign Optimisation Agent, I’m reallocating budget. Don’t increase this campaign’s budget for the next 2 hours.”

Scaling to Hundreds of Campaigns

When you have hundreds or thousands of campaigns, you can’t run one agent decision per campaign. You need to batch and parallelise.

Batch Processing:

def process_campaigns_in_batches(all_campaigns, batch_size=50):
    """Process campaigns in batches to reduce API calls."""
    for i in range(0, len(all_campaigns), batch_size):
        batch = all_campaigns[i:i+batch_size]
        
        # Single LLM call for entire batch
        decisions = agent.decide_batch(batch)
        
        # Execute decisions
        for decision in decisions:
            execute_decision(decision)

Parallelisation:

import concurrent.futures

def process_campaigns_parallel(all_campaigns, num_workers=10):
    """Process campaigns in parallel using multiple agent workers."""
    with concurrent.futures.ThreadPoolExecutor(max_workers=num_workers) as executor:
        futures = []
        for campaign in all_campaigns:
            future = executor.submit(agent.decide, campaign)
            futures.append(future)
        
        # Collect results as they complete
        for future in concurrent.futures.as_completed(futures):
            decision = future.result()
            execute_decision(decision)

With batching and parallelisation, you can process 1,000 campaigns in ~5 minutes instead of 16 hours.

Integration with Existing Marketing Stacks

Production agents need to integrate with your existing tools: Salesforce, HubSpot, Google Ads, Meta, Klaviyo, etc. This requires:

1. API Connectors: Build or use existing connectors to each platform. Handle authentication, rate limiting, and error handling.
2. Data Mapping: Each platform has different data models. Map between them: Salesforce “Leads” = HubSpot “Contacts” = Klaviyo “Profiles”.
3. Webhook Handlers: Listen for events from platforms (campaign created, audience updated) and trigger agent decisions.

Many teams use integration platforms like Zapier, Make, or custom middleware to handle this complexity.

For teams building sophisticated AI platforms with multiple agents and complex integrations, PADISO’s Platform Development services in Sydney, San Francisco, New York, and other cities provide end-to-end platform engineering, including data infrastructure design, multi-tenant SaaS architecture, and observability.

---

Next Steps: From Proof of Concept to Production

Immediate Actions (Week 1–2)

1. Identify Your First Use Case: Choose one high-impact, low-risk marketing operation to automate.
2. Audit Your Data: Ensure you have reliable data pipelines for the campaigns and metrics you’ll be optimising.
3. Define Guardrails: Write down the constraints and safety rules the agent must follow.
4. Build a Prototype: Implement a simple agent using Claude, GPT-4, or Gemini. Test it against historical data.

Short-Term (Weeks 3–8)

1. Deploy to Staging: Run the agent in read-only mode. Log all decisions without executing them.
2. Collect Baseline Data: Measure how the agent’s decisions compare to human decisions. Build evals.
3. Iterate on Prompts: Refine the system prompt based on eval results and real-world feedback.
4. Implement Monitoring: Set up dashboards for agent performance, cost, and business metrics.
5. Plan Security and Compliance: If handling sensitive data, design for SOC 2 or other compliance requirements from day one.

Medium-Term (Weeks 9–16)

1. Graduated Rollout: Deploy the agent to production with human approval required. Gradually reduce approval requirements.
2. Expand to More Campaigns: If the first agent works well, expand it to more campaigns or add a second agent.
3. Optimise Cost: Implement batching, caching, and smaller models to reduce LLM inference costs.
4. Build Multi-Agent Coordination: If you have multiple agents, implement coordination and conflict detection.

Long-Term (Months 4+)

1. Continuous Improvement: Run A/B tests on prompt variants. Measure agent performance against business metrics.
2. Expand to New Domains: Once marketing operations are automated, consider automating customer support, sales operations, or product analytics.
3. Build Custom Models: If LLM costs are high, consider fine-tuning a smaller model on your specific domain.
4. Integrate Deeply: Integrate agents into your product, so customers can use them directly.

When to Bring in Expert Help

Building production agentic systems is complex. Consider bringing in external expertise if:

• You’re unsure about architecture: PADISO’s AI Advisory Services in Sydney and other cities provide architecture and strategy guidance from teams that ship production AI systems.
• You need to move fast: A Fractional CTO can lead your technical strategy and unblock your team.
• You’re building a platform: If agents are core to your product, PADISO’s Platform Development services provide end-to-end platform engineering.
• You need compliance: If you’re targeting enterprise customers, PADISO helps teams achieve SOC 2 compliance and implement security audit readiness via Vanta.
• You’re in financial services: If you’re in fintech or banking, PADISO’s AI for Financial Services team understands APRA, ASIC, and AUSTRAC requirements.

---

Conclusion: The Operating Principles

Production agentic marketing operations are not magic. They’re engineering. The teams that succeed follow these principles:

1. Start Narrow: Solve one specific problem well before trying to automate everything.
2. Build Observability Early: You can’t improve what you don’t measure. Instrument your agents from day one.
3. Respect Guardrails: Constraints are features, not bugs. Hard limits prevent expensive failures.
4. Iterate on Prompts: Prompts are code. Version them, test them, and iterate.
5. Monitor Costs: LLM inference costs add up fast. Implement cost tracking and budgets.
6. Plan for Failure: APIs go down. Data gets stale. Agents hallucinate. Build for graceful degradation.
7. Measure Business Impact: Don’t just measure technical metrics. Measure campaign ROI, time saved, and revenue generated.
8. Coordinate Multiple Agents: When you have many agents, they need to coordinate. Plan for this from the start.

The marketing teams winning with agentic AI are not the ones with the most sophisticated prompts. They’re the ones with the best data, the clearest problem definitions, and the most rigorous operational discipline.

Start building. Measure relentlessly. Iterate quickly. The future of marketing operations is agentic, and the time to start is now.

If you’re ready to build production agentic systems but unsure where to start, PADISO is a Sydney-based venture studio and AI digital agency that partners with ambitious teams to ship AI products. We’ve helped dozens of founders and operators move from proof of concept to production AI systems. Book a call to discuss your agentic marketing operations strategy.