DEV Community: Marc Newstead

Building Multi-Agent Systems: When Your AI Should Spawn More AIs

Marc Newstead — Mon, 22 Jun 2026 09:12:00 +0000

Building Multi-Agent Systems: When Your AI Should Spawn More AIs

You've built a chatbot. It works. Now product wants it to handle legal queries, technical troubleshooting, and customer support—all in one conversation. Your first instinct? Build three specialised agents and hardcode the routing logic. But there's another pattern gaining traction: supervisor agents that dynamically spawn sub-agents on demand.

Let's talk about when each approach makes sense, because the choice will fundamentally shape your system's cost, reliability, and maintainability.

The Hardcoded Hierarchy: Routing Rules You Control

In a static architecture, your orchestration logic is explicit code:

def route_request(query):
    if contains_legal_keywords(query):
        return legal_agent.process(query)
    elif is_technical_issue(query):
        return tech_support_agent.process(query)
    else:
        return general_agent.process(query)

This is predictable. You know exactly which agent handles what, your token costs are bounded, and debugging is straightforward. When something goes wrong, you're reading deterministic code, not trying to decipher why an LLM decided to spawn a "blockchain expert" for a password reset.

The trade-off? Brittleness. Every new capability means updating your routing logic. Edge cases pile up. That legal query about API rate limits? Neither your legal agent nor your technical agent was designed for it, and your routing function won't know what to do.

Dynamic Orchestration: Let the LLM Decide

Dynamic supervisors flip the script. Instead of hardcoded rules, the supervisor reasons about which sub-agents to spawn:

# Supervisor system prompt (simplified)
supervisor_prompt = """
You have access to these specialist agents:
- LegalAgent: contract review, compliance, GDPR
- TechAgent: API debugging, infrastructure
- CustomerAgent: billing, account management

Analyse the user's request and spawn appropriate sub-agents.
You may spawn multiple agents if needed.
"""

The supervisor becomes a meta-agent that interprets intent and assembles a response pipeline at runtime. For that legal-technical hybrid query? It might spawn both agents, coordinate their outputs, and synthesise a final answer.

This is powerful. New capabilities can be added by updating the agent registry and supervisor prompt—no code changes. The system adapts to novel combinations of requirements you didn't anticipate at design time.

But it's expensive. Every request now includes:

Supervisor reasoning step (100–500 tokens)
Sub-agent spawning decision (variable)
Coordination overhead if multiple agents run
Final synthesis step

You've potentially tripled your token spend, and latency scales with the supervisor's decision complexity.

When to Choose Which

Here's the decision framework I use:

Choose static hierarchies when:

Your domain is well-defined and stable
Cost predictability matters more than flexibility
You need deterministic behaviour for compliance/audit
Your team is comfortable maintaining explicit orchestration code

Choose dynamic supervisors when:

Requirements evolve frequently
You're handling truly unpredictable user input
Development velocity matters more than marginal cost
You have robust observability to debug LLM routing decisions

The Observability Problem

Dynamic systems create a new debugging challenge: you're troubleshooting decisions made by a model, not by your code. When a supervisor routes incorrectly, you need:

Full prompt/response logging for every supervisor decision
Structured traces showing which sub-agents were spawned and why
Token usage broken down by orchestration vs. task execution

Without this, you're flying blind. Budget for engineering time to build proper instrumentation—it's not optional.

For teams working on AI automation and software development, investing early in observability patterns for multi-agent systems pays dividends once you're handling production traffic.

A Hybrid Approach

In practice, you don't have to pick one or the other. Consider a tiered model:

Static top-level routing for broad categories (legal, technical, sales)
Dynamic sub-agent spawning within each category for nuanced specialisation

This gives you cost control at the entry point while preserving flexibility where it matters. Your supervisor still makes intelligent decisions, but within a bounded domain that limits runaway token usage.

The Real Question

When building multi-agent systems, the architecture choice boils down to this: are you optimising for developer control or system adaptability?

Static hierarchies give you determinism and debuggability. Dynamic supervisors give you flexibility and emergent capabilities. Neither is inherently better—it depends on your constraints.

If you're still evaluating which pattern fits your use case, the detailed comparison on how one agent learns to delegate walks through cost modelling and reliability trade-offs worth considering before you commit.

One final tip: whichever you choose, start simple. A two-level hierarchy (supervisor + three sub-agents) is easier to reason about than a recursive tree of agents spawning agents. Get the observability and cost monitoring right at two levels before you go deeper.

Your future self—and your AWS bill—will thank you.

MCP vs A2A: Stop Building Agent Architectures Wrong

Marc Newstead — Mon, 22 Jun 2026 09:08:45 +0000

MCP vs A2A: Stop Building Agent Architectures Wrong

If you're wiring up AI agents in production right now, you've probably hit the same confusion I did: when do I use MCP, and when do I need A2A?

Turns out, they're not alternatives. They solve different problems at different layers of your stack. Mixing them up will wreck your architecture before you've shipped v1.

Let me break down what I wish someone had told me three months ago.

MCP: Your Agent Talks to Tools

Model Context Protocol (Anthropic's spec) is about agent-to-tool communication. Think of it as the interface layer between your LLM and the stuff it needs to do things.

When your agent needs to:

Query a database
Call an internal API
Read from a file system
Fetch customer records

...you're in MCP territory.

What MCP Actually Gives You

// MCP server exposes capabilities
const mcpServer = {
  tools: [
    {
      name: "query_customer_db",
      description: "Fetch customer by ID",
      inputSchema: { customerId: "string" }
    }
  ]
};

The protocol standardises how your agent discovers what tools exist, how to invoke them, and how results flow back. It's RPC with schema negotiation baked in.

Crucially: MCP doesn't care about agent autonomy. It's a request-response pattern. Your agent asks, the tool answers. Done.

A2A: Your Agents Talk to Each Other

Agent-to-Agent protocol (Google's answer to multi-agent coordination) operates at a completely different layer. This is about autonomous systems negotiating with each other.

When you need:

A research agent to delegate to a summarisation agent
A planning agent to coordinate with execution agents
Agents to negotiate task ownership
Asynchronous handoffs between agent workflows

...you're in A2A territory.

The Key Difference

A2A assumes both sides have agency. They're not calling dumb tools — they're collaborating with other intelligent systems that have their own goals, context, and decision-making.

# A2A coordination (conceptual)
Agent A -> Agent B: "Can you handle UK tax calculation?"
Agent B -> Agent A: "Yes, send me the transaction data"
Agent A -> Agent B: [structured payload]
Agent B -> Agent A: "Completed. Result: £2,450 VAT due"

Notice the back-and-forth? That's negotiation. MCP doesn't do that.

Why This Matters When You're Building

Here's where teams go wrong: they try to use MCP to wire agents together.

Don't do this:

# Anti-pattern: Agent-to-agent via MCP
mcp_server.register_tool(
    name="call_summarisation_agent",  # ❌ This is an agent, not a tool
    handler=lambda x: summarisation_agent.run(x)
)

Why does this break down?

MCP is synchronous and blocking — agents need async coordination
MCP has no concept of agent state or context handoff
You lose the negotiation layer (what if the agent is busy? unavailable? needs clarification?)

Instead, use MCP to give each agent its own tools, then use A2A (or a message bus, or even HTTP with agent-aware semantics) to let them coordinate.

Better architecture:

┌─────────────────┐         ┌─────────────────┐
│   Agent A       │         │   Agent B       │
│                 │         │                 │
│  ┌───────────┐  │  A2A    │  ┌───────────┐  │
│  │ MCP Tools │  │ ◄─────► │  │ MCP Tools │  │
│  └───────────┘  │         │  └───────────┘  │
└─────────────────┘         └─────────────────┘
       │                           │
       │ MCP                       │ MCP
       ▼                           ▼
   [Database]                  [API]

Each agent gets its own MCP interface to tools. Agents talk to each other via A2A.

What to Do Tomorrow

If you're designing an agentic system:

Map your tool layer first — what external capabilities do agents need? Build MCP servers for those.
Identify agent boundaries — where does one agent's responsibility end and another's begin?
Choose your A2A transport — could be Google's spec, could be a message queue with agent-aware semantics. Just don't use MCP for it.
Keep agents dumb about each other's internals — they should coordinate via high-level intent, not RPC.

The two-layer stack isn't theoretical — it's the separation of concerns your system needs to scale beyond a proof-of-concept.

The Bottom Line

MCP = agent ↔ tool (synchronous, request-response, capability exposure)
A2A = agent ↔ agent (asynchronous, stateful, coordination)

Get this wrong and you'll end up refactoring your entire stack when you need to add agent #3. Get it right and your architecture stays clean as you scale.

If you're building this for real and need architecture help, teams doing serious AI automation and software development are already using this mental model.

Now go build something that doesn't fall over when you add more agents.

Stop Selling AI Projects on Hours Saved (And What to Track Instead)

Marc Newstead — Mon, 15 Jun 2026 09:12:42 +0000

Stop Selling AI Projects on Hours Saved (And What to Track Instead)

You've just shipped an AI feature that automates part of your product workflow. Marketing wants ROI numbers. Your PM asks: "How many hours does this save?"

It's a trap.

Here's why chasing "hours saved" metrics will sabotage your AI projects—and what you should measure instead.

The Problem with Time-Saved Metrics

Let's say you build an AI classifier that auto-tags support tickets. You measure that it saves your support team 30 minutes per day. Ship it, report the win, move on.

Six months later:

The feature is still running
No headcount has been reduced
The support team is just as busy
Finance asks why costs haven't changed

What happened? You optimised for the wrong metric. Time saved doesn't automatically translate to business value—especially when that time gets absorbed by other work, context switching, or simply Parkinson's Law.

Worse, hour-based ROI invites the wrong conversations. Stakeholders hear "we're automating 10 hours a week" and start asking about redundancies. Your engineering work becomes a political minefield instead of a technical improvement.

What Developers Should Measure Instead

Shift your metrics from inputs (time spent) to outcomes (results achieved). Ask: what is this process actually supposed to accomplish?

Let's revisit that support ticket classifier:

Time-saved framing:

"Saves 30 minutes of manual tagging per day"

Outcome-based framing:

"Reduces average ticket resolution time by 18%"
"Increases first-response accuracy from 73% to 91%"
"Decreases ticket escalations by 40%"

See the difference? The second set of metrics connects directly to what the business cares about: faster support, happier customers, fewer escalations.

Practical Examples by Domain

Here's how this translates across common automation scenarios:

Code review automation:

❌ "Saves 2 hours per week reviewing PRs"
✅ "Reduces time-to-merge by 35%, catches 60% more style issues pre-review"

Content moderation ML:

❌ "Automates 1000 moderation decisions daily"
✅ "Reduces harmful content visibility by 80%, decreases appeal rate by 25%"

Inventory forecasting:

❌ "Saves data team 5 hours weekly on reports"
✅ "Reduces stockouts by 45%, decreases overstock by 30%"

Building This Into Your Workflow

The trick is defining success criteria before you write any code. Here's a lightweight framework:

1. Start with the Business Outcome

Before the sprint starts, write down:

What specific outcome are we trying to improve?
How is it measured today?
What's the baseline metric?

# Document this in your ADR or project brief
BASELINE_METRICS = {
    "ticket_resolution_time_p50": 4.2,  # hours
    "first_response_accuracy": 0.73,
    "escalation_rate": 0.18
}

TARGET_OUTCOMES = {
    "ticket_resolution_time_p50": 3.5,  # 15% improvement
    "first_response_accuracy": 0.85,    # 12pp improvement
    "escalation_rate": 0.12             # 6pp improvement
}

2. Instrument for Outcomes, Not Activity

Your telemetry should track results, not just usage.

// Less useful
logger.info('AI classifier invoked', { ticketId });

// More useful
logger.info('Ticket resolved', {
  ticketId,
  resolutionTimeMinutes,
  autoTagAccuracy,
  escalated: false,
  aiAssisted: true
});

3. Compare Before/After, Control/Treatment

Run A/B tests where possible. Roll out gradually and measure the delta:

50% of tickets use AI tagging, 50% don't
Compare resolution times, accuracy, escalations
Ship to 100% only if outcomes improve

Why This Matters for Your Career

As a developer, learning to frame your work in business outcomes—not just technical achievements—is a force multiplier. It makes your projects easier to fund, easier to defend, and much harder to cut when budgets tighten.

The companies getting AI automation and software development right aren't the ones chasing headcount reduction. They're the ones connecting automation directly to revenue, customer satisfaction, or strategic goals.

If you're presenting AI work to non-technical stakeholders, skip the "hours saved" pitch. Show them outcomes, not hours saved, and watch the conversation shift from "can we afford this?" to "how fast can we scale it?"

Quick Takeaways

Time saved ≠ value delivered. Hours are an input; outcomes are what matter.
Define success metrics before you code. Baseline, target, measurement strategy.
Instrument for business outcomes, not just feature usage. Track resolution time, accuracy, customer impact.
Use A/B testing to prove the delta. Control groups make ROI undeniable.
Frame your work in business terms. It makes you a more effective engineer and a better communicator.

Your AI feature might save time—but if you can't connect it to a better outcome, you're building on sand.

Building Persistent AI Agents: A Dev's Guide to State Management and Long-Running Workflows

Marc Newstead — Mon, 15 Jun 2026 09:10:05 +0000

The Problem with Stateless Agents

Most AI agents we build today are essentially fancy request-response systems. User asks, agent responds, context dies. Rinse and repeat. But what happens when you need an agent that can start a workflow on Monday, wait for external approval on Wednesday, and resume execution on Friday — all while maintaining perfect context?

That's the shift from chatbots to persistent agents. And it changes everything about how we architect AI systems.

What Makes an Agent "Persistent"?

A persistent agent isn't just a chatbot with better memory. It's a system that:

Maintains state across sessions — not just conversation history, but workflow position, pending actions, and decision context
Can pause and resume — waiting on external events, human input, or scheduled triggers without losing its place
Initiates actions autonomously — checking conditions, triggering workflows, and making decisions without explicit user prompts
Recovers gracefully — handling failures, retries, and state corruption without manual intervention

Think less "chat interface" and more "background worker with reasoning capabilities".

The Hard Part Isn't the LLM Calls

Here's what surprised me: building the agent logic itself is relatively straightforward. Frameworks like LangGraph, CrewAI, and AutoGen handle the orchestration. Calling GPT-4 or Claude is trivial. Integrating tools and APIs is just... normal backend work.

The hard part is state management.

State Storage: More Than Just JSON

You need to persist:

{
  "workflow_id": "claim_review_001",
  "current_step": "awaiting_manager_approval",
  "context": {
    "claim_amount": 1250,
    "supporting_docs": [...],
    "previous_decisions": [...]
  },
  "pending_actions": [
    {"type": "wait_for_approval", "timeout": "2024-02-15T17:00:00Z"}
  ],
  "llm_state": {
    "reasoning_trace": [...],
    "tool_call_history": [...]
  }
}

But here's the thing: this state evolves. The agent needs atomic updates. You need versioning for rollbacks. You need to handle concurrent modifications if multiple agents or humans interact with the same workflow.

Suddenly you're designing a state machine with persistence, not just prompt engineering.

Interruption as a First-Class Concept

In traditional software, interruption is an exception case. In persistent agents, interruption is the normal case.

Your agent will:

Pause to wait for human approval
Stop because a rate limit was hit
Yield while waiting for an external system
Get interrupted because a higher-priority task arrived

Each interruption point needs explicit handling:

def process_claim_step(state):
    if state.requires_human_review():
        return PauseState(
            resume_trigger="approval_received",
            context=state.to_dict(),
            timeout_hours=72
        )
    # Continue processing...

You're not building a linear function anymore. You're building a resumable state machine.

Human-in-the-Loop Isn't Optional

For any agent doing real work — approving expenses, modifying production data, sending customer communications — human oversight isn't a nice-to-have. It's regulatory, ethical, and practical table stakes.

But "human-in-the-loop" means different things:

Approval gates — agent pauses, human approves/rejects, agent continues
Suggested actions — agent proposes, human edits, agent executes
Monitoring dashboards — humans can intervene at any point

This isn't a UI concern. It's an architectural decision that affects your state model, your event system, and your error handling.

If you're building systems that blend AI automation and software development, you need to design for human intervention from day one, not bolt it on later.

Observability Gets Weird

How do you debug an agent that's been running for three days and is currently paused?

Your standard APM tools won't help. You need:

Workflow visualisation — where is each agent in its process?
State inspection — what decisions has it made? What's it waiting for?
Reasoning traces — why did it take action X instead of Y?
Replay capability — can you rerun from a checkpoint with different conditions?

Logging becomes critical. Every LLM call, every tool invocation, every state transition needs to be traceable.

Where to Start

If you're building your first persistent agent:

Choose a state backend early — Redis, PostgreSQL, or a proper workflow engine like Temporal
Design your state schema first — before you write agent logic
Build pause/resume into every step — don't assume linear execution
Make state transitions explicit — log everything, version your state
Test interruption scenarios — not just happy paths

The Shift in Thinking

Persistent agents force us to think differently. We're not building APIs or microservices anymore. We're building systems that think in the background — agents that are always on, always aware, and always ready to pick up where they left off.

The code isn't harder. The architecture is just... different. And that's the real challenge.

Stop Measuring AI Features By Hours Saved (Measure This Instead)

Marc Newstead — Mon, 08 Jun 2026 09:12:39 +0000

The "Time Saved" Trap We Keep Falling Into

You've just shipped an AI feature. Your manager asks: "How much time does this save users?"

It sounds reasonable. We're engineers — we optimise for efficiency. But this question often leads us to build the wrong thing and measure what doesn't matter.

I've watched teams spend months building AI tools that technically saved hours but delivered zero business value. The feature worked. The metrics looked good. Nobody used it after the first week.

Here's why measuring outcomes not hours matters more than you think — and how to instrument for it from day one.

Why "Hours Saved" Breaks Your Decision-Making

The labour-hour metric made sense when automation meant replacing repetitive tasks. If your script processes 1,000 invoices instead of a human spending 40 hours doing it, the maths is simple.

But modern AI features don't work like that. They:

Augment decisions (suggesting code completions, not writing entire apps)
Enable new workflows (analysis that wasn't feasible manually)
Shift quality, not just speed (better detection, fewer false positives)

When you measure a code completion tool by "time saved typing", you miss that its real value might be:

Reducing context-switching by keeping developers in flow
Lowering the barrier for junior devs to write idiomatic code
Decreasing cognitive load during complex refactors

None of those show up in a time-saved metric. Worse, optimising for time-saved might lead you to auto-complete aggressively when developers actually want suggestions that help them think, not type faster.

What to Measure Instead: Outcomes Engineers Can Instrument

Shift your instrumentation to capture what changed, not just what was faster.

Example: AI-Powered Code Review Assistant

Don't measure: "Saved 15 minutes per PR review"

Do measure:

Defect escape rate (bugs reaching production)
Time-to-merge for PRs of similar complexity
Reviewer confidence scores (post-merge survey)
Rate of AI suggestions accepted vs. dismissed

Example: Automated Customer Query Classifier

Don't measure: "Replaced 10 hours/week of manual tagging"

Do measure:

First-response accuracy (correct routing)
Customer satisfaction with resolution
Escalation rate to human agents
Query resolution time end-to-end

The Pattern

For any AI feature, ask:

What business outcome does this enable? (faster deployments, fewer incidents, better conversion)
What baseline exists? (instrument before you ship)
What proxy metrics indicate progress? (leading indicators you can measure weekly)

Instrumenting for Outcomes From Day One

This is where most teams fail: they bolt on measurement after launch. You can't retrofit a baseline.

Pre-Launch Checklist

# Pseudocode: What your instrumentation might look like

class AIFeatureMetrics:
    def __init__(self, feature_name):
        self.feature = feature_name

    def log_interaction(self, user_id, action, context):
        """
        Log every meaningful interaction:
        - What did the AI suggest?
        - What did the user do with it?
        - What was the context? (task type, user experience level)
        """
        event = {
            'timestamp': now(),
            'feature': self.feature,
            'user': user_id,
            'action': action,  # accepted, rejected, modified
            'context': context,
            'outcome': None  # filled in later
        }
        self.event_store.append(event)

    def link_to_outcome(self, interaction_id, outcome_metric):
        """
        Connect the AI interaction to business outcome:
        - Did the PR with AI suggestions have fewer bugs?
        - Did the AI-routed ticket resolve faster?
        """
        self.event_store.update(interaction_id, outcome=outcome_metric)

Key principle: Capture the interaction and the eventual outcome. This lets you correlate AI assistance with business results.

Making This Work in Practice

For teams working on AI automation and software development, here's the tactical approach:

1. Define Success Before You Code

Write your "definition of done" to include outcome metrics:

## Feature: AI-Powered Incident Classifier

**Success criteria:**
- 80% of incidents routed to correct team (up from 65% baseline)
- Mean-time-to-engagement decreases by 20%
- On-call satisfaction score maintained or improved

**NOT success:**
- "Saves 5 hours/week of manual classification"

2. Build a Baseline Period

Run your instrumentation for 2-4 weeks before enabling the AI feature. You need the counterfactual.

3. Plan Your Feedback Loop

How will you know if outcomes improve?

Weekly cohort analysis (users with AI vs. without)
Monthly business metric reviews
Qualitative feedback sessions (what changed in practice?)

The Bottom Line

Hours saved is easy to measure but often meaningless. Outcomes are harder to instrument but tell you whether you built the right thing.

As engineers, we control the telemetry. Instrument for outcomes from day one, and you'll ship AI features that actually matter.

What outcome metrics are you tracking for your AI features? Let's discuss in the comments.

Stop Using One LLM for Everything: A Dev's Guide to Model Routing

Marc Newstead — Mon, 08 Jun 2026 09:10:08 +0000

The Problem With Your Current LLM Stack

If you're sending every prompt through GPT-4 or Claude Opus because "it's the best model", you're probably burning money on overkill. Classifying a support ticket's sentiment doesn't need the same horsepower as generating a product requirements document. Yet most codebases I see treat LLM calls like they're all created equal.

Model routing solves this. Instead of one model for everything, you dynamically select which model handles each task based on complexity, cost, and latency requirements. Think of it as load balancing, but for intelligence.

What Model Routing Actually Looks Like

At its core, a router is middleware between your app and your LLM providers. Here's the mental model:

def route_llm_request(task):
    complexity = analyse_task(task)

    if complexity == "simple":
        return call_model("gpt-3.5-turbo", task)
    elif complexity == "moderate":
        return call_model("claude-haiku", task)
    else:
        return call_model("gpt-4", task)

Obviously production implementations get more sophisticated, but the principle holds: inspect the task, pick the cheapest model that can handle it reliably.

Mapping Tasks to Models

The hard part isn't the routing logic—it's building a sensible taxonomy of your tasks. Start by auditing what you're actually sending to LLMs:

Classification tasks: Intent detection, sentiment analysis, category assignment. These are often binary or multi-class decisions. GPT-3.5-turbo or even GPT-4o-mini handles these beautifully at a fraction of the cost.
Retrieval-augmented generation: Answering questions from your docs. Moderate complexity. Models like Claude Haiku or Gemini Flash offer solid performance without flagship pricing.
Content generation: Drafting emails, writing code, creating marketing copy. This is where you might actually need GPT-4 or Claude Opus—but only when the stakes justify it.
Structured extraction: Pulling entities from text, parsing invoices. If you can define a JSON schema, smaller models work fine, especially with function calling.

The key insight: most applications have a long tail of simple tasks subsidising a small number of complex ones. Route accordingly.

Tracking the Wins

You need telemetry. Log every routing decision with:

{
  taskId: uuid(),
  taskType: "classification",
  modelSelected: "gpt-3.5-turbo",
  tokens: 150,
  cost: 0.0003,
  latency: 420,
  timestamp: Date.now()
}

After a week, aggregate this. You'll likely find:

70%+ of requests are simple and could use cheaper models
Your highest costs come from 5-10% of requests
Latency improves because smaller models are faster

One team I worked with cut their monthly LLM bill by 60% just by routing classification and extraction tasks away from GPT-4. The business logic didn't change—just the infrastructure underneath.

Fallback Strategies and Provider Diversity

Routing also gives you resilience. If OpenAI's API goes down (and it will), your router can failover to Anthropic or Gemini. This requires:

Normalised interfaces: Abstract provider-specific SDKs behind a common interface
Retry logic: Catch rate limits and failures, try the next model in your tier
Circuit breakers: Temporarily skip a provider if it's consistently failing

def call_with_fallback(task, models_list):
    for model in models_list:
        try:
            return call_model(model, task)
        except ProviderError:
            continue
    raise AllProvidersFailed()

This multi-provider approach also dodges vendor lock-in. When you're not married to a single API, you can negotiate better pricing and adopt new models faster.

Getting Started

You don't need to build a Netflix-scale routing system on day one. Start simple:

Categorise your prompts. Spend an afternoon tagging a sample of requests by complexity.
Benchmark models on each category. Test accuracy, cost, and latency.
Implement a basic router. Even a hardcoded if/else saves money immediately.
Instrument everything. You can't optimise what you don't measure.
Iterate. Add more sophisticated routing rules as your usage patterns emerge.

For a deeper dive into the strategic thinking behind this approach, the team at AI automation and software development have a solid write-up on deploying LLMs at scale that's worth reading.

The Bottom Line

Using one model for everything is like running every database query against your production master. Sure, it works—but it's wasteful and fragile. Model routing gives you cost control, performance headroom, and architectural flexibility.

Start small, measure everything, and let the data guide your routing decisions. Your infrastructure budget will thank you.

Why Your RPA Bot Keeps Breaking: A Process Mining Reality Check

Marc Newstead — Mon, 01 Jun 2026 16:07:47 +0000

Why Your RPA Bot Keeps Breaking: A Process Mining Reality Check

You've just shipped an RPA bot that automates invoice processing. It worked perfectly in UAT. Two weeks into production, it's failing 40% of the time. Sound familiar?

The culprit isn't your code—it's process variance you never knew existed. This is where process mining stops being a cool dashboard and becomes actual engineering work.

What Process Mining Actually Shows You

Process mining tools (SAP Signavio, Celonis, etc.) ingest event logs from your ERP, CRM, or whatever system you're working with. They reconstruct what actually happens versus what the process documentation claims happens.

Here's a real example from a warehouse management system integration I worked on:

Expected process:

Order Created → Picked → Packed → Shipped → Invoiced

What the event logs showed:

Order Created → Picked → Packed → Shipped → Invoiced (62% of cases)
Order Created → Picked → Packed → Invoiced → Shipped (23%)
Order Created → Invoiced → Picked → Packed → Shipped (8%)
Order Created → Split → Picked (partial) → ... (7% chaos)

That 38% variance? That's why your automation breaks. The bot was coded for the happy path. The business swore that was the only path.

The Gap Between "Should" and "Does"

This delta is called a conformance gap. As developers, we encounter this constantly:

API documentation says the field is required, but 15% of records have it null
The procurement process "always" requires three approvals, except when someone with director-level access shortcuts it
Purchase orders "must" be created before goods receipt, but half your warehouses do it backwards

Process mining makes these gaps visible at scale. The problem is that discovering them is the easy part. The real work begins when you have to fix them.

Why This Matters for Automation Projects

Every process variant you don't account for is a potential failure mode. Consider this:

# What you wrote
def process_invoice(invoice):
    validate_po(invoice.po_number)
    check_three_way_match(invoice, po, goods_receipt)
    post_to_ledger(invoice)

# What actually needs to happen
def process_invoice(invoice):
    if invoice.po_number:
        validate_po(invoice.po_number)
        if goods_receipt_exists(invoice.po_number):
            check_three_way_match(invoice, po, goods_receipt)
        else:
            # Handle 12% of cases where GR comes later
            flag_for_manual_review(invoice)
    else:
        # Handle 8% of non-PO invoices
        route_to_exception_queue(invoice)

    post_to_ledger(invoice)

The difference between these two implementations is whether your automation has a 70% success rate or a 95% success rate.

The Developer's Role After Discovery

Once you've got process mining data, here's what actually needs doing:

1. Variant Analysis and Prioritisation

You can't code for every edge case. Use Pareto principle:

Handle the top 3–5 variants that cover 80%+ of volume
Build exception queues for the rest
Don't try to automate the 2% of cases that involve manual overrides from the CFO

2. Root Cause Investigation

Why does the variant exist?

System limitation: Legacy system doesn't enforce order, need middleware
Legitimate business reason: Expedited orders follow different path
Workaround: Users circumventing a broken approval flow
Training gap: New hires don't know the standard process

Only the first two belong in your code. The others need process fixes.

3. Design for Observable Variance

Build your automation to log which variant it's processing:

logger.info(f"Processing invoice {inv.id} via variant: {variant_type}")
metrics.increment(f"invoice.variant.{variant_type}")

This gives you telemetry when new variants emerge (and they will).

Where Consultancies Come In

SAP and Celonis will sell you the mining tool. They won't:

Interview stakeholders to understand why variants exist
Redesign broken approval workflows
Mediate between finance and operations when their processes conflict
Retrain users or update documentation

That's consulting work. If you're at an agency focused on AI automation and software development, this is where you add value—bridging the gap between what the data shows and what engineering can actually automate.

Bottom Line

Process mining is brilliant for surfacing the mess. But turning those insights into stable, production-grade automation requires:

Engineering rigour to handle variants gracefully
Business analysis to fix what can be standardised
Operational discipline to maintain conformance over time

The ML model that predicts process outcomes is impressive. The unglamorous work of handling the "invoiced before shipped" edge case? That's what keeps your bot running in production.

Don't confuse deploying a tool with solving the problem.

So Your Company Wants Multi-Agent AI Systems. Who's Actually Going to Build Them?

Marc Newstead — Mon, 01 Jun 2026 09:11:47 +0000

So Your Company Wants Multi-Agent AI Systems. Who's Actually Going to Build Them?

I've been watching a strange pattern emerge across enterprise engineering teams: everyone's excited about multi-agent AI systems, but nobody's quite sure who owns them.

Your backend team says it's an architecture problem. Your ML engineers say they build models, not workflows. Your DevOps team is already drowning. And your product managers are drawing diagrams with arrows between cartoon robots, hoping someone will make it real.

Welcome to the emerging role of the AI Workflow Architect — and if you've never heard of it, you're not alone.

What This Actually Looks Like in Practice

Let me paint a concrete scenario. You're building a customer support system where:

Agent A monitors incoming tickets and classifies urgency
Agent B pulls relevant documentation and past tickets
Agent C drafts responses
Agent D decides whether to auto-send or escalate to humans
Agent E learns from human edits and feeds back to the others

Now here's the fun part: who designs the handoff protocols? Who decides Agent D's confidence threshold? Who debugs it when Agent C starts hallucinating because Agent B fed it corrupted context? Who ensures Agent A doesn't create a bias feedback loop?

This isn't just "prompt engineering at scale." It's systems architecture, but the components are non-deterministic and the failure modes are bizarre.

The Skills Cocktail Nobody Teaches

The tricky bit is that AI Workflow Architects need a frankly weird combination of skills:

Systems Design: You need to think in state machines, event-driven architectures, and async patterns. If you've designed microservices, you're halfway there — except these services occasionally make things up.

Observability Expertise: Traditional logging won't cut it. You need to trace decisions across multiple agents, capture prompt/response pairs, and understand where in a 6-agent chain something went sideways.

Process Mapping: Yes, the boring business analyst skill. Because before you automate a workflow, you need to understand what humans actually do (versus what they say they do).

Risk Assessment: When Agent D auto-approves a refund, who's liable? What's the blast radius if Agent A misclassifies 1,000 tickets? You're designing systems that take actions, not just make predictions.

Here's the problem: no bootcamp teaches this. No degree covers it. The people doing this work now are usually:

Senior backend engineers who got curious about LLMs
Solutions architects who've been burned by bad automation
That one DevOps person who actually reads the logs

What This Looks Like in Code Terms

A simplified mental model:

class WorkflowOrchestrator:
    def __init__(self):
        self.agents = self.load_agents()
        self.state_machine = self.define_transitions()
        self.audit_log = AuditLogger()
        self.circuit_breakers = CircuitBreakerRegistry()

    async def execute(self, input_data):
        state = WorkflowState(input_data)

        while not state.is_terminal():
            agent = self.route_to_agent(state)

            # This is where it gets interesting
            with self.observe(agent, state) as trace:
                result = await agent.process(state)

                if not self.validate_output(result):
                    # What happens here? Retry? Escalate? Log and continue?
                    await self.handle_invalid_output(agent, result, trace)

                state = state.transition(result)
                self.audit_log.record(state, result, trace)

        return state.output

The devil's in those commented lines. Traditional error handling assumes deterministic failures. Agent failures are... squishy.

Why This Matters Now

We're at an inflection point. Two years ago, "AI in production" meant serving a model behind an API. Now it means coordinating multiple models, traditional services, human-in-the-loop interventions, and decision trees that adapt based on outcomes.

Most UK organisations are either:

Building this ad-hoc with whoever's available (usually overloaded senior engineers)
Not building it at all, despite the hype
Outsourcing to agencies specialising in AI automation and software development to bridge the gap

What You Can Do About It

If you're a mid-to-senior engineer who enjoys systems thinking, this is a genuinely interesting career direction. Here's how to position yourself:

Build something multi-agent (even a toy project) and document what went wrong
Study observability patterns — OpenTelemetry, distributed tracing, that stuff you've been meaning to learn
Get comfortable with business process mapping — yes, really. BPMN isn't sexy but it's useful
Learn prompt engineering — not as the end goal, but as a tool in a larger system

The companies that figure this out early will have a significant advantage. The engineers who can bridge this gap will be bloody hard to replace.

And if your company's just added "implement AI agents" to the backlog without assigning a clear owner? Well, that's your opening.

The EU AI Act Is Shifting — Here's What It Means for Your Codebase

Marc Newstead — Mon, 01 Jun 2026 09:09:04 +0000

The EU AI Act Is Shifting — Here's What It Means for Your Codebase

If you've been tracking the EU AI Act, you probably pencilled in August 2026 as the date when certain systems would need to be compliant. That timeline is now looking less certain. Brussels is floating changes through something called the Digital Omnibus Package, and UK teams are stuck in an especially awkward position — no UK-specific AI law, no clarity on whether to follow EU rules, and compliance work already underway.

So what should you actually do about it?

The Omnibus Isn't a Repeal — It's a Tweak

First, let's get the framing right. The Digital Omnibus isn't scrapping the AI Act. It's recalibrating parts of it in response to competitiveness concerns, particularly from SMEs who feel the compliance burden is disproportionate.

What does that mean in practice? Possibly lighter requirements for some model providers,延extended grace periods, or narrower definitions of "high-risk" systems. The core intent — transparency, accountability, risk management — isn't going away.

For developers, this is important context. If you've been working on compliance tooling, audit logs, model cards, or risk documentation, that work isn't wasted. The deadlines may shift, but the direction of travel remains the same.

The UK Position: Deliberately Vague

The UK has explicitly avoided EU-style legislation. Instead, it's gone for a "principles-based, sector-led" approach — which in developer terms means: no single rulebook, no clear deadline, and plenty of room for interpretation.

But here's the catch. If you're building software that:

Serves EU users or customers
Integrates with EU-based systems
Uses foundation models trained or hosted in the EU
Operates in regulated sectors (finance, health, recruitment)

...then the EU AI Act probably applies to you anyway, regardless of where your servers are.

So the UK's ambiguity doesn't buy you much. If anything, it means you need to stay across both jurisdictions.

Why "Wait and See" Is the Wrong Move

The temptation right now is to pause compliance work until the dust settles. Understandable, but risky.

Here's why:

1. The fundamentals won't change

Even if the Omnibus softens certain obligations, the technical requirements around logging, transparency, and testing are baked into good engineering practice anyway. If you're building production AI systems, you should already be doing this stuff.

2. Procurement and contracts are moving faster than regulation

Your customers — especially in enterprise or public sector — are already asking compliance questions in RFPs. They're not waiting for final rules. If you can't demonstrate basic governance, you'll lose deals.

3. Technical debt compounds

Retrofitting compliance into a system is far harder than building it in from the start. If you wait until the regulation is finalised, you'll be scrambling to bolt on audit trails, explainability hooks, and data lineage tracking. That's expensive and brittle.

For a deeper dive on the regulatory landscape, the deadline is shifting in ways that warrant recalibration, not paralysis.

What to Do Instead: Recalibrate, Don't Restart

If you've already started compliance work, don't throw it out. Instead, focus on no-regret moves — things that improve your system regardless of regulatory outcome.

Prioritise foundational capabilities:

Structured logging for model decisions

If your model makes a decision (e.g. credit scoring, CV filtering), log it with context: input features, model version, timestamp, output, confidence.
Version control for models and datasets

Treat models like code. Git for weights, DVC for datasets, MLflow or similar for experiment tracking.
Human-in-the-loop hooks

Build affordances for human review or override, even if they're not always used. It's much easier to expose a UI element than to redesign your inference pipeline later.
Documentation as code

Model cards, datasheets, risk assessments — write them in Markdown, version them in Git, publish them automatically. Make governance a first-class part of your CI/CD pipeline.

These aren't just compliance theatre. They make your system more maintainable, auditable, and debuggable.

The Bottom Line

Regulatory uncertainty is uncomfortable, but it's not an excuse to do nothing. The EU AI Act's direction is clear, even if the details are in flux. And if you're in the UK, you're not off the hook — you're just operating in a more ambiguous environment.

The smart play is to treat compliance as an engineering quality concern, not a legal checkbox. Build systems that are transparent, explainable, and auditable because those are good systems, not just because Brussels says so.

If you're working on these challenges and need support with AI automation and software development, you're not alone. This is a moving target for everyone.

But the teams who ship thoughtfully now will be in a much stronger position than those who wait for perfect clarity that may never come.

Why Your Image Upload Pipeline Should Check for Physically Impossible Lighting

Marc Newstead — Mon, 18 May 2026 11:10:19 +0000

Why Your Image Upload Pipeline Should Check for Physically Impossible Lighting

If you're building user-generated content platforms, marketplace verification systems, or anything that ingests images from untrusted sources, you've probably noticed the synthetic media problem getting worse. Gen-AI tools have become good enough that casual users can't spot the fakes anymore.

But here's the thing: the physics still breaks. And if you know what to look for, you can build surprisingly effective validation layers using simple computer vision techniques.

The Shadow Problem: Your First Line of Defence

In any real photograph, shadows share a common light source geometry. This is basic physics—light travels in straight lines. When AI image generators compose scenes from learned patterns rather than simulated physics, they consistently mess this up.

Here's what you can check programmatically:

1. Shadow Direction Consistency

Extract shadow vectors across different objects in the scene. In a genuine photo, these should converge toward a common vanishing point (the light source).

# Pseudocode for shadow vector analysis
def analyse_shadow_consistency(image):
    objects = segment_objects(image)
    shadow_vectors = []

    for obj in objects:
        if obj.has_shadow():
            vector = calculate_shadow_angle(obj, obj.shadow)
            shadow_vectors.append(vector)

    # Check if vectors converge within tolerance
    convergence_score = calculate_convergence(shadow_vectors)
    return convergence_score > THRESHOLD

This won't catch everything, but it'll flag a surprising number of AI-generated images, especially from earlier-generation models or rushed prompts.

2. Shadow Intensity Relative to Distance

Shadows should soften and lighten with distance from the object casting them. AI generators often produce shadows with uniform intensity throughout, or inconsistent softness between objects at similar distances.

You can measure this with edge detection and gradient analysis across shadow boundaries.

Reflection Geometry: The Silent Tell

Reflections are even harder for generators to get right. Water reflections, glass surfaces, and metallic objects all follow strict geometric rules.

What to check:

Reflections should be vertically symmetrical (for horizontal surfaces)
Reflection angles must match viewing angles
Environmental lighting in reflections should match the scene lighting

A simple geometric validation:

def validate_reflection(surface_region, reflected_region):
    # Extract key points from both regions
    surface_features = extract_keypoints(surface_region)
    reflection_features = extract_keypoints(reflected_region)

    # Check if reflection obeys mirror symmetry
    symmetry_score = calculate_mirror_symmetry(
        surface_features, 
        reflection_features
    )

    return symmetry_score > MIN_SYMMETRY_THRESHOLD

Where This Actually Matters in Production

If you're building:

Marketplace verification systems — Preventing fake product photos that don't represent real inventory. One e-commerce platform I know ran into this when sellers started using AI to generate "lifestyle" product shots that looked professional but didn't match the actual items.

Content moderation pipelines — Flagging synthetic profile pictures in identity verification flows, or detecting manipulated images in insurance claims.

Media asset management — Automatically tagging AI-generated images in your DAM system so teams know what they're working with.

You don't need perfect detection. You need a confidence score that feeds into your review queue prioritisation.

The Detection Tool Ecosystem

Before you roll your own, know what exists:

Hive Moderation and Illuminarty offer API-based detection with probabilistic scoring
Google's SynthID watermarks AI-generated content at generation time (only useful if the generator cooperates)
Open-source models like the ones from Hugging Face give you full control but require more infrastructure

These tools are useful as part of a layered approach, but they're not silver bullets. False positive rates are still high enough that you'll need human review for edge cases.

For a deeper look at the specific physical tells and how they manifest across different generators, spotting AI-generated imagery has become a critical organisational competency.

Building a Practical Validation Layer

Here's a sensible architecture:

Fast rejection filters — Basic checks for impossible lighting/shadows using CV libraries (OpenCV, scikit-image)
API-based scoring — Send suspicious images to a detection service
Human review queue — Images above a certain suspicion threshold get reviewed
Feedback loop — Feed confirmed cases back into your filters

async def validate_uploaded_image(image_file):
    # Layer 1: Fast physics checks
    physics_score = await check_lighting_consistency(image_file)

    if physics_score < 0.3:  # Clearly fake
        return {"status": "rejected", "reason": "lighting_anomaly"}

    if physics_score > 0.8:  # Probably real
        return {"status": "approved", "confidence": physics_score}

    # Layer 2: API-based detection for ambiguous cases
    api_score = await detection_service.analyse(image_file)

    if api_score < 0.5:
        return {"status": "review_queue", "scores": {"physics": physics_score, "api": api_score}}

    return {"status": "approved", "confidence": min(physics_score, api_score)}

The Bottom Line

You can't stop AI-generated images from being uploaded. But you can build systems that flag the physically impossible ones before they cause problems downstream. If you're working on platforms where image authenticity matters—or you're helping clients navigate this space through AI automation and software development—basic physics checks should be in your validation pipeline.

The generators will get better. But until they're simulating actual light physics rather than pattern-matching, the tells will remain.

Stop Optimising for One Search Algorithm — You Need Three in 2025

Marc Newstead — Mon, 18 May 2026 11:04:07 +0000

The search layer cake nobody warned you about

If you've built anything user-facing in the last 18 months, you've probably noticed something weird: classic Google search still exists, but so do AI Overviews. And ChatGPT. And Perplexity. And whatever Bing is calling their AI feature this week.

Here's the bit that matters for us as developers: you're now optimising for three distinct layers of search, not one. Classic SEO still matters. Answer Engine Optimisation (AEO) is a thing. And Generative Engine Optimisation (GEO) — making your content LLM-friendly — is rapidly becoming table stakes.

Ignore any one of these and you're leaving traffic (and revenue) on the table. The good news? A lot of this is automatable. The bad news? Most teams are still pretending it's 2019.

Why classic SEO isn't dead (and won't be)

Let's get the obvious out of the way: traditional SEO fundamentals still matter.

Core Web Vitals haven't gone anywhere
Structured data still helps crawlers parse your pages
Backlink authority is alive and well
Mobile responsiveness is non-negotiable

If your Lighthouse scores are in the red or your robots.txt is blocking half your site, no amount of AI magic will save you. Google's crawlers need to index your content before any algorithm — classic or generative — can surface it.

The mistake teams make is treating SEO as only this. It's necessary, but no longer sufficient.

AEO: structured answers for featured snippets and voice

Answer Engine Optimisation is about formatting content so it can be extracted cleanly as a standalone answer. Think:

FAQ schema that actually answers the question in the markup
Concise <h2> headings that mirror user queries
Tables and lists that are trivial to parse

Example: instead of burying your API rate limits in prose, do this:

## What are the API rate limits?

- Free tier: 100 requests/hour
- Pro tier: 10,000 requests/hour
- Enterprise: Custom limits

This works for featured snippets, voice assistants, and — crucially — gets picked up cleanly by LLM crawlers. Which brings us to layer three.

GEO: making your content LLM-legible

Generative Engine Optimisation means writing and structuring content so LLMs can cite it accurately. A few practical tactics:

Use explicit attributions. "According to [Your Company], the median API latency is 120ms." LLMs love citations they can quote.
Front-load key facts. Don't bury your lede six paragraphs down. Put the answer in the first 100 words.
Avoid jargon overload. LLMs are trained on the web; niche terminology without context confuses them.
Link internally with descriptive anchor text. "See our authentication guide" beats "click here."

If you want to go deeper on the strategic layer, there's a solid overview of AI-driven SEO that covers the business case.

What this looks like in practice

Let's say you're documenting a new SDK. Here's the old way:

"Our SDK provides a robust interface for interacting with the platform, offering flexibility and performance."

Here's the new way:

How do I install the Python SDK?

Install via pip:
pip install your-sdk
Supports Python 3.8+. Typical installation takes under 30 seconds.

The second version works for classic SEO (keyword-rich headings), AEO (structured Q&A), and GEO (clear, quotable answer). One piece of content, three optimisation layers satisfied.

Tooling that actually helps

You don't need a seven-figure MarTech stack to do this. A few categories worth exploring:

Schema validators (Google's Rich Results Test, Schema.org validator)
Content analysis tools that flag vague language or poor structure
AI-powered SEO platforms that surface keyword gaps and suggest schema improvements

If you're working with a team that spans AI automation and software development, ask them to audit your content pipeline. Most of this is scriptable.

The metrics trap

One last thing: rankings are now a lagging indicator. A page can rank #1 and still see click-through rates collapse because an AI Overview answered the query above the fold.

Track:

Impressions vs. clicks (CTR decay is your canary)
LLM citation frequency (some tools now track this)
Conversion rates, not just rankings

If your content is good enough to be cited by ChatGPT but your site never gets the click, you've got a GEO problem — or a business model problem.

TL;DR

Classic SEO fundamentals (Core Web Vitals, schema, backlinks) are still essential
AEO means structuring content as extractable answers (FAQ schema, lists, tables)
GEO means writing so LLMs can cite you accurately (front-load facts, use attributions)
One piece of content can satisfy all three layers if you write it right
Track CTR and conversions, not just rankings

The search landscape fragmented. Your optimisation strategy should reflect that — or you'll spend 2025 wondering where your traffic went.

Your Website's Content Now Has Two Jobs: Feeding Crawlers and Training LLMs

Marc Newstead — Mon, 18 May 2026 10:47:21 +0000

Your Website's Content Now Has Two Jobs: Feeding Crawlers and Training LLMs

If you've built a documentation site, marketing platform, or content-heavy application recently, you've probably optimised for Google's crawlers—structured data, semantic HTML, decent page speed, sensible meta tags. Job done, right?

Not anymore.

Google's AI Overviews (and similar LLM-powered search features from Bing, Perplexity, and others) are now extracting, synthesising, and presenting your content without sending users to your site. Your carefully crafted landing pages might be cited in an AI-generated summary, but the click? Gone.

This isn't theoretical. Organic click-through rates are dropping. The real battle for UK search visibility isn't just about ranking #1 anymore—it's about being the source LLMs choose to cite.

What Changed: From PageRank to Prompt Context

Traditional SEO was a game of signals: backlinks, domain authority, keyword density, Core Web Vitals. You knew the rules. You played by them.

Generative Engine Optimisation (GEO) is different. LLMs don't "crawl" in the same way. They're trained on massive corpora, then retrieve and synthesise information at inference time. The question isn't "Does this page rank?" but "Does this content get selected as context for the LLM's response?"

Think of it like this:

# Traditional SEO
def get_search_results(query):
    pages = index.find(query)  # crawled, indexed, ranked
    return sorted(pages, key=lambda p: p.pagerank)

# GEO / LLM-powered search
def get_ai_overview(query):
    context = retrieval_model.fetch_relevant_docs(query)
    response = llm.generate(query, context=context)
    return response  # user never clicks through

Your content needs to be selected during retrieval, not just indexed. That's a different optimisation problem.

What LLMs Actually Reward

Based on research into how generative engines select sources, here's what seems to matter:

1. Authoritative, Structured Answers

LLMs favour content that directly answers questions in a clear, hierarchical format. Think:

Concise definitions at the top
Bullet lists for steps or options
Tables for comparisons
Headings that map to user intent ("How to...", "What is...", "Best practices for...")

2. Semantic Richness

Keyword stuffing is dead. LLMs look for semantic coverage—related concepts, synonyms, contextual depth. If you're documenting an API, don't just list endpoints. Explain use cases, common errors, and edge cases.

3. Freshness and Specificity

Generic evergreen content is losing ground to timely, specific answers. If you're writing a guide, reference current versions, real-world examples, and actual data.

4. Citation-Friendly Formatting

LLMs are more likely to cite content that's easy to extract and attribute. This means:

Clear authorship and publication dates
Structured data (JSON-LD, Open Graph)
Blockquotes, code snippets, and other semantically marked-up elements

Practical Steps: Optimise for Both

The good news? You don't have to choose. Most GEO best practices also improve traditional SEO. Here's a starter playbook:

Audit Your Content for "Extract-ability"

Can someone (or an LLM) quickly pull a useful answer from your page? If your intro is 300 words of marketing fluff before the actual information, you're in trouble.

Use Structured Data Everywhere

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Building Resilient APIs",
  "author": {"@type": "Person", "name": "Jane Dev"},
  "datePublished": "2024-01-15"
}
</script>

This helps both crawlers and LLMs understand your content's context.

Write for Humans, Optimise for Machines

Your content should read naturally, but also be scannable. Use:

Bold text for key terms
Short paragraphs (2-3 sentences max)
Code blocks for examples (not screenshots)
Tables and lists for structured info

Track Non-Click Visibility

If your content is cited in an AI Overview but doesn't generate clicks, that's still brand exposure. Tools are emerging to track "impression share" in AI-generated results, but even anecdotal monitoring (searching your own key topics and noting citations) is useful.

The Workflow Shift

If you're building content pipelines or CMS tooling, consider:

AI-assisted content audits: Use LLMs to identify gaps in semantic coverage or question-answer alignment
Automated structured data generation: Parse your markdown/HTML and inject schema.org markup programmatically
Prompt testing: Literally query LLMs (ChatGPT, Claude, Perplexity) with your target keywords and see if your content surfaces

Agencies focused on AI automation and software development are building these workflows into content ops—treating GEO as a CI/CD problem, not just an editorial one.

The Takeaway

If you're maintaining documentation, a developer blog, or any content-heavy platform, your success metrics are shifting. Rankings matter less than retrieval. Clicks matter less than citation.

Optimise for both crawlers and LLMs. Structure your content like an API response: clear, hierarchical, and easy to parse. And remember—your content isn't just being read anymore. It's being used as training data.

Make sure it's worth learning from.