DEV Community: Marc Newstead

Why Your AI Integration Might Get 10x More Expensive (And What to Do About It)

Marc Newstead — Mon, 14 Sep 2026 09:04:55 +0000

The API You're Using Is Losing Money

Let's talk about something most of us aren't thinking about when we integrate OpenAI, Anthropic, or Google's AI APIs into our applications: the pricing we're paying right now is artificial.

These companies are selling API access below cost. Intentionally. And whilst that's brilliant for our current sprint budgets, it creates a dependency risk that should be on every technical decision log.

What Happens When Subsidies End?

Think about what happened with AWS, Uber, or any other platform that used aggressive pricing to capture market share. The pattern is consistent:

Below-cost pricing to build adoption
Ecosystem lock-in (tooling, workflows, team knowledge)
Price normalisation once switching costs are high enough

OpenAI isn't a charity. Neither is Anthropic. They're venture-backed companies burning capital to acquire users. When the losses stop, pricing will shift to reflect actual costs plus margin.

The question isn't if prices go up. It's when, and whether your architecture can handle it.

Where Lock-In Actually Hurts

It's rarely the API contract itself that traps you. It's everything else:

Prompt Engineering Investment

You've spent weeks tuning prompts for GPT-4's specific behaviour. Those prompts won't necessarily work the same way with Claude, Gemini, or Llama. Each model has different:

Response formats and consistency
Instruction-following characteristics
Context window handling
Rate limit behaviours

That's technical debt you probably haven't budgeted for.

Data Pipelines and Tooling

How tightly coupled is your code to OpenAI's SDK?

# This is coupled
response = openai.ChatCompletion.create(
    model="gpt-4",
    messages=messages,
    temperature=0.7
)
result = response.choices[0].message.content

# This is better
response = llm_client.complete(
    messages=messages,
    temperature=0.7  
)
result = response.content

If you're calling provider-specific methods throughout your codebase, switching providers means a refactor, not a config change.

Team Knowledge and Momentum

Your team has learned one provider's quirks, pricing tiers, and API patterns. They've built monitoring dashboards around specific error codes. Your runbooks assume certain rate limits and failure modes.

Switching isn't just technical—it's organisational friction.

Building for Portability (Practically)

You don't need to build an abstraction layer over every possible LLM provider. That's over-engineering. But you can make deliberate choices that reduce switching costs:

1. Abstract the Provider Interface

Create a thin adapter layer. Even if you only support one provider today, the interface shouldn't assume provider-specific features.

class LLMClient(ABC):
    @abstractmethod
    def complete(self, messages: List[Message], **kwargs) -> Response:
        pass

class OpenAIClient(LLMClient):
    def complete(self, messages, **kwargs):
        # OpenAI-specific implementation
        pass

When pricing changes, you can implement AnthropicClient without touching application logic.

2. Make Prompts Configurable

Don't hardcode prompts in application code. Store them as versioned configs or in a database. When you need to adapt prompts for a different model, you're editing data, not deploying code.

3. Monitor Cost Per Operation

Track cost at the feature level, not just the invoice level:

Cost per user query
Cost per document processed
Cost per API route

When prices shift, you'll immediately know which features become uneconomical.

4. Keep Open-Source Options Viable

Periodically test whether your use case works with open models (Llama, Mistral, etc.). You don't need to run them in production, but if you can't make them work, you've got zero negotiating leverage when your current provider reprices.

If you're building AI-driven products and want to avoid these traps at the architecture level, companies specialising in AI automation and software development can help design for resilience from day one.

The Practical Takeaway

You don't need to panic or rip out your OpenAI integration tomorrow. But you should:

Treat current pricing as temporary in your financial models
Abstract provider dependencies even if you're only using one today
Version and externalise prompts so they're easy to adapt
Track unit economics so you know when pricing becomes a problem

The AI API market is in land-grab mode. That's great for us right now. Just don't mistake a growth strategy for a permanent price point.

Should You Trust Cloud Provider AI Safety Controls in Production?

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

Should You Trust Cloud Provider AI Safety Controls in Production?

If you're building anything with LLMs in production, you've probably hit the moment where someone asks: "How are we handling hallucinations, PII leaks, and toxic outputs?" The instinct is often to reach for a custom solution—build your own content filters, regex patterns for PII, and hardcoded blocklists. But AWS Bedrock Guardrails, Azure AI Content Safety, and Google's safety filters have matured significantly in the past year. So here's the question: can we finally trust native safety controls enough to skip the custom layer?

Let's walk through what these platforms actually offer now, where they still fall short, and how to make the call for your stack.

What You Actually Get Out of the Box

All three major cloud providers now offer built-in guardrails that go beyond simple keyword filtering:

Content classification: Detect hate speech, violence, sexual content, self-harm prompts—configurable by severity threshold
PII redaction: Automatically strip email addresses, credit card numbers, national insurance numbers, etc.
Prompt injection detection: Flag attempts to manipulate the system prompt (though effectiveness varies)
Grounding checks: Validate that responses align with your retrieved context (RAG scenarios)
Topic denial: Block entire subject areas you don't want the model engaging with

Bedrock Guardrails, for example, lets you configure these as pre- and post-inference filters with a simple API call:

response = bedrock_runtime.invoke_model(
    modelId="anthropic.claude-v2",
    body=json.dumps({
        "prompt": user_input,
        "max_tokens": 512
    }),
    guardrailIdentifier="your-guardrail-id",
    guardrailVersion="1"
)

The guardrail runs transparently, logs violations, and can either block or redact problematic content. No need to build your own detection pipeline.

Where They Still Let You Down

Here's the reality: these native controls are designed for breadth, not depth. They handle common patterns well but struggle with edge cases that matter for your specific domain.

Domain-specific jargon gets flagged incorrectly. If you're building tools for healthcare, legal, or financial services, expect false positives. Clinical terminology can trigger violence filters. Legal language around contracts might hit PII detectors.

Context-aware moderation is weak. Native filters don't understand the difference between a user asking "how do I secure my database?" versus "how do I break into a database?" They pattern-match rather than reason about intent.

Transparency is limited. You often don't know why something was flagged. Was it a specific phrase? A topic? A combination? Debugging production issues becomes guesswork.

Customisation has a ceiling. You can tweak sensitivity thresholds and add custom word lists, but you can't fundamentally change how classification works. If the provider's model doesn't recognise your niche risk patterns, you're stuck.

The Framework: Foundation vs. Entirety

The useful mental model isn't "native vs. custom"—it's native as foundation vs. native as entirety.

For most internal tooling, customer support bots, or low-risk workflows, native controls are probably enough. You get decent coverage, managed infrastructure, and automatic updates when new attack patterns emerge.

But if you're in a regulated industry, handling sensitive data, or exposing LLMs to untrusted users at scale, you need a layered approach:

Native guardrails catch the obvious stuff (PII, hate speech, prompt injection attempts)
Custom filters handle your domain-specific rules (proprietary data patterns, context-aware blocking)
Runtime monitoring logs everything for audit and continuous improvement
Human review queues for edge cases that automation can't resolve

This isn't overkill—it's acknowledging that no single layer is foolproof.

Making the Call for Your Stack

Before you commit to going all-in on native controls, ask yourself:

What's our actual risk profile? Internal Q&A tool for devs? Probably fine with native. Customer-facing financial advice bot? Not a chance.
How much control do we need over false positives? If blocking legitimate user queries costs you conversions, you need tighter customisation than native tools allow.
Can we afford vendor lock-in? Guardrail implementations aren't portable. Bedrock guardrails don't work on Azure OpenAI.
Do we have compliance requirements? GDPR, SOC 2, or industry-specific regulations might demand explainability and auditability that native tools don't provide.

If you're working with an agency that specialises in AI automation and software development, they can help map these considerations to architecture decisions—but ultimately, you're the one who knows your risk tolerance and domain edge cases.

The Practical Takeaway

Native AI safety controls are no longer toys. They're production-ready for a wide range of use cases. But "production-ready" doesn't mean "sufficient for all contexts." Start with native guardrails as your baseline, monitor real-world performance closely, and add custom layers only where you've proven they're necessary.

The goal isn't to build the most sophisticated safety system possible—it's to build the least complex system that meets your actual risk requirements. That might be entirely native. It might be hybrid. But it definitely shouldn't be a custom solution built because you didn't trust the platforms to have caught up yet.

They have. Now it's on us to evaluate honestly whether they've caught up enough.

Building for AI Agents: What Developers Need to Know About Agentic Commerce

Marc Newstead — Mon, 07 Sep 2026 09:04:40 +0000

Building for AI Agents: What Developers Need to Know About Agentic Commerce

If you're building ecommerce platforms, here's something that should be on your radar: AI agents are starting to make purchases on behalf of users. Not just recommending products or chatting—actually completing transactions autonomously.

This isn't some distant future scenario. ChatGPT can browse the web. Google's experimenting with Shopping Graph agents. Perplexity is testing checkout flows. The AI shopping agents paradigm is already here, and it breaks a lot of assumptions we've baked into our ecommerce stacks.

What Does This Mean for Your Codebase?

Traditional ecommerce development optimises for human behaviour: visual hierarchy, persuasive copy, A/B tested CTAs. But AI agents don't care about your hero banner or that cleverly worded urgency message. They parse structured data, evaluate explicit attributes, and move on fast if information is missing or ambiguous.

The implications:

Your product data model needs to be machine-first, not just human-friendly
API responses become the primary product interface
Schema.org markup goes from "nice to have" to critical infrastructure

Structured Data Is Now a First-Class Concern

You probably already emit some JSON-LD for SEO. Time to treat it like a proper API contract.

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Wireless Headphones",
  "brand": {"@type": "Brand", "name": "AudioCo"},
  "offers": {
    "@type": "Offer",
    "price": "79.99",
    "priceCurrency": "GBP",
    "availability": "https://schema.org/InStock",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "deliveryTime": {
        "@type": "ShippingDeliveryTime",
        "businessDays": {"@type": "OpeningHoursSpecification", "dayOfWeek": "http://schema.org/Monday"}
      }
    }
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.5",
    "reviewCount": "287"
  }
}

Agents will prioritise vendors who provide complete, unambiguous data. Missing fields mean you're invisible to the agent, even if your product is perfect for the user's needs.

What to prioritise:

Full Schema.org Product markup (not just the bare minimum)
Explicit shipping costs, lead times, return policies
Structured specification data (dimensions, compatibility, materials)
Machine-readable availability and stock levels

APIs Over HTML

Some agents will scrape your HTML. Better ones will prefer proper APIs. If you're not exposing product catalogues via REST or GraphQL endpoints, now's the time.

Consider:

Dedicated agent endpoints with richer data than your public-facing site might display
Rate limiting strategies that don't punish legitimate agent traffic
API keys or authentication for verified agents (think partnerships with OpenAI, Google, etc.)

// Example: Agent-optimised product endpoint
app.get('/api/v1/products/:id/agent', authenticateAgent, (req, res) => {
  const product = getProductById(req.params.id);
  res.json({
    ...product,
    structured_specs: product.specifications, // Fully normalised
    compatibility: product.compatibleWith, // Explicit relationships
    environmental_impact: product.sustainability, // Emerging agent priorities
    agent_metadata: {
      last_updated: product.updatedAt,
      data_confidence: 'high'
    }
  });
});

Rethinking Affiliate Tracking

Traditional affiliate tracking relies on cookies and click-through attribution. Agents don't click banners. They evaluate options programmatically and transact directly.

You'll need:

Server-side attribution models that accept agent-provided referral tokens
API-native commission tracking (think affiliate IDs passed in headers or request params)
New integration points with agent platforms themselves

This is still emerging territory. Businesses focused on AI automation and software development are already exploring agent partnership models that look more like B2B integrations than traditional affiliate marketing.

What to Build Right Now

Audit your product data completeness. Run your catalogue through a schema validator. Fix missing fields.
Expose a proper product API. Even a read-only REST endpoint is a start.
Monitor agent traffic. Check your logs for non-browser user agents. Understand how they're interacting with your site.
Test with existing agents. Ask ChatGPT or Perplexity to find and compare your products. See what they surface (or don't).

The Bottom Line

Agents are becoming a meaningful traffic source, and they behave fundamentally differently from human users. The good news? This is solvable with better data architecture and thoughtful API design—skills developers already have.

The platforms that win in agentic commerce will be the ones that treat machine readability as a feature, not an afterthought.

Your API Isn't Ready for AI Agents (And Why That Matters Now)

Marc Newstead — Mon, 07 Sep 2026 09:02:01 +0000

Your API Isn't Ready for AI Agents (And Why That Matters Now)

We've spent years building APIs for mobile apps, SPAs, and internal services. Now there's a new client knocking: AI agents that want to browse your catalogue, compare prices, and complete purchases—autonomously.

If you're running an ecommerce platform, this isn't science fiction. It's happening now, and your existing REST endpoints probably aren't cut out for it.

The Problem: APIs Built for Humans, Not Agents

Most ecommerce APIs assume a human is driving. Pagination works one way. Search expects user-typed queries. Checkout flows require session cookies and CSRF tokens tied to browser contexts.

AI agents don't work like that. They:

Need machine-readable schemas, not just JSON responses
Want structured discovery mechanisms ("what can I do here?")
Expect stateful sessions that persist across model context windows
Require authentication that works outside cookie-based flows

Your perfectly functional API might be completely opaque to an agent trying to make a purchase.

Enter MCP: The Protocol You Should Know About

Anthropic's Model Context Protocol (MCP) is becoming the de facto standard for LLMs to interact with external services. Think of it as a handshake protocol that lets AI models discover and call your API methods in a structured way.

Here's what matters from a developer perspective:

1. Tool Definitions

You expose your API capabilities as "tools" with explicit schemas:

{
  "name": "search_products",
  "description": "Search product catalogue by query",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {"type": "string"},
      "category": {"type": "string", "optional": true},
      "maxPrice": {"type": "number", "optional": true}
    }
  }
}

2. Stateful Sessions

MCP supports session state, so an agent can add items to a basket and complete checkout across multiple interactions—critical for anything beyond simple queries.

3. Authentication That Works

Token-based auth schemes that agents can actually use, not cookie flows that assume a browser.

The llms.txt Convention

Alongside MCP, you'll want an llms.txt file at your domain root. It's the robots.txt for AI—a simple, human-readable file that tells agents what your site offers:

# Product Catalogue API
Base URL: https://api.yourstore.com/v2
MCP Endpoint: https://api.yourstore.com/mcp
Capabilities: product_search, price_check, inventory_status, checkout
Auth: Bearer token required
Rate limits: 100 req/min

It's not a standard yet, but it's emerging as convention. Add one now.

What Actually Needs Doing

If you maintain an ecommerce API, here's the practical checklist:

1. Audit Your Catalogue Endpoints

Is every SKU accessible via a queryable API?
Are product attributes structured and consistently typed?
Can you filter by price, availability, category programmatically?

2. Make Pricing and Inventory Real-Time

Agents won't scrape your frontend. They'll call your API. If your product endpoint returns stale pricing or "call for quote", you're out of the game.

3. Rethink Checkout Flows

Multi-step checkout with CSRF tokens and session cookies doesn't work for agents. You need:

Stateless or token-based basket management
Programmatic address validation
Payment flows that support server-to-server tokens (Stripe Payment Intents, not Checkout.js)

4. Add Machine-Readable Schemas

OpenAPI specs are a start, but MCP tool definitions are better. Describe what your endpoints do and what they return, in terms an LLM can reason about.

B2B Is Where This Gets Real

If you're in B2C, agentic commerce is interesting. If you're B2B—especially procurement, trade supply, wholesale—it's urgent.

Procurement teams are already using AI assistants to research suppliers and compare quotes. The first supplier whose API an agent can actually navigate and purchase from wins the order. The one still requiring a phone call loses.

Agencies specialising in AI automation and software development are seeing this demand spike, particularly from wholesale and manufacturing clients.

Start Small, But Start Now

Add an llms.txt file this week
Audit your top 10 API endpoints—are they agent-friendly?
Pick one flow (search? add to basket?) and write an MCP tool definition for it
Test it with Claude or another MCP-aware model

The competitive window is open now. In 12 months, agentic commerce will be table stakes.

If you want to dig deeper into the strategic implications, the article ready to sell to AI covers the broader ecommerce landscape and where the urgency really lies.

But from a dev perspective? The work is concrete, achievable, and needs doing now. Your API is about to get a lot more clients—and they won't be human.

Building for AI Agents That Actually Buy Stuff: A Developer's Guide

Marc Newstead — Mon, 31 Aug 2026 09:04:48 +0000

Building for AI Agents That Actually Buy Stuff: A Developer's Guide

Visa and Mastercard are now allowing AI agents to hold tokenised payment credentials and complete purchases autonomously. This isn't a demo or a proof of concept—it's happening in production right now. If you're building ecommerce platforms, payment integrations, or anything adjacent, this changes your technical requirements in ways that aren't immediately obvious.

Let's talk through what actually matters from a developer perspective.

The Request Signature Problem

Traditional ecommerce APIs assume a human is somewhere in the loop. Your rate limiting, session management, and fraud detection are all tuned for browser-based sessions or mobile apps with recognisable user-agent strings.

AI agents don't behave like browsers. They don't click through three product pages before converting. They don't abandon carts. They make decisions in milliseconds based on structured data, then execute.

Your existing fraud rules will flag this as suspicious:

// What your fraud detection sees
{
  session_duration: 0.3, // seconds
  pages_viewed: 1,
  user_agent: "CustomAgentClient/2.1",
  conversion_rate: 1.0,
  repeat_purchase_interval: "exactly 30 days"
}

That's not a fraudster—that's an AI agent buying cat food on behalf of a user who set up a recurring purchase rule. But your existing heuristics can't tell the difference.

Rethinking Your API Design

If agents are first-class customers, your API needs to support them explicitly. This means:

1. Agent authentication flows

You need a distinct auth mechanism for agent credentials. OAuth2 client credentials flow is a starting point, but you'll want additional metadata:

{
  "client_id": "agent_xyz",
  "client_type": "autonomous_agent",
  "acting_on_behalf_of": "user_12345",
  "authorised_actions": ["purchase", "reorder"],
  "spending_limits": {
    "per_transaction": 50.00,
    "per_month": 200.00
  }
}

2. Structured product data endpoints

Agents don't scrape your HTML. They need machine-readable product catalogues with pricing, availability, and specifications. If you're not already exposing this via GraphQL or a robust REST API, you're making agents work harder than they should.

3. Webhook-first order updates

Agents don't poll. They subscribe. Make sure your order status changes, shipping updates, and inventory alerts are available via webhooks, not just GET endpoints.

The Attribution Mess

Here's where it gets commercially messy: Agentic Commerce breaks traditional affiliate tracking.

An agent doesn't click a referral link. It evaluates options programmatically, possibly across dozens of vendors simultaneously, and chooses based on price, availability, and user preferences. Your ?ref=affiliate123 query parameter never enters the equation.

From a technical perspective, you need:

Agent declaration headers: Let agents identify which service or user initiated the request
Alternative attribution models: Consider tagging agents themselves as referral sources
Transparent logging: Agents should be able to query why a particular product or vendor was recommended

// Agent making a purchase request
POST /api/orders
Headers:
  X-Agent-ID: perplexity_assistant_v2
  X-Acting-For-User: user_12345
  X-Initiated-By: perplexity_shopping_context

Fraud Detection Needs Retraining

Your ML-based fraud models are trained on human behaviour. Agents will look like anomalies until you explicitly account for them.

Consider adding:

Agent reputation scores: Track which agents behave predictably vs. which show suspicious patterns
Velocity limits per agent: An agent making 50 purchases/minute across different users might be legitimate—or it might be compromised
Credential binding: Ensure agent tokens are bound to specific users and can't be reused across accounts

What to Build Now

If you're working on payment infrastructure, ecommerce platforms, or integration layers, here's what to prioritise:

Implement agent-specific auth flows before your fraud system starts blocking legitimate agent purchases
Expose structured product data APIs if you haven't already—Schema.org markup isn't enough
Log and monitor agent behaviour separately from human traffic so you can tune your systems
Design spending controls that let users authorise agents with granular permissions

This isn't speculative. Payment networks are enabling this now. The companies that treat agent commerce as a first-class integration concern—rather than a weird edge case—will have a significant advantage.

If you're building in this space and need technical guidance on AI automation and software development, the architecture decisions you make in the next six months will define whether your platform is agent-friendly or agent-hostile.

The agents are coming. Make sure your API is ready.

Building Your Ecommerce Stack for AI Agents: A Dev's Guide

Marc Newstead — Mon, 31 Aug 2026 09:02:06 +0000

Building Your Ecommerce Stack for AI Agents: A Dev's Guide

AI shopping agents are coming. Not in some distant future—they're being tested now by companies like Anthropic, OpenAI, and Perplexity. These agents will browse, compare, and purchase products autonomously on behalf of users.

The question isn't whether this traffic will arrive, but whether your site will be their first choice or an afterthought. Here's what you need to know as a developer to get ahead of this shift.

The MCP Problem: Agents Need Structured Access

Right now, most sites are optimised for humans with browsers. AI agents can scrape HTML, but it's inefficient and fragile. Enter the Model Context Protocol (MCP)—an open standard that defines how AI models connect to external data sources.

Think of MCP as GraphQL for AI agents. Instead of parsing your rendered HTML, agents query structured endpoints that return exactly what they need: product catalogues, availability, pricing, checkout flows.

What This Means for Your Stack

If you're already running a headless commerce setup, you're halfway there. Your product API probably exposes the right data—it just needs to be packaged for agent consumption.

Key endpoints to consider:

/mcp/products — searchable, filterable product catalogue
/mcp/inventory — real-time stock levels
/mcp/checkout — programmatic purchase flow with auth

Your responses should be deterministic and well-typed. JSON Schema validation is your friend here. Agents don't handle ambiguity well—"out of stock" and "temporarily unavailable" need to map to distinct states.

The llms.txt Convention

Before an agent queries your MCP endpoints, it needs to discover them. This is where llms.txt comes in—a dead-simple convention inspired by robots.txt.

Place it at your domain root and tell agents what you offer:

# llms.txt
MCP-Endpoint: https://yoursite.com/mcp
Product-Feed: https://yoursite.com/products.json
Docs: https://yoursite.com/api/docs

No XML sitemaps, no scraping your footer for API links. Just a plain text file that says "here's how to talk to me programmatically."

If you're unsure where to start with preparing your website for agentic traffic, this file is your minimum viable step.

Product Data Quality: The Unsexy Foundation

Here's the uncomfortable truth: if your product data is inconsistent, agents will skip you.

Humans are forgiving. They'll tolerate missing dimensions, vague descriptions, or inconsistent categorisation. AI agents won't. They're optimising across dozens of sites simultaneously, and poor data quality is a ranking signal.

Audit Your Schema

Run this mental checklist:

Attributes: Are size, colour, material fields consistently populated?
Descriptions: Do they contain actual product details or just marketing fluff?
Categories: Is your taxonomy machine-readable (standardised IDs) or human-only ("Summer Favourites")?
Pricing: Are sale prices, VAT, and shipping costs programmatically accessible?

If you're using Shopify, WooCommerce, or a similar platform, you likely have gaps. Custom taxonomies and metafields are often inconsistently applied. Now's the time to clean that up.

Authentication and Trust

When an agent places an order on behalf of a user, trust becomes critical. You need to verify:

The agent is acting with user consent
The user's payment method is authenticated
The transaction is auditable

OAuth 2.0 flows work here, but you'll need to think about agent-specific scopes. Does the agent have permission to purchase, or only browse? Can it access order history?

Consider issuing agent-specific API keys with rate limits and usage tracking. You want observability into this traffic as it grows.

Why This Matters Now

Agents aren't theoretical. Claude can already browse the web and interact with sites. ChatGPT's browsing mode is live. Perplexity is testing shopping features.

The first wave of agentic traffic will be small—measurable in single-digit percentage points. But it will grow fast, and early movers will set the patterns. Sites that are agent-friendly now will capture disproportionate share as this behaviour scales.

If you're working in ecommerce infrastructure, partner with agencies experienced in AI automation and software development to audit your readiness. The window to prepare is open, but it won't stay that way.

Next Steps

Create your llms.txt file — describe your site's capabilities in plain text
Audit your product API — ensure it's consistent, complete, and well-documented
Prototype an MCP endpoint — start with read-only product queries
Monitor agent traffic — watch your logs for non-browser user agents

The shift to agentic commerce is infrastructural, not cosmetic. It's not about adding a chatbot to your site—it's about making your entire stack legible to autonomous systems.

Get ahead of it now, while it's still a competitive advantage rather than table stakes.

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.