DEV Community: Marc Newstead

Why Your E-commerce API Needs an llms.txt File (Before Your Competitors Add One)

Marc Newstead — Mon, 24 Aug 2026 09:04:55 +0000

Why Your E-commerce API Needs an llms.txt File (Before Your Competitors Add One)

Last week, a client asked me why their product pages weren't showing up in ChatGPT's shopping recommendations. My first question: "Do you have an llms.txt file?" Blank stare.

If you're building or maintaining an e-commerce platform, AI agents are about to become your most important traffic source—and they don't browse like humans do.

The Problem: AI Agents Don't Click Around

When a user asks Claude or ChatGPT to "find me the best wireless headphones under £150," the agent doesn't open Chrome and click through your navigation. It queries structured data sources, calls APIs, and follows machine-readable conventions.

Your beautifully designed product pages? Invisible.

Your carefully crafted category descriptions? Wasted.

Unless you expose your catalogue in a way LLMs can actually consume, you're not in the game.

Enter llms.txt: The New Robots.txt

Remember when robots.txt was optional? Then suddenly every site needed one to control crawler behaviour. We're at that inflection point again.

An llms.txt file (typically served at https://yoursite.com/llms.txt) tells AI agents:

What your site does
Where to find structured data
Which endpoints support agent queries
Authentication requirements
Rate limits and usage policies

Here's a minimal example for an e-commerce site:

# llms.txt for MyShop

## Purpose
E-commerce site selling consumer electronics

## Structured Data Endpoints
- Product catalogue: /api/v1/products (JSON-LD)
- Search: /api/v1/search?q={query}
- Product detail: /api/v1/products/{id}

## Authentication
API key required: docs at /api/docs

## Rate Limits
100 requests/minute per key

## Contact
api-support@myshop.com

Simple, machine-readable, and it takes 15 minutes to implement.

What Agents Actually Need From Your API

Beyond the llms.txt file, make sure your endpoints return:

1. Clean JSON or JSON-LD

No HTML scraping. Agents want structured product data:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Wireless Headphones Pro",
  "price": "129.99",
  "priceCurrency": "GBP",
  "availability": "InStock",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.5",
    "reviewCount": "287"
  }
}

2. Real-time Stock and Pricing

Agents won't recommend out-of-stock items. Your API should return current availability, not cached values from three days ago.

3. Clear Return and Shipping Policies

Include machine-readable policy data. Agents compare these when making recommendations.

4. Secure, Documented Checkout Flows

If you want agents to complete purchases, your checkout API needs OAuth2 support and clear documentation. The agent needs to act on behalf of an authenticated user.

Why This Matters Right Now

Early movers in SEO built link equity that competitors couldn't touch for years. Agentic commerce creates a similar first-mover advantage.

Once an AI agent successfully transacts with your site, that interaction becomes training data. The agent learns your inventory structure, pricing patterns, and reliability. Competitors entering later face an uphill battle.

Plus, LLM providers are actively building partnerships with early adopters. OpenAI's plugin marketplace prioritised sites with clean APIs and good documentation. The same dynamic will play out with shopping agents.

Getting Started This Week

Monday: Audit your existing APIs. Do you expose product data in structured JSON? Is your search endpoint agent-friendly?

Tuesday: Create an llms.txt file. Use the template above. Deploy it to your root domain.

Wednesday: Add JSON-LD markup to your product pages if you haven't already. Use Schema.org's Product type.

Thursday: Document your API. OpenAPI specs are ideal. Host the docs at a stable URL and reference them in your llms.txt.

Friday: Test it. Ask ChatGPT or Claude to search your catalogue. See what happens.

The Bigger Picture

This isn't just about being "AI-ready." It's about building APIs that are actually useful—to agents, to mobile apps, to your own frontend team. The discipline of making your data machine-readable pays dividends everywhere.

If you're working on a larger digital transformation around AI automation and software development, treating your e-commerce platform as an API-first system positions you well for whatever interface comes next—whether that's voice assistants, AR shopping, or something we haven't imagined yet.

The web is shifting from pages to protocols. Your competitors are already noticing. Make sure you're not left behind.

Building for Agentic Commerce: What Devs Need to Know Before It's Too Late

Marc Newstead — Mon, 24 Aug 2026 09:02:18 +0000

Building for Agentic Commerce: What Devs Need to Know Before It's Too Late

If you're building ecommerce systems right now, here's something worth thinking about: what happens when your customers aren't humans anymore?

I don't mean this in a sci-fi dystopia way. I mean practically, architecturally — what changes when an AI agent, not a person clicking through your checkout flow, becomes a first-class user of your system?

The Technical Shift That's Coming

Agentic commerce isn't about chatbots that help you find products. It's about delegation at the transaction level. A user says "keep me stocked on coffee beans, optimise for price and delivery" and an agent — with its own credentials, budget, and decision-making logic — handles the rest.

From a dev perspective, this creates some genuinely new problems:

Authentication that isn't human-centric: OAuth flows assume a person clicking buttons. What does auth look like when the client is an autonomous process making purchasing decisions across dozens of merchants?
Rate limiting and bot detection: Your current bot protection is designed to block automated purchasing. Now you need to enable it, but only for legitimate agents.
Transaction context: When a purchase goes wrong, you can't just email the customer. The agent made the call. Who do you notify? What's the rollback protocol?

Who Sits Between the Agent and Your API?

Here's where it gets commercially interesting, and why I think this matters to you even if you're just shipping features today.

When humans shop, trust infrastructure is invisible: HTTPS, payment card networks, browser security models. We built all of that over decades.

With agents, that trust layer doesn't exist yet — and whoever builds it will control a lot. Think about:

Agent registries: Who certifies that an agent is acting on behalf of a real user with real funds?
Merchant discovery protocols: How does an agent even find your API? Is there an agent-readable product feed spec we all converge on?
Dispute resolution: When an agent makes a mistake, who mediates? The agent provider? The payment network? A new intermediary?

This isn't theoretical. If you're building AI automation and software development systems, you're already adjacent to this problem space.

What You Can Do Right Now

You don't need to rebuild your entire stack, but there are some practical steps worth considering:

1. Make your API agent-friendly

If your ecommerce API is designed exclusively for SPAs and mobile apps, it's going to struggle with agents.

// Instead of requiring session cookies:
GET /products?category=coffee&sort=price&delivery_speed=fast
Authorization: Bearer <agent_token>

// Return structured, parseable data
{
  "products": [...],
  "_meta": {
    "agent_hints": {
      "reorder_eligible": true,
      "subscription_available": true
    }
  }
}

2. Instrument for non-human transaction patterns

Your monitoring and analytics probably assume human behaviour: sessions, cart abandonment, browsing patterns.

Start logging and flagging agent-initiated transactions separately. You'll want to understand:

Purchase frequency and timing patterns
Decision speed (agents won't browse for 10 minutes)
Price sensitivity and optimisation behaviour

3. Design for delegation, not impersonation

When an agent acts, it's not pretending to be the user. It's acting on behalf of the user. That's a meaningful distinction.

Your data models should capture:

CREATE TABLE orders (
  id UUID PRIMARY KEY,
  user_id UUID NOT NULL,
  placed_by_agent_id UUID,  -- null if human
  agent_authority_token TEXT,  -- verifiable delegation proof
  ...
);

The Bit No One's Solved Yet

Liability and regulation are still wide open. If an agent makes an unauthorised purchase, who's responsible? If it violates terms of service, do you ban the agent? The user? Both?

There's no case law. There's barely any industry consensus. But these questions will land on your backlog when your product manager asks you to support agent-driven purchasing.

Bottom Line for Devs

Agentic commerce isn't a 2030 problem. If you're in ecommerce, marketplace, or API platform engineering, this is a 2025–2026 problem.

You don't need to solve it all today, but you do need to be thinking about:

How your API will authenticate and rate-limit non-human clients
What your transaction model looks like when the purchaser isn't clicking buttons
Who you're architecturally betting on to provide the trust layer

Because once that trust layer solidifies, migrating will be expensive. Better to have a point of view now.

Stop Building AI Agents Like Scripts: A Loop Architecture Primer for Devs

Marc Newstead — Mon, 17 Aug 2026 09:04:54 +0000

The Problem With Most AI Agent Code

If you've shipped an AI agent recently, there's a decent chance it's basically a fancy script. You send a prompt, get a response, maybe chain a few calls together, log the output, done. That works fine for demos. But the moment you need that agent to:

Decide whether its own output is good enough to proceed
Spawn sub-agents to handle specific tasks
Recover from API errors or hallucinated nonsense
Explain why it made a decision three steps ago

...your script falls apart.

What you're missing is loop architecture — the control structure that governs how agents reason, act, evaluate, and decide what to do next. Most teams treat this as an afterthought. It shouldn't be.

What Loop Architecture Actually Looks Like

Think of a loop architecture as the runtime for your agent. It's not the model, and it's not the prompt. It's the scaffolding that wraps around both and enforces:

State management: What has the agent done? What does it know?
Evaluation logic: Did that action succeed? Should we retry, delegate, or stop?
Control flow: What happens next? Do we loop again, call a different agent, or return to the user?

Here's a toy example in pseudocode:

class AgentLoop:
    def __init__(self, task, max_iterations=5):
        self.task = task
        self.state = {"steps": [], "status": "running"}
        self.max_iterations = max_iterations

    def run(self):
        iteration = 0
        while self.state["status"] == "running" and iteration < self.max_iterations:
            action = self.reason(self.state)
            result = self.execute(action)
            self.state = self.evaluate(result, self.state)
            iteration += 1
        return self.state

    def reason(self, state):
        # LLM call: "given state, what should I do next?"
        pass

    def execute(self, action):
        # Actually do the thing (API call, DB query, spawn sub-agent)
        pass

    def evaluate(self, result, state):
        # LLM or deterministic check: did it work? update state accordingly
        pass

Notice the loop isn't endless. It has a budget. It checks its own output. It maintains state across iterations. That's the foundation.

The Failure Modes You'll Hit

Once you start building loops, you'll encounter these failure modes fast:

Runaway Spawning

Your orchestrator agent decides every subtask needs its own agent. Suddenly you've got 47 LLM calls in parallel, your API quota is toast, and you have no idea which one caused the failure.

Fix: Hard limits on spawn depth and breadth. Track the agent tree explicitly.

State Amnesia

The agent forgets what it did two steps ago because you're not persisting state between calls. It repeats work, contradicts itself, or loops forever.

Fix: Structured state (JSON, not vibes). Log every state transition. Make it queryable.

No Exit Strategy

Your loop has no clear success or failure condition. It just… keeps going until it times out.

Fix: Explicit halt conditions. "Task complete", "unrecoverable error", "max budget exceeded". Treat these as first-class citizens in your control flow.

Governance Isn't Optional (Especially in the UK)

If you're building agents for finance, healthcare, legal, or public sector, you can't punt on governance. Loop architecture is where you enforce:

Audit trails: every decision, every action, every state change
Human-in-the-loop gates: certain actions require approval before execution
Rollback and replay: if something breaks, you can rewind and debug

This isn't theoretical. If your agent makes a decision that costs money or affects people, you need to be able to explain why it did that. That explanation lives in your loop architecture, not in a vibe check of your prompt history.

For a deeper dive into how loop architecture intersects with governance and enterprise constraints, the original piece on engineering discipline is worth reading.

Practical Next Steps

If you're refactoring an existing agent or starting fresh:

Make state explicit. Use a schema. Version it. Persist it.
Define halt conditions upfront. Success, failure, budget exhaustion.
Instrument everything. Log state transitions, decisions, and evaluations. You'll need this when things break.
Set hard limits. Max iterations, max spawn depth, max cost per loop.
Build eval into the loop. Don't wait until prod to discover your agent hallucinates half the time.

If you're working with teams who need to scale this across regulated environments, agencies focused on AI automation and software development often have reusable loop patterns and governance templates baked in.

The Takeaway

Loop architecture is the difference between a prototype that impresses in a demo and a system you can actually trust in production. Most teams skip this step because it's not as exciting as fine-tuning models or crafting clever prompts. But it's the scaffolding that makes everything else work.

Treat your agent runtime like you'd treat any other critical system component: with discipline, observability, and respect for failure modes. Your future on-call self will thank you.

Your API Just Got Rolled Back: Building Resilience When AI Models Disappear

Marc Newstead — Mon, 17 Aug 2026 09:02:14 +0000

Your API Just Got Rolled Back: Building Resilience When AI Models Disappear

You wake up to Slack alerts. Your product's AI-powered feature is returning gibberish. You check the vendor's status page: "Model gpt-4-turbo-2024-04-09 deprecated effective immediately. Please migrate to gpt-4-turbo-2024-05-13."

Sound familiar? If you're integrating third-party AI models into production systems, this isn't a hypothetical anymore. It's Tuesday.

AI vendors have normalised something that would be unthinkable in traditional software: pulling products with little notice and treating it as routine maintenance. For developers building on these platforms, this changes everything about how we architect integrations.

Why This Isn't Like Other Dependencies

When you pin lodash@4.17.21 in your package.json, you're done. That version behaves identically today, next month, and five years from now. The contract is simple: you control when you upgrade.

AI model APIs break this contract fundamentally:

Model versions can vanish with 30–90 days notice (sometimes less)
Behaviour drifts even within the same version identifier
Rollbacks happen when vendors discover post-deployment issues
Pricing changes mid-lifecycle, making your current integration uneconomical

This isn't a technical problem—it's a business model problem. When OpenAI serves 100 million users across thousands of products, they optimise for their platform economics, not your deployment schedule.

Agencies working in AI automation and software development have seen this pattern accelerate over the past 18 months. The vendors aren't being malicious; they're treating model deprecation as product hygiene.

The Developer's Dilemma

Let's make this concrete. You've built a feature that summarises support tickets using GPT-4. Your product manager loves it. Customers love it. Then the model gets pulled.

Your options:

Migrate immediately to the replacement model (which might behave differently, breaking your prompts)
Disable the feature until you can properly test and migrate
Switch vendors entirely (requiring weeks of reintegration work)

None of these are good. All of them create technical debt, user-facing issues, or both.

Defensive Architecture Patterns

Here's what actually works when building on unstable AI foundations:

1. Abstract the Model Layer

Don't scatter OpenAI calls throughout your codebase:

// Bad: tightly coupled
const summary = await openai.chat.completions.create({
  model: "gpt-4-turbo",
  messages: messages
});

// Better: abstraction layer
const summary = await aiService.summarise({
  text: content,
  model: ModelVersion.CURRENT_SUMMARY
});

This lets you swap implementations, A/B test models, or fall back to alternatives without touching business logic.

2. Version Your Prompts and Outputs

Track which model version generated which output:

interface AISummary {
  content: string;
  modelVersion: string;
  generatedAt: Date;
  tokensUsed: number;
}

When behaviour changes, you can identify which historical outputs might be affected.

3. Build Kill Switches

Feature flags aren't optional—they're critical infrastructure:

if (!featureFlags.isEnabled('ai-summarisation')) {
  return fallbackSummarisation(content);
}

You need the ability to disable AI features instantly without deploying code.

4. Monitor Model Behaviour, Not Just Uptime

Traditional API monitoring (latency, error rates) isn't enough. You need to detect behavioural drift:

Track output length distributions
Sample outputs for quality checks
Monitor user feedback signals (edits, deletions, complaints)
Set up alerts for statistical anomalies

If the new model suddenly produces 40% longer summaries, you want to know before your UI breaks.

What to Demand in SLAs

Developers don't usually negotiate contracts, but you should be feeding requirements to whoever does. Push for:

Minimum notice periods for deprecations (90+ days)
Explicit version stability guarantees (or lack thereof)
Rollback notification requirements with severity definitions
Testing access to replacement models before forced migration

The standard SLA template treats AI like SASS. It isn't. If your procurement team doesn't understand this, point them to resources that explain why SLAs need updating for AI integration.

The Uncomfortable Truth

No amount of defensive coding eliminates the fundamental risk: you're building on infrastructure you don't control, with stability guarantees that wouldn't be acceptable for any other dependency.

That doesn't mean you shouldn't use AI APIs. It means you need to:

Architect for failure as a first-class concern
Never make AI critical path without a fallback
Budget time for unexpected migrations
Document assumptions about model behaviour

Treat AI model integrations like you'd treat a startup's beta API: powerful, useful, and potentially unreliable. Build accordingly.

The vendors have made their position clear through their actions. Now it's on us to build systems that can survive their product decisions.

Why Your Multi-Agent AI System Is Probably a Ticking Time Bomb

Marc Newstead — Mon, 10 Aug 2026 09:04:53 +0000

Why Your Multi-Agent AI System Is Probably a Ticking Time Bomb

You've built a multi-agent AI system. Maybe it's a research assistant that spawns specialist agents, or a customer service orchestrator that delegates to domain experts. It works brilliantly in demos. Then you put it in production and watch your API costs explode, your logs fill with circular reasoning, and your agents start hallucinating confidently at scale.

Sound familiar?

The problem isn't your prompt engineering. It's that you're treating agent orchestration like a script when you should be treating it like distributed systems design.

The Loop Is the System

When you chain LLM calls together with the ability to spawn sub-tasks, you're not building a prompt anymore — you're building a control flow system with non-deterministic nodes. Each decision point is a potential branch. Each agent spawn is a potential infinite regress.

Consider this pseudocode:

def orchestrator(task):
    subtasks = llm.decompose(task)
    results = []
    for subtask in subtasks:
        if is_complex(subtask):
            results.append(orchestrator(subtask))  # Recursive call
        else:
            results.append(specialist_agent(subtask))
    return llm.synthesize(results)

Looks reasonable, right? Now ask yourself:

What stops infinite recursion if is_complex() is LLM-based?
How do you handle when a subtask legitimately requires 47 specialist calls?
What's your budget ceiling before you cut off mid-execution?
How do you debug why the orchestrator chose to spawn 12 agents instead of 3?

These aren't prompt problems. They're architectural problems.

Three Things You Need to Design Explicitly

If you're serious about production multi-agent systems, you need to treat loop design as a first-class engineering concern. That means explicitly designing:

1. Spawning Logic

Your orchestrator needs clear, testable rules for when to delegate. "Let the LLM decide" isn't good enough. You need guard rails:

class SpawnPolicy:
    max_depth: int = 3
    max_children_per_node: int = 5
    cost_ceiling_per_branch: float = 0.50

    def should_spawn(self, context: TaskContext) -> Decision:
        if context.depth >= self.max_depth:
            return Decision.EXECUTE_INLINE
        if context.current_cost + estimated_cost > self.cost_ceiling:
            return Decision.SIMPLIFY
        return Decision.DELEGATE

This isn't about limiting capability — it's about predictable resource consumption. Your spawning logic should be as observable and testable as any other system boundary.

2. State Management

When agents spawn agents, who owns the context? How do you avoid passing the entire conversation history to every spawned agent? What gets synthesised back up the chain?

You need explicit state boundaries:

What context each agent receives
What artifacts persist between calls
How results get aggregated back to the orchestrator
When to prune context to stay under token limits

Treat your agent interactions like microservices. Define clear contracts.

3. Termination Conditions

Your loop needs to know when to stop. Not just "when the task is done" (the LLM will always think it can do more), but hard limits:

Maximum depth of delegation
Token budget exhaustion
Wall-clock timeout
Confidence thresholds that trigger escalation to humans

These should be baked into your architecture, not bolted on as an afterthought.

The Production Reality Check

The discipline teams are missing isn't about better prompts. It's about treating agentic loops with the same rigour you'd apply to any distributed system.

That means:

Structured logging at every spawn decision
Distributed tracing to visualise agent call trees
Circuit breakers to prevent runaway costs
Regression tests that validate spawn behaviour against known scenarios
Cost attribution per logical task, not just per API call

If you're building AI automation and software development capabilities into your product, these aren't nice-to-haves. They're survival basics.

Start Small, Instrument Everything

You don't need to solve all of this on day one. But you do need to acknowledge that the loop is your architecture.

Start by making spawning decisions observable. Log every delegation. Visualise your call trees. Set hard cost ceilings. Build dashboards that show you why an agent spawned five children instead of two.

Then iterate. Because the alternative — hoping your multi-agent system behaves itself in production — is how you end up with surprise AWS bills and a very awkward Slack message to your CTO.

Treat your loops like the distributed systems they are, and your future self will thank you.

Your AI Provider Just Yanked Their Best Model. Now What?

Marc Newstead — Mon, 10 Aug 2026 09:02:15 +0000

Your AI Provider Just Yanked Their Best Model. Now What?

Last month, you integrated GPT-4 Turbo into your product. Your users loved it. Then OpenAI quietly rolled it back, swapped the model weights, and your output quality tanked. Sound familiar?

This isn't hypothetical. Major AI labs are making silent model retractions a regular occurrence, and most dev teams are building on foundations that can shift overnight. If you're calling AI APIs without a plan for this, you're one undocumented rollback away from a very bad sprint.

The Problem: API Stability Is a Polite Fiction

We're used to semantic versioning. Breaking changes come with major version bumps. Deprecation warnings give us months to migrate. The social contract of stable APIs is deeply embedded in how we build software.

AI providers don't play by these rules.

A model version like gpt-4-turbo isn't a semantic version—it's a moving target. The weights behind that endpoint can change without warning. Performance characteristics shift. Output formats drift. What worked in your integration tests last Tuesday might fail differently on Friday.

The incentive structure is clear: labs are in a race for benchmarks, talent, and investment. Shipping fast matters more than stability. If a model has issues post-launch, the path of least resistance is a quiet rollback and a vague status page update.

For a deeper look at why this pattern is becoming normalised, see launch fast, retract quietly.

What Your TOS Actually Says (Spoiler: Not Much)

Most of us click through AI API terms without reading them. When you do read them, the language is blunt:

No uptime guarantees beyond vague "commercially reasonable efforts"
Unilateral modification rights for models, pricing, and availability
Termination clauses that give the provider an exit with minimal notice
No liability for consequential damages (i.e., your product breaking)

You're building critical features on infrastructure that has fewer contractual protections than your email service.

If you're in a regulated industry or handling enterprise SLAs, this gap isn't just annoying—it's a compliance and commercial risk.

Build for Instability: The Abstraction Layer You Actually Need

The correct response isn't to avoid AI. It's to architect for vendor instability from day one.

1. Abstract the AI boundary

Don't let openai.ChatCompletion.create() calls sprawl across your codebase. Wrap all AI calls behind an internal interface:

class LLMService:
    def generate_response(self, prompt: str, context: dict) -> str:
        # Your internal contract
        pass

class OpenAIProvider(LLMService):
    def generate_response(self, prompt: str, context: dict) -> str:
        # OpenAI-specific implementation
        return openai.ChatCompletion.create(...)

This isn't over-engineering. It's basic dependency inversion. When (not if) you need to swap providers, you're changing one class, not grepping through 47 files.

2. Version your prompts and expected behaviours

Treat prompts like database migrations. Version them. Test them. Track which version is active in production.

PROMPT_V3 = """
You are a customer service assistant.
Always respond in JSON format: {"answer": str, "confidence": float}
"""

def test_prompt_v3_format():
    response = llm.generate_response(PROMPT_V3, test_context)
    assert is_valid_json(response)
    assert "answer" in response

When model behaviour drifts, you'll spot it in CI, not in production.

3. Log inputs, outputs, and model versions

You can't debug what you can't see. Log every AI interaction with:

Model name and version
Full prompt (sanitised if needed)
Raw response
Timestamp

When output quality silently degrades, you need data to prove it wasn't your code.

Multi-Vendor Isn't Paranoia—It's Risk Management

Running multiple AI providers in parallel sounds expensive and complex. It is. But so is having your product break when your single provider retracts a model or raises prices 3x.

You don't need full redundancy. You need viable fallback options:

Keep integration code for 2-3 providers behind your abstraction layer
Run periodic tests against backup providers to ensure they still work
Have a decision matrix: which provider for which use case, and what's the fallback?

This isn't about tolerating complexity for its own sake. It's about not having your commercial roadmap held hostage by a vendor's internal politics.

The Bottom Line

AI capabilities are transformative. The commercial terms and stability guarantees surrounding them are not.

If you're building AI features into production systems, architect as if your provider will change the rules mid-game. Because they will.

Abstraction layers, versioned prompts, structured logging, and multi-vendor optionality aren't gold-plating. They're the minimum due diligence for infrastructure you don't control.

If your organisation is navigating these tradeoffs at scale, working with specialists in AI automation and software development can help you get the architecture right before the next retraction hits.

Now go wrap those API calls.

We built a GB-first Maps & Places API because the mapping bill stopped making sense

Marc Newstead — Tue, 04 Aug 2026 09:11:20 +0000

The bill nobody budgeted for

If you've shipped anything with a map in it lately, you've had a version of this conversation with your finance person.

The short history: in March 2025 Google Maps Platform retired the flat $200 monthly credit and replaced it with much smaller per-SKU allowances. Subscription tiers followed. The practical effect is that workloads which used to vanish under the credit now bill from a low threshold — and place search sits at the expensive end. Text Search on the Places API (New) runs around $32 per 1,000 calls above a 5,000-call monthly allowance. Request a rating field and the call moves up an SKU tier. Request reviews and it moves up again.

None of that is unreasonable for what Google provides. It's an excellent global dataset and you're paying global-dataset prices.

But plenty of us aren't building for the globe. We're building a UK checkout. A UK store locator. A UK field-service dispatcher. And we're paying for planet-scale coverage, a consumer-search-optimised ranking model, and a session-token billing abstraction we then have to reverse-engineer to forecast next month's spend.

So we built the thing we wanted instead.

Goggle Places

Goggle Places is a Maps & Places API for Great Britain: predictive search, unified place search, nearby lookup, hosted vector maps and routing, behind one key, priced per request.

GB-first is the whole design constraint, and it buys things a global provider can't easily give you:

Postcodes are first-class, not a special case bolted onto a generic geocoder. Full and partial input, typo-tolerant, ranked sensibly.
Full national coverage — every GB postcode, street, town and landmark, plus amenities, in one index.
Real GB public transport — National Rail plus London bus/tube/DLR/ferry, on live timetables.
Sub-50ms typeahead from the edge, because autocomplete that lands after the user stops typing isn't autocomplete.

Two search endpoints, and the difference matters

This is the bit worth reading properly, because picking the wrong one is the most likely way to have a bad time.

GET /predict is the addresses-only typeahead — postcodes, streets, towns, landmarks. It's what you want behind a checkout address field.

curl "https://api.goggleplaces.com/predict?q=York" \
  -H "x-api-key: gk_live_pk_..."

{ "hits": [ { "name": "York", "type": "town", "geo_point": { "lat": 53.96, "lon": -1.08 } } ] }

GET /search is the single-field façade. It fans out server-side to the gazetteer and the amenity index, then blends both into one ranked list. So Premier Inn York, Nando's and Pizza Express resolve here — where /predict returns nothing, because they aren't addresses.

curl "https://api.goggleplaces.com/search?q=premier%20inn%20york&mode=all&key=gk_live_pk_..."

{
  "q": "premier inn york",
  "mode": "all",
  "total": 3,
  "hits": [
    {
      "display_name": "Premier Inn York South West, York",
      "kind": "place",
      "type": "lodging",
      "locality": "York",
      "geo_point": { "lat": 53.93, "lon": -1.13 }
    },
    {
      "display_name": "York, North Yorkshire",
      "kind": "address",
      "type": "town",
      "geo_point": { "lat": 53.96, "lon": -1.08 }
    }
  ]
}

mode takes all (default), addresses (gazetteer only — identical to /predict) or places (amenities only, for a store locator). Pass lat/lng as a location bias and the amenity half gets a distance decay, so typing travelodge with the map over Manchester surfaces Manchester branches first.

One gotcha, documented but easy to miss: businesses are matched by name. Nando's Manchester won't match, because amenities aren't named with their city. Bias by coordinates instead.

Nearby lookup

Proximity and category rather than typed name — anchored on a point, or on the map viewport so you load exactly what's on screen as the user pans.

# around a point (radius in km, default 5, max 25)
curl "https://api.goggleplaces.com/nearby?lat=53.4808&lng=-2.2426&radius=2&categories=restaurant,bar&key=gk_live_pk_..."

# within a viewport (bbox = minLng,minLat,maxLng,maxLat)
curl "https://api.goggleplaces.com/nearby?bbox=-2.26,53.46,-2.20,53.50&categories=lodging,charging&key=gk_live_pk_..."

Categories: restaurant, bar, attraction, transport, hospital, parking, lodging, charging. Hits come back nearest-first with distance, plus opening_hours, website, phone, cuisine and wheelchair where we have them. Coverage on those secondary fields varies by area, so don't build a UI that assumes opening hours are always present.

Routing

POST /directions, self-hosted over GB data, engine-normalised so the response shape is stable regardless of which engine served it.

curl -X POST "https://api.goggleplaces.com/directions" \
  -H "x-api-key: gk_live_sk_..." \
  -H "content-type: application/json" \
  -d '{
    "origin": [-2.2426, 53.4808],
    "destination": [-1.8904, 52.4862],
    "mode": "auto",
    "alternatives": true
  }'

Modes are auto, bicycle, pedestrian and transit (with the obvious aliases). Up to 25 waypoints, optimize to reorder them as a TSP, GeoJSON LineString geometry, turn-by-turn legs. Set mode=transit and each leg carries the service name, board/alight stops and live times.

Points accept [lon, lat] arrays or {lat, lon} / {lat, lng} objects, so a geo_point from /search drops straight in — you can route to a hotel, not just to an address.

There's a convenience GET for simple two-point routes:

curl "https://api.goggleplaces.com/directions?from=53.4808,-2.2426&to=52.4862,-1.8904" \
  -H "x-api-key: gk_live_sk_..."

Maps

import { map } from '@goggleplaces/sdk'

map({ container: 'map', key: 'gk_live_pk_...' })

A full UK vector map in your <div>. Tiles stream from our API — nothing to self-host, no tile server to operate, no per-tile line item on the invoice.

Keys

Publishable (gk_live_pk_…) are safe to ship in a browser but must be origin-locked; anything else is rejected at the edge with a 403. Secret (gk_live_sk_…) are server-side only. Both are scoped per service, rotatable and metered.

Pricing

Free allowance on every service, then a flat per-1,000 rate. Priced per service, no bundles to decode.

Service	Free / month	Rate	Above 5M*
`/predict`	30,000	£1.68 / 1k	£1.34 / 1k
`/nearby`	30,000	£2.96 / 1k	£2.37 / 1k
`/tiles`	30,000	£4.15 / 1k	£3.32 / 1k
`/directions`	10,000	£2.96 / 1k	£2.37 / 1k

*Directions steps down above 1M rather than 5M. Rates as at August 2026 — check /pricing for current figures.

A card is required to activate the account. You aren't charged unless you exceed the free allowance.

Worked example

The Google comparison depends on your field profile, but a checkout session terminating in a Place Details Pro request is commonly cited around $17 per 1,000 sessions — so ~$1,700 (c £1,260) for 100,000 sessions, against our pricing which would (at an average of 4 debounced calls per session and including the free tier) would work out at £621.60 for the same number of sessions.

Add a map to that page and Google's dynamic map loads run around $7/1,000 against our £4.15/1,000 with 30,000 free — that gap is wider and more straightforward.

When you should not use this

Worth saying plainly, because you'd find out in week three otherwise:

You need coverage outside Great Britain. We don't have it. Use Google, HERE or Mapbox.
You depend on ratings and review text. We don't return either. If your UI shows star ratings, this isn't a swap you can make.
You need Street View or equivalent imagery. Not something we offer.
Your POI depth requirement is high in long-tail commercial categories. Coverage is strongest on transport, infrastructure, hospitality and chains, and thinner on small independents in some areas.

Try it

The search box on goggleplaces.com hits the live predictive endpoint on every keystroke — same endpoint your app would call, no demo mode. Open the network tab and throw real queries at it before you sign up for anything.

Docs: goggleplaces.com/docs. Keys: app.goggleplaces.com.

If predictive search mis-ranks somewhere you know well, or the router sends you a stupid way round, put it in the comments. GB coverage is the product, so local knowledge is the most useful bug report we can get.

Your AI Integration Just Got Deprecated: A Developer's Guide to Vendor Stability

Marc Newstead — Mon, 03 Aug 2026 09:05:04 +0000

The Problem

You've just spent three sprints integrating a shiny new AI API. Your pull request is merged, monitoring is green, and the product team is already planning the next feature that builds on it. Then you open your inbox:

"Important Update: [Feature Name] Deprecated"

The capability you built around? It's being "refined". Translation: it didn't work as advertised, and now you're rewriting code.

This isn't a hypothetical. Google, OpenAI, and Anthropic have all shipped features, branded them, and then quietly walked them back. Why labs ship before they fully understand what they've built is a systemic issue, and as developers, we're the ones left holding the technical debt.

Why This Hits Developers Harder Than Anyone Else

When marketing changes messaging, they update a deck. When a vendor retracts a feature, you rewrite the code.

Here's what actually happens:

Contract breakage disguised as iteration. A model that was "multimodal" becomes "optimised for text-primary workflows". Your image processing pipeline now throws errors in production.
Versioning theatre. The model version number increments, but the behaviour changes fundamentally. Your integration tests pass, but user-facing accuracy drops 20%.
Documentation drift. The API docs still reference capabilities that have been soft-deprecated. You only find out when you hit rate limits or unexpected error codes.

Consumer apps can pivot. Enterprise systems can't. And the codebase you maintain sits somewhere in between, absorbing every breaking change.

What to Check Before You Integrate

You can't eliminate risk, but you can avoid the worst landmines. Here's what I look at now:

1. Version Stability Track Record

Don't trust the roadmap. Check the changelog:

How often do minor versions introduce breaking changes?
Are deprecations announced with a migration window, or do they appear retroactively in release notes?
Is there a public issue tracker where behavioural regressions are discussed?

If a vendor has quietly changed model behaviour three times in six months, assume that's the cadence you'll be dealing with.

2. SLA Reality Check

Read the actual SLA, not the marketing site:

❌ "Enterprise-grade reliability"
✅ 99.9% uptime on inference endpoints, 30-day notice on deprecations

If the SLA doesn't mention API stability or behavioural consistency, you don't have one.

3. Escape Hatch Architecture

Design for replaceability from day one:

# Bad: Tight coupling to vendor SDK
result = openai.ChatCompletion.create(model="gpt-4", ...)

# Better: Abstraction layer
class LLMProvider(Protocol):
    def complete(self, prompt: str) -> str: ...

class OpenAIProvider(LLMProvider):
    def complete(self, prompt: str) -> str:
        return openai.ChatCompletion.create(...)

# Swap providers without touching business logic
provider: LLMProvider = get_provider()  # Config-driven
result = provider.complete(prompt)

If swapping the vendor would mean rewriting half your application, you've already lost.

4. Feature Flag Everything

Treat AI features like you'd treat any experimental third-party dependency:

Wrap calls in feature flags so you can disable them instantly
Log inputs, outputs, and latency separately from your core metrics
Have a fallback path that doesn't depend on the AI being available or correct

This isn't paranoia. This is treating external APIs like the network calls they are.

The Naming Game

One of the subtler issues: vendors brand capabilities before they've proven them at scale. A feature called "Advanced Reasoning" or "Extended Context" sounds like a contract, but legally and technically, it's marketing.

As developers, we need to push back:

If a capability is critical, get the behaviour in writing (SLA, API contract, regression tests)
If the vendor won't commit to specific accuracy or consistency metrics, treat it as experimental
If a feature has been in "beta" for a year, it's not becoming stable — that is the stable state

What This Means for Your Next Sprint

If you're integrating AI tooling — especially in systems that can't tolerate surprise breakage — apply the same scrutiny you would to any other third-party dependency:

Treat model outputs as untrusted input
Version your integrations so you can roll back
Monitor behavioural drift, not just uptime
Budget time for re-integration work, because it's coming

The competitive advantages of AI tooling are real, and adoption does create a moat. But only if you build on stable ground. Firms specialising in AI automation and software development often see teams trip over this exact issue: brilliant proof-of-concept, fragile production deployment.

Final Thought

AI vendors are shipping fast because the market rewards speed over stability. That's not changing. What can change is how we integrate: with scepticism, abstraction layers, and an escape plan.

Because the next retraction email is already being drafted.

Stop Writing One-Shot Prompts: Why Your AI Feature Needs a Loop

Marc Newstead — Mon, 03 Aug 2026 09:02:23 +0000

Stop Writing One-Shot Prompts: Why Your AI Feature Needs a Loop

If you're building AI features the same way you call a REST API — fire a request, get a response, parse the output — you've probably hit the reliability wall. One-shot prompts work brilliantly for demos and narrow tasks, but the moment you need consistency, validation, or multi-step reasoning, they fall apart.

The answer isn't bigger models or more prompt engineering. It's agentic loops: structured, deterministic systems that let AI reason, validate, and course-correct in a controlled cycle.

Here's what that actually looks like in practice.

The Problem with One-Shot Thinking

Let's say you're building a feature that generates SQL from natural language. A one-shot implementation looks like this:

query = llm.generate(f"Convert to SQL: {user_input}")
db.execute(query)

Simple. Clean. And completely brittle.

What happens when:

The LLM hallucinates a table name?
The query has a syntax error?
The user asks for something ambiguous?

You could add validation logic after the call, but you're still stuck with a single attempt. The model doesn't get to learn from its mistakes, and you can't build guardrails into the reasoning process itself.

This is where agentic loops come in.

What an Agentic Loop Actually Is

An agentic loop is a structured cycle where an AI system:

Attempts a task
Evaluates its own output
Decides whether to return, retry, or escalate

Think of it as a while loop with intelligence:

max_iterations = 5
attempts = 0

while attempts < max_iterations:
    query = llm.generate(f"Convert to SQL: {user_input}")
    validation = validate_sql(query, schema)

    if validation.is_valid:
        return query

    user_input = f"{user_input}\n\nPrevious attempt failed: {validation.error}"
    attempts += 1

raise Exception("Failed to generate valid SQL after 5 attempts")

Now the model gets feedback. It can see why it failed and adjust. You've turned a fragile one-shot into a self-correcting system.

The Three Non-Negotiables

If you're building agentic loops in production, three things need to be explicit and deterministic:

1. Exit Conditions

Every loop must have clear success and failure criteria. "The model seems happy" is not an exit condition. "Query passes schema validation" is.

2. Iteration Limits

Never build an unbounded loop. Set a hard cap (usually 3–7 iterations). If the agent can't succeed by then, escalate or fail gracefully.

3. State Management

The agent needs context across iterations. That means passing conversation history, error messages, and intermediate outputs back into the loop. If you're not tracking state, you're not building an agent — you're just retrying.

Real-World Patterns

Two architectures have emerged as practical starting points:

Supervisor-worker: One agent plans, multiple agents execute. The supervisor breaks a task into subtasks, delegates to specialist workers (e.g. one for SQL generation, one for validation), and synthesises the results.

Chain-of-thought validation: The agent generates a solution, then explicitly reasons about whether it meets the requirements. This "thinking step" is logged and used to decide whether to iterate.

Both patterns share a common trait: the agent's reasoning is observable and debuggable. You're not staring at a black box hoping it works.

Observability Is Not Optional

Here's the part that surprises teams: once you ship an agentic loop, you've shipped a runtime decision-making system. That means:

Every iteration should be logged with inputs, outputs, and reasoning
You need metrics on loop convergence (how many iterations to success?)
Failed loops need structured error states, not just stack traces

If you're treating this as a dev concern rather than an ops/governance one, you're in for a rough production incident.

For teams building this infrastructure from scratch, partnering with specialists in AI automation and software development can accelerate time-to-production significantly.

Start Small, Build Deliberately

You don't need to rewrite your entire AI stack overnight. Start with one feature where reliability matters:

Wrap a flaky prompt in a validation loop
Add iteration limits and logging
Track convergence rates and failure modes

Once you see the difference in reliability, you'll never go back to one-shot prompts.

Agentic loops aren't magic. They're structured engineering. And they're the difference between an AI feature that works in demos and one that works in production.

Your Agentic AI Pilot Is Probably Measuring the Wrong Things

Marc Newstead — Mon, 27 Jul 2026 09:07:20 +0000

Your Agentic AI Pilot Is Probably Measuring the Wrong Things

You've built an agentic AI system. It's working. It's doing real work autonomously—chaining API calls, making decisions, handling edge cases. Now you need to prove it's worth the infrastructure spend.

So you pull up the metrics dashboard: tokens consumed, average response time, cost per interaction. Clean numbers. Finance-friendly.

Except these metrics were designed for chatbots, not agents. And that mismatch is quietly killing your business case.

The Chatbot Metric Trap

Most teams inherit their AI metrics from RAG systems and support bots. Those systems were evaluated on:

Cost per query – How much does one Q&A interaction cost?
Response accuracy – Did it retrieve the right answer?
User satisfaction scores – Did the human like the response?

These made sense when you were replacing a glorified search box. But agentic systems don't work like that.

An agent doesn't answer a question. It executes a workflow. It might:

Call three different APIs to gather context
Make a decision based on business rules
Write data back to your CRM
Trigger a follow-up task in Slack
Handle failures and retry with backoff

If you measure that with "cost per query", you're comparing apples to entire fruit salads. The unit of work isn't comparable. Your ROI case falls apart under scrutiny.

What You Should Actually Be Measuring

Start with the workflow, not the AI. Map out what the agent is replacing:

Before (manual process):

1. Support agent receives escalation email
2. Looks up customer in CRM (avg 2 mins)
3. Checks order history in legacy system (avg 3 mins)
4. Evaluates refund eligibility (avg 5 mins)
5. Updates CRM and sends response (avg 3 mins)

Total: ~13 minutes per escalation
Cost: £X per hour × time spent
Throughput: Limited by team capacity

After (agentic system):

# Pseudocode for agentic refund workflow
async def handle_refund_escalation(email):
    customer = await crm.lookup(email.from_address)
    orders = await legacy_system.get_orders(customer.id)

    decision = await agent.evaluate_refund(
        customer_tier=customer.tier,
        order_history=orders,
        request_details=email.body
    )

    if decision.approved:
        await payments.process_refund(decision.amount)

    await crm.log_interaction(customer.id, decision)
    await email.send_response(decision.template)

Measure this:

End-to-end completion time (13 mins → 45 seconds)
Throughput increase (8/hour/person → 80/hour)
Error rate (manual data entry errors vs. agent failures)
Escalation rate (what % still needs human review)
Cost per completed workflow (not per API call)

Now you have numbers that map to business outcomes. You can show that your agent handles 72 more escalations per hour than a human, with 99.2% accuracy and £2.30 per workflow vs. £4.80 for manual processing.

That's a business case. "We saved 40,000 tokens" is not.

Why Pilots Hide the Real Wins

Most agentic pilots run in parallel with existing processes. You're comparing outputs, but not capturing the actual cost savings because the old process is still running.

This creates three problems:

No cost reduction shows up – You're paying for both systems
Throughput gains are invisible – The agent could handle 10× more volume, but you're not sending it 10× more work
The comparison is artificial – You're cherry-picking tasks instead of measuring real production load

If you want credible numbers, you need to:

Route a percentage of production traffic to the agent
Measure actual time/cost saved on those workflows
Track what happens when you scale up the percentage

Don't run a science experiment. Run a production rollout with rollback capability.

Making Finance Actually Listen

Your CFO doesn't care about your model architecture. They care about:

Unit economics – Cost per workflow completed
Payback period – When does cumulative saving exceed build cost?
Risk – What happens if it breaks?

Build your metrics around those questions. If you're serious about getting this right, treating your ROI framework as broken is the starting point.

And if you're building agentic systems in a larger digital transformation context, working with teams experienced in AI automation and software development helps you avoid the common structural mistakes that sink pilots before they reach production.

The Practical Takeaway

Before you write another line of agentic code, map the workflow it's replacing. Define:

Time saved per workflow
Error rate comparison
Throughput ceiling (old vs. new)
Total cost per completed unit of work

Then instrument your agent to capture those metrics from day one. Not token counts. Not inference latency. Business outcomes.

Because the best agentic system in the world is worthless if you can't prove it's worth running.

Your RAG system can't answer "why" questions. Here's what you're missing.

Marc Newstead — Mon, 27 Jul 2026 09:04:44 +0000

The problem with semantic search

You've built a RAG system. User asks a question, you embed it, run a vector similarity search, retrieve the top 5 chunks, shove them into context, and let the LLM answer. Works brilliantly for simple lookup queries.

Then someone asks: "Why did the deployment fail after the database migration?"

Your agent retrieves a chunk about the deployment error. Maybe another about the migration. But it completely misses that the migration changed a column type, which broke a dependency in the service layer, which caused the deployment to fail. That's three hops of reasoning your vector store can't connect.

The gap between 32% and 86% accuracy on multi-hop questions isn't a prompt engineering problem. It's an architecture problem.

What vector search actually gives you

Vector embeddings are phenomenal at semantic similarity. They'll find documents about the same topic, even if the words differ. But they're terrible at representing relationships between facts.

When you embed a sentence like "Service A depends on Service B", that directional relationship gets flattened into a 1536-dimensional float array. The embedding knows these services are related, but it doesn't know how or which direction.

Ask "what services depend on Service B?" and you might retrieve chunks mentioning both services. Ask "what does Service A depend on?" and you'll get similar chunks. The vector store can't distinguish between these queries because the relationship isn't preserved—just the proximity.

The retrieval gap in production

Here's where it breaks in real systems:

Scenario: Your AI agent manages a microservices architecture. Documentation lives in Notion, incident reports in Jira, config in GitHub.

Query: "What's the blast radius if we take down the auth service?"

What vector retrieval gets you:

Chunks about the auth service
Maybe some chunks about services that mention auth
Possibly incident reports that mention auth failures

What you actually need:

Services that directly call auth
Services that depend on those services (second hop)
Downstream effects on user-facing features (third hop)
Historical incidents showing actual impact patterns

Vector search retrieves documents. But reasoning about systems requires traversing a graph of relationships.

Why hybrid retrieval matters

The solution isn't to abandon vector search—it's to stop treating it as your only retrieval mechanism.

Graph-based memory stores information as entities and edges. When your agent processes documentation, it extracts:

Entities: services, APIs, databases, teams, incidents
Relationships: depends_on, calls, deploys, owns, caused_by

Now that "blast radius" query becomes a graph traversal:

# Pseudocode for hybrid retrieval
def answer_query(query):
    # Step 1: Use vector search for initial recall
    candidate_entities = vector_search(query, top_k=10)

    # Step 2: Expand via graph traversal
    related_nodes = graph.traverse(
        start_nodes=candidate_entities,
        relationships=['depends_on', 'calls', 'impacts'],
        max_depth=3
    )

    # Step 3: Retrieve detailed content for final context
    context = fetch_content(related_nodes)

    return llm.generate(query, context)

You use vectors for semantic recall ("find anything related to auth service"), then use the graph to expand outward along explicit relationships.

When you actually need this

Not every agent needs a graph. If you're building a documentation Q&A bot that answers "how do I configure X?", vector search is probably fine.

You need hybrid retrieval when:

Questions require connecting multiple facts ("why did X happen?")
You're reasoning about systems with explicit relationships (dependencies, hierarchies, workflows)
Accuracy on complex queries is more valuable than simplicity
You're seeing high retrieval scores but wrong final answers

Quick diagnostic: Ask your agent three questions that require connecting information from different documents. If it can retrieve all relevant chunks but still gives incomplete answers, you have a relationship problem, not a retrieval problem.

What this looks like in practice

Implementing hybrid retrieval isn't trivial, but it's not exotic either:

Extract entities and relationships during document ingestion (use an LLM or NLP pipeline)
Store vectors in your existing vector DB (Pinecone, Weaviate, etc.)
Store the graph separately (Neo4j, or even a relational DB with recursive CTEs)
Query both during retrieval and merge results

The teams seeing that 86% accuracy boost on multi-hop reasoning aren't using magic—they're just stopped expecting embeddings to preserve information they were never designed to capture. The research on vector-only retrieval makes this gap clear.

If you're building production AI systems that need to reason about relationships, not just retrieve similar text, you'll eventually hit this wall. Graph memory isn't a nice-to-have—it's how you bridge the gap between semantic similarity and actual reasoning.

For more on building robust agent architectures, check out resources on AI automation and software development that cover these hybrid approaches in depth.

The bottom line

Vector search is brilliant at finding relevant documents. Terrible at understanding how facts connect. If your agent needs to answer "why" or "what happens if", you need more than cosine similarity. You need a graph.

Stop Measuring Your AI Agent Like It's a Microservice

Marc Newstead — Mon, 20 Jul 2026 09:10:04 +0000

Stop Measuring Your AI Agent Like It's a Microservice

You've built an AI agent. It works. It's handling real tasks. Your manager asks: "What's the ROI?"

You pull up latency metrics, error rates, cost per API call. The same dashboard you'd show for any service. And that's exactly why your pilot is about to die in committee.

I've watched too many technically successful AI projects get axed because we measured them wrong. Here's what I learned about making agentic AI survive past the pilot phase.

The Microservice Trap

When you build a REST API or a background worker, you measure it like infrastructure:

Requests per second
P99 latency
Error rate
Cost per transaction

These metrics make sense for deterministic systems. You know exactly what each transaction does, and you optimise for doing it cheaper and faster.

But agentic AI doesn't work like that. Your agent might:

Handle a customer query in 30 seconds that would take a human 15 minutes
Fail gracefully and route to a human
Resolve an issue completely, preventing three follow-up tickets

If you're measuring "cost per transaction" at £0.20 per agent interaction versus £0.05 for a traditional form submission, you've already lost the argument. You're comparing apples to entire orchards.

What Actually Matters: Task Deflection Rate

Task deflection rate is the percentage of tasks your agent completes without human intervention. Not "handled" or "touched" — actually completed.

This is your primary metric. Everything else is secondary.

Here's why it matters: if your agent deflects 60% of tier-1 support tickets, and you're processing 10,000 tickets monthly, you've just recaptured 6,000 human interactions. Each of those has a fully loaded cost (salary, overhead, management time).

Let's get concrete:

# Traditional metric (wrong)
cost_per_agent_call = 0.20  # £0.20 LLM + infrastructure
monthly_agent_calls = 6000
monthly_cost = cost_per_agent_call * monthly_agent_calls  # £1,200

# This looks expensive. But watch:

# Task deflection metric (correct)
avg_human_handle_time = 15  # minutes
deflection_rate = 0.60
monthly_tickets = 10000

deflected_tickets = monthly_tickets * deflection_rate  # 6,000
human_hours_recaptured = (deflected_tickets * avg_human_handle_time) / 60  # 1,500 hours

fully_loaded_cost_per_hour = 35  # £35/hour (salary + overhead)
monthly_value = human_hours_recaptured * fully_loaded_cost_per_hour  # £52,500

net_value = monthly_value - monthly_cost  # £51,300/month

Suddenly your "expensive" agent is generating £51k of monthly value. That's the business case.

Measuring Deflection in Practice

You need to instrument this before you finish your pilot. Here's the minimum viable tracking:

class AgentInteraction {
  constructor(ticketId) {
    this.ticketId = ticketId;
    this.startTime = Date.now();
    this.humanHandoffRequired = false;
    this.resolutionConfirmed = false;
  }

  requiresHandoff() {
    this.humanHandoffRequired = true;
    this.logMetric('task_deflection', 0);
  }

  confirmResolution() {
    if (!this.humanHandoffRequired) {
      this.resolutionConfirmed = true;
      this.logMetric('task_deflection', 1);
      this.logMetric('time_saved_minutes', this.estimatedHumanTime);
    }
  }
}

The key is tracking complete resolution versus partial assistance. Your agent might help with 90% of tickets, but only fully resolve 60%. That 60% is your deflection rate.

The Human-Hour Recapture Angle

When task deflection rate changes everything, it's because you're no longer arguing about infrastructure costs. You're talking about capacity.

Those 1,500 recaptured hours monthly? That's nearly a full FTE. Your business case isn't "we made customer service 3% cheaper" — it's "we created capacity equivalent to one senior engineer without hiring."

For teams working on AI automation and software development, this reframing is essential. You're not optimising a process. You're multiplying human capability.

Before You Ship to Production

Build your measurement framework during the pilot:

Baseline human performance — average handle time, escalation rate, resolution rate
Track deflection explicitly — not just "agent engaged" but "human avoided"
Validate with spot checks — random sample of "deflected" tasks to confirm quality
Calculate fully loaded costs — don't use base salary; include overhead

When you go to production review, lead with deflection rate and human-hour recapture. Show the capacity you've created. The cost-per-transaction comparison comes last, if at all.

The Real Win

The best AI agents don't just save money. They give your team time back to do work that actually requires human judgement. Measure that capability, and you'll get your production budget.

Your agent isn't a microservice. Stop measuring it like one.