DEV Community: Marc Newstead

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.

Your RAG Pipeline Is Probably Failing Multi-Hop Questions (Here's Why)

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

The Problem You're Not Measuring

If you've built a RAG system in the last year, you've probably reached for a vector database. Pinecone, Weaviate, Qdrant—doesn't matter which. You chunk your docs, generate embeddings, toss them in, and suddenly your LLM can "remember" things. Shipped.

But here's the uncomfortable truth: vector-only RAG falls apart the moment queries require reasoning across multiple pieces of information. We're talking 32% accuracy on multi-hop questions. That's not a tuning problem—it's an architectural one.

Why Vector Search Isn't Enough

Vector databases are brilliant at semantic similarity. Ask "What's our refund policy?" and they'll surface the right doc chunk every time. But ask something like:

"Which projects led by engineers who reported to Sarah are now blocked by infrastructure issues?"

Now you need:

Find engineers reporting to Sarah
Find projects led by those engineers
Filter for blocked status
Check blocking reason is infrastructure

Vector search treats each chunk independently. There's no concept of "reports to" or "blocks" as traversable relationships. You're hoping the right context happens to land in the same embedding neighbourhood. Sometimes it does. Often it doesn't.

This is precisely why the real bottleneck isn't compute or model size—it's how we structure memory.

Graph Memory: Relationships as First-Class Citizens

Graph-based memory stores knowledge as nodes (entities) and edges (relationships). Think Neo4j, but purpose-built for agentic systems.

Instead of:

Chunk 437: "Sarah manages the Platform team..."
Chunk 891: "Project Apollo is blocked due to..."
Chunk 1203: "The Platform team owns..."

You get:

(sarah:Person)-[:MANAGES]->(platform:Team)
(alice:Engineer)-[:MEMBER_OF]->(platform)
(alice)-[:LEADS]->(apollo:Project)
(apollo)-[:BLOCKED_BY]->(infra:Issue {type: "infrastructure"})

Now that multi-hop query becomes a graph traversal. You're not praying the embeddings align—you're following explicit paths through structured knowledge.

What This Looks Like in Practice

For a Python agent using something like LangGraph or a custom orchestrator:

def answer_complex_query(question: str):
    # LLM extracts entities and relationships from question
    query_graph = llm.parse_to_graph_query(question)

    # Execute graph traversal
    results = graph_db.traverse(
        start_nodes=query_graph.entities,
        relationships=query_graph.relations,
        constraints=query_graph.filters
    )

    # LLM synthesises answer from structured results
    return llm.generate_answer(question, results)

The key difference: your retrieval layer now understands structure, not just semantics.

Multi-Agent Systems Amplify the Problem

Single-agent RAG is one thing. But enterprise workflows increasingly involve multiple specialised agents coordinating:

Agent A researches customer context
Agent B pulls relevant contract terms
Agent C generates a response draft
Agent D validates against compliance rules

If each agent is independently fumbling with vector search over the same corpus, you're compounding retrieval errors at every step. Graph memory gives agents a shared, queryable mental model of the domain.

For teams working on AI automation and software development, this isn't theoretical—it's the difference between a demo that impresses and a system that ships.

Hybrid Is the Pragmatic Play

Don't rip out your vector DB tomorrow. Hybrid architectures are where the smart money is:

Vector search for broad semantic retrieval ("find documents about billing")
Graph traversal for structured reasoning ("find Sarah's team's blocked projects")
LLM orchestration to decide which retrieval mode to use

You can even use vector embeddings as initial filtering before graph traversal—shrink the search space, then reason precisely.

# Hybrid retrieval pattern
candidates = vector_db.search(query, top_k=50)  # Cast wide net
entities = extract_entities(candidates)          # Identify key nodes
results = graph_db.traverse_from(entities)       # Reason through relationships

What to Do Next

If you're building agentic systems today:

Audit your queries. How many actually require multi-hop reasoning? If it's >20%, you need structure.
Start small. Build a domain graph for one use case—customer support tickets, project dependencies, org structure.
Instrument retrieval. Log when your RAG system fails. You'll spot the pattern fast.
Prototype hybrid. Keep your vector pipeline, add graph traversal for complex queries.

The architecture shift isn't about chasing novelty. It's about building systems that actually reason instead of just pattern-match.

Because 32% accuracy doesn't ship.

Why Your RAG Agent Can't Connect the Dots (And How to Fix It)

Marc Newstead — Mon, 13 Jul 2026 09:13:29 +0000

The Problem You've Probably Hit

You've built a RAG agent. It answers questions from your docs brilliantly... until someone asks something that requires connecting information across multiple sources. Then it falls apart.

"Who worked on projects related to the component that failed in production last week?"

Your vector-based agent returns documents about the failure, documents about team members, and documents about projects. But it can't connect them. That's multi-hop reasoning, and it's where vector embeddings hit their ceiling.

What Multi-Hop Actually Looks Like in Code

Let's be concrete. Single-hop reasoning is straightforward:

# Single hop: "What does the auth service do?"
query_embedding = embed("auth service functionality")
results = vector_db.similarity_search(query_embedding, k=5)
# Returns relevant docs about auth service ✓

Multi-hop reasoning chains multiple steps:

# Multi-hop: "Which engineer should fix the auth service bug?"
# Step 1: What is the auth service?
# Step 2: Who maintains it?
# Step 3: Who's currently available?
# Step 4: Who has fixed similar bugs before?

With vectors alone, you're either:

Hoping all that context lives in one chunk (unlikely)
Re-querying multiple times and losing the thread
Jamming everything into the LLM context window and burning tokens

None of these scale.

Why We Defaulted to Vectors

Vectors were the pragmatic choice in 2023. The tooling was mature, implementation was straightforward, and for 80% of use cases—document retrieval, FAQ matching, semantic search—they worked brilliantly.

Pinecone, Weaviate, Chroma: all excellent tools. The problem isn't the technology; it's the architectural assumption that every knowledge retrieval problem is a similarity search problem.

It isn't.

What Graphs Do Differently

Graph databases store knowledge as entities and relationships:

// Neo4j example
(Alice:Engineer)-[:MAINTAINS]->(AuthService:Component)
(AuthService)-[:DEPENDS_ON]->(UserDB:Database)
(UserDB)-[:HOSTED_ON]->(ProdServer:Infrastructure)
(Bob:Engineer)-[:ON_CALL_FOR]->(ProdServer)

Now that multi-hop query becomes traversable:

MATCH (bug:Issue {component: "AuthService"})
      -[:AFFECTS]->(service:Component)
      <-[:MAINTAINS]-(engineer:Engineer)
      -[:FIXED]->(similar:Issue)
WHERE similar.type = bug.type
RETURN engineer.name, COUNT(similar) as experience
ORDER BY experience DESC

The graph encodes the connections. You're not asking an LLM to infer relationships from unstructured text—you're traversing explicit edges.

The Practical Hybrid Architecture

Here's what's actually working in production:

Use vectors for:

Initial document retrieval
Semantic similarity matching
Unstructured content search

Use graphs for:

Entity relationships
Multi-hop queries
Traversing connected data

Implementation pattern:

Ingest: Extract entities and relationships from your documents (using NER, LLMs, or structured parsers)
Store: Documents as vectors, entities and relationships in a graph
Query: Use vectors to find candidate documents, use graphs to find connected context
Combine: Pass both to your LLM as enriched context

This isn't theoretical. Teams have measured 40%+ accuracy improvements on multi-hop tasks by adding graph memory to existing vector pipelines. The research on why graph beats vectors shows the performance gap clearly.

Actually Building This

You don't need to rip out your existing stack. Start small:

Identify multi-hop queries in your logs (anything requiring "and then" logic)
Extract key entities from those query domains
Add a graph layer (Neo4j, Amazon Neptune, or even PostgreSQL with recursive CTEs)
Build a hybrid retriever that queries both systems

If you're working with a team that specialises in AI automation and software development, they'll likely be working through similar architectural decisions right now.

The Real Tradeoff

Graphs add complexity. You need:

Entity extraction pipelines
Relationship modelling
Graph database expertise
More complex query logic

But if your agent needs to reason across connected information—and most interesting agents do—the accuracy gains justify the overhead.

Vectors are brilliant for similarity. Graphs are brilliant for connectivity. Use both.

Stop Measuring AI Agent ROI Like It's a Chatbot: A Developer's Guide

Marc Newstead — Mon, 13 Jul 2026 09:10:51 +0000

Stop Measuring AI Agent ROI Like It's a Chatbot: A Developer's Guide

If you've recently shipped an AI agent or are being asked to build one, you've probably been handed a spreadsheet that calculates ROI based on "hours saved" or "tickets deflected." These metrics made sense for traditional automation—but they're killing your agentic AI projects before they start.

Here's why, and what to measure instead.

The Problem: Traditional Metrics Miss the Point

Most organisations are still measuring AI agents like they're measuring a search bar upgrade or a new help desk widget. The conversation goes something like this:

"If the agent handles 1,000 queries per month and saves 5 minutes per query, that's 83 hours saved. Times hourly rate, minus infrastructure cost... ROI positive in 18 months!"

Sounds reasonable. Except agentic AI doesn't just answer questions—it makes decisions and takes actions. A procurement agent doesn't just look up vendor details; it evaluates quotes, flags compliance risks, and routes approvals. A triage agent doesn't just categorise tickets; it assesses severity, assigns priority, and sometimes resolves the issue outright.

When you measure these systems purely on cost savings, you're optimising for the wrong thing. You end up building glorified FAQ bots with extra steps.

A Better Metric: Decisions Automated Per Hour

Instead of "how much did we save?", ask: "How many decisions is this system making per hour?"

This reframes the entire conversation. Suddenly you're thinking about:

Throughput: Can this agent handle 10 routing decisions per hour, or 1,000?
Scope: What categories of decisions can it own end-to-end?
Latency: How quickly does it move from input to action?
Scale: What happens when load doubles?

These are questions developers instinctively ask about any production system. Treating your agent as a decision-making service—not a cost-centre—makes architectural choices clearer.

Example: Deployment Approval Agent

Let's say you build an agent that reviews deployment requests for a platform team:

# Traditional ROI thinking:
# "Saves 10 minutes per manual review, ~200 reviews/month"
# = 33 hours saved, ~£1,500/month

# Decisions-per-hour thinking:
# "Handles 50 deployment approvals/hour during peak"
# "Automatically clears 80% with no human in loop"
# "Escalates 20% with full context and risk assessment"

The second framing makes it obvious this isn't about saving 33 hours—it's about removing a bottleneck. You can now deploy 50 times per hour instead of queuing for manual review. The value isn't the time saved; it's the velocity unlocked.

This shift in perspective influences everything: how you design the agent, what data it needs, how you monitor it, and how you sell it to stakeholders. The decisions matter more article covers the strategic side of this in detail.

What This Changes for You as a Developer

1. You'll Prioritise Different Features

Cost-reduction logic says: "Make the agent handle the simplest 80% of queries."

Decisions-per-hour logic says: "Make the agent handle the highest-volume decision paths end-to-end."

Very different backlogs.

2. Observability Becomes Central

You need to instrument decision quality, not just uptime. Think:

Decision confidence scores
Escalation rates by decision type
Feedback loops from humans who review edge cases
Drift detection on decision patterns

Your agent is now a service with SLOs. Treat it like one.

3. You'll Design for Throughput, Not Coverage

A chatbot optimises for "Can it answer this question?"

An agent optimises for "Can it close the loop on this workflow?"

That means thinking about state management, rollback strategies, and idempotency from day one. Your agent isn't read-only.

The Quality Trap (and How to Avoid It)

Obviously, "decisions per hour" is meaningless if those decisions are rubbish. The key is to instrument quality from the start:

Shadow mode first: Run the agent in parallel, compare to human decisions
Confidence thresholds: Auto-execute high-confidence decisions, escalate the rest
Continuous evaluation: Sample and audit decisions regularly
Feedback signals: Did the human override? Did downstream systems reject it?

If you're working with teams focused on AI automation and software development, these feedback loops should be baked into your delivery process, not bolted on later.

Final Thought

If your current AI project is being measured purely on "cost per query" or "FTE avoided," push back. Ask what decisions the system could own, how many per hour, and what good looks like.

You'll build better systems—and you'll have a much easier time explaining why they matter.

MCP and A2A: Two Protocols Every Multi-Agent Dev Should Know

Marc Newstead — Mon, 06 Jul 2026 09:11:56 +0000

The Two-Layer Problem Nobody Saw Coming

If you're building anything with AI agents right now, you've probably hit the same wall I did: how do you wire multiple agents together without creating a brittle mess of custom integrations?

Turns out, two protocols are emerging to split this problem cleanly down the middle. MCP (Model Context Protocol) handles the vertical—how a single agent talks to its tools and data sources. A2A (Agent-to-Agent) handles the horizontal—how agents discover and communicate with each other.

Understanding this split early saves you from architectural regret later. Let me show you why.

The Vertical Layer: MCP

Think of MCP as the standardised plumbing between your agent and everything it needs to do actual work. Before MCP, every LLM framework had its own way of wrapping API calls, database queries, or file system access.

Here's what MCP standardises:

Tool definitions — A consistent schema for describing what a function does and what parameters it needs
Resource access — How agents read from databases, file systems, or external APIs
Prompts and context — A protocol-level way to inject context and instructions

In practice, this means you can write an MCP server once and plug it into Claude, custom LangChain agents, or any other MCP-compatible runtime:

# Pseudocode: MCP server exposing a tool
class WeatherMCPServer:
    @mcp_tool
    def get_forecast(location: str) -> dict:
        return fetch_weather_api(location)

Anthropie drives MCP, and adoption is growing fast. If you're building agents that need reliable tool access, MCP is becoming the safe default.

The Horizontal Layer: A2A

A2A solves a different problem: how do agents find each other and coordinate?

Imagine you're building a customer support system with three specialised agents:

An intake agent that routes requests
A technical agent that handles product queries
A billing agent that processes refunds

Without A2A, you'd hard-code those connections. With A2A, agents register their capabilities in a directory, and other agents discover them dynamically.

Key A2A concepts:

Agent discovery — A registry where agents advertise what they can do
Message routing — Standardised envelopes for inter-agent communication
Capability negotiation — Agents declare their skills; others query and invoke them

Google's pushing A2A hard, and major cloud vendors are lining up support. The two-layer stack is quickly becoming the de facto architecture for serious multi-agent systems.

Where Devs Get It Wrong

The biggest mistake I see? Using MCP to solve A2A problems, or vice versa.

For example:

❌ Trying to use MCP tool calls to route messages between agents
❌ Building custom agent discovery when A2A already defines it
❌ Implementing A2A-style capability negotiation inside MCP servers

Keep it clean:

MCP = One agent, many tools
A2A = Many agents, one conversation

Real-World Architecture

Here's how I'd structure a production system:

┌─────────────────────────────────────┐
│   A2A Layer (Agent Coordination)    │
│  - Discovery registry               │
│  - Message bus                      │
│  - Routing logic                    │
└─────────────────────────────────────┘
           ↓           ↓           ↓
    Agent A       Agent B       Agent C
       ↓              ↓              ↓
┌──────────────────────────────────────┐
│    MCP Layer (Tool Integration)      │
│  - Database connector                │
│  - API wrappers                      │
│  - File system access                │
└──────────────────────────────────────┘

Each agent has its own MCP stack. The A2A layer orchestrates the whole system.

The Standards Risk

One caveat: neither protocol is governed by a neutral standards body yet. MCP is Anthropic's baby; A2A is Google's. That's not necessarily a dealbreaker, but it does mean the specs could shift based on commercial priorities.

If you're building something enterprise-grade, keep an eye on governance. The worst-case scenario is ending up locked into one vendor's interpretation of the spec.

Should You Care Right Now?

If you're building:

Single-agent systems → MCP is immediately useful. Start there.
Multi-agent orchestration → You need both layers. Design for A2A from day one.
Enterprise AI at scale → The two-layer stack is becoming table stakes. Teams working on AI automation and software development are already adopting this architecture.

The payoff is real: cleaner code, less coupling, easier to extend. And when the next big LLM framework drops, you won't be rewriting everything.

Where to Start

Experiment with MCP — Anthropic's docs are solid. Build a simple tool server.
Read the A2A spec — Google published it earlier this year. It's clearer than you'd expect.
Design for the split — Even if you're not using both today, structure your code as if you will.

The agent internet is coming. These two protocols are the plumbing.

Why Your Next AI Agent Should Probably Be a Manager

Marc Newstead — Mon, 06 Jul 2026 09:09:16 +0000

Why Your Next AI Agent Should Probably Be a Manager

If you've built an AI agent that tries to do everything—answer support tickets, query databases, generate reports, and update CRM records—you've probably noticed it's mediocre at all of them. There's a better pattern, and it's one we've used in software architecture for decades: delegation.

Instead of building one massive agent with an enormous context window and dozens of tools, build a supervisor agent that spawns specialists on demand. Think of it as a tech lead who routes work to the right engineer, not a full-stack developer trying to do everything themselves.

The Problem with Jack-of-All-Trades Agents

A single LLM agent handling a complex workflow hits a wall quickly. You give it:

Access to 15+ API endpoints
A 3,000-word system prompt
Instructions for edge cases in six different domains
Tools for everything from data validation to PDF generation

What you get back is an agent that:

Picks the wrong tool 20% of the time
Hallucinates when context exceeds its sweet spot
Can't specialise deeply enough to handle domain-specific nuance
Becomes exponentially harder to debug as complexity grows

Sound familiar? It's the same reason we stopped building monoliths and started building microservices.

Enter the Supervisor Pattern

The supervisor and sub-agents pattern flips the model. Your supervisor agent doesn't do the work—it routes it.

Here's a simplified flow:

# Pseudocode: Supervisor agent receives a task
task = "Analyse this customer complaint and update their support ticket"

# Supervisor decomposes and delegates
supervisor.analyse(task)
# Output: [
#   {"agent": "sentiment_analyser", "input": complaint_text},
#   {"agent": "crm_updater", "input": ticket_id, "sentiment": result}
# ]

# Each specialist does one thing well
sentiment = sentiment_agent.run(complaint_text)
crm_agent.update(ticket_id, sentiment)

The supervisor's job is orchestration, not execution. It:

Breaks down the user's request into subtasks
Determines which specialist agent handles each subtask
Passes context between agents
Aggregates results and responds

Each sub-agent has:

A narrow, well-defined role
A smaller, focused system prompt
Only the tools it actually needs
Higher accuracy within its domain

Why This Works (and Why It's Familiar)

If you've built distributed systems, this should feel natural. It's the same principles:

Single Responsibility Principle: Each agent does one thing well
Loose Coupling: Agents don't need to know about each other
Bounded Context: Clear domain boundaries reduce complexity
Graceful Degradation: One agent failing doesn't tank the whole system

You wouldn't build a microservice that handles payments, inventory, and email notifications. Don't build agents that way either.

Dynamic Spawning: The Next Level

Static sub-agent pools work, but the real power comes when your supervisor can spawn agents dynamically. Frameworks like LangGraph, AutoGen, and CrewAI support this.

Imagine your supervisor encounters a task it's never seen:

# Task: "Translate this legal document to French and summarise it"

# Supervisor spawns specialists on-the-fly:
supervisor.spawn_agent(
    role="legal_translator",
    tools=["translation_api"],
    context="French legal terminology, formal tone"
)

supervisor.spawn_agent(
    role="document_summariser",
    tools=["text_analysis"],
    context="Legal summary, bullet points, max 200 words"
)

No need to pre-define every possible agent. The supervisor adapts to the task.

The Gotchas (Because There Always Are)

Routing errors are your biggest risk. If the supervisor sends a task to the wrong specialist, you're worse off than with a generalist. Mitigation strategies:

Use structured outputs (JSON, Pydantic models) for routing decisions
Log every delegation decision for debugging
Implement confidence scores—if the supervisor isn't sure, escalate to a human
Test routing logic obsessively

Token costs add up. Multiple agents mean multiple LLM calls. Profile your usage and optimise:

Use smaller models for specialist tasks
Cache common decompositions
Consider local models for low-stakes subtasks

Observability is critical. Distributed agent systems are harder to debug than single agents. Invest in:

Tracing (OpenTelemetry, LangSmith)
Structured logging with request IDs
Dashboards showing agent performance and routing patterns

Should You Build This?

If your agent workflow has:

Multiple distinct domains (e.g., data retrieval + analysis + reporting)
More than 8–10 tools
Frequent routing mistakes
Growing system prompts that feel unwieldy

...then yes, try the supervisor pattern.

If you're building a simple chatbot or single-purpose assistant, stick with one agent. Don't over-engineer.

Where to Start

Pick one complex agent workflow you've already built. Identify two or three distinct subtasks. Refactor into a supervisor + two specialists. Measure accuracy and token usage before and after.

You'll know quickly if it's the right pattern for your use case.

For teams working on AI automation and software development at scale, this pattern is increasingly becoming the default. It's not about replacing single agents—it's about knowing when orchestration beats execution.

Now go build something modular.

MCP + A2A: You're Building Two Integration Layers Whether You Realise It or Not

Marc Newstead — Mon, 29 Jun 2026 09:05:26 +0000

The Problem You Probably Have Already

If you're building agentic systems in 2025, chances are you've already got two integration layers in your stack:

MCP (Model Context Protocol) — wiring your AI models to databases, APIs, filesystems, internal tools
A2A (Agent-to-Agent) protocols — letting your agents discover, negotiate with, and invoke each other

They're not competing. They're complementary. But without a clear interoperability story, you're setting yourself up for the kind of integration spaghetti that kept enterprise architects busy (and miserable) in the ESB era.

What MCP Actually Does

MCP is Anthropic's answer to a simple problem: how do you give an LLM structured, reliable access to external resources without writing bespoke glue code for every data source?

Instead of hardcoding database queries or API calls into your prompts, you expose them as MCP servers. Your AI client connects via a standard protocol, discovers available tools, and invokes them with typed parameters.

Example use case:

# MCP server exposes a tool
@mcp_tool
def query_customer_orders(customer_id: str) -> list[Order]:
    return db.execute("SELECT * FROM orders WHERE customer_id = ?", customer_id)

Your LLM can now call query_customer_orders as a function — no prompt engineering, no brittle scraping, no hoping the model "figures it out".

MCP is vertical integration: connecting one agent to the resources it needs to do its job.

What A2A Actually Does

A2A is horizontal. It's about agents talking to other agents.

Imagine you've got:

A customer service agent that handles support tickets
A logistics agent that tracks shipments
A billing agent that processes refunds

When a customer asks "Where's my refund?", the support agent needs to talk to billing. That's A2A.

A2A protocols define:

Discovery: how does Agent A find Agent B?
Capability negotiation: what can Agent B actually do?
Invocation: how does Agent A call Agent B and handle the response?

Unlike MCP, A2A is still fragmented. There's no single standard. You might be using:

HTTP APIs with custom service meshes
Pub/sub queues (Kafka, RabbitMQ)
gRPC with Protobuf schemas
Proprietary frameworks from LangChain, AutoGen, CrewAI

Each works. None interoperate cleanly.

Why This Feels Familiar (and Not in a Good Way)

If you worked in enterprise integration in the 2000s, this smells like ESB déjà vu.

The Enterprise Service Bus promised to solve the n-squared integration problem: instead of every system talking directly to every other system, route everything through a central bus.

It worked — until it didn't. ESBs became:

Single points of failure
Performance bottlenecks
Proprietary lock-in traps (looking at you, TIBCO and WebSphere)

The two-layer stack emerging now — MCP below, A2A above — risks the same fate if we're not careful.

What You Should Do About It

1. Treat MCP as infrastructure, not application logic

MCP is brilliant for standardising resource access. Don't abuse it by cramming business logic into MCP tools. Keep them thin, composable, and stateless.

2. Pick one A2A pattern per bounded context

Don't mix pub/sub and RPC in the same workflow unless you have a damn good reason. Consistency beats flexibility when debugging multi-agent failures at 2am.

3. Design for replaceability

Whatever A2A framework you choose today will probably be legacy in 18 months. Wrap it. Abstract it. Make it swappable.

Example:

class AgentInvoker(Protocol):
    def invoke(self, agent_id: str, task: dict) -> dict:
        ...

class KafkaAgentInvoker(AgentInvoker):
    # Implementation today

class GrpcAgentInvoker(AgentInvoker):
    # Swap in tomorrow

4. Monitor both layers separately

MCP failures look different to A2A failures:

MCP: "Tool not found", "Database timeout", "API key expired"
A2A: "Agent unavailable", "Circular dependency", "Message bus backlog"

Your observability stack needs to distinguish them.

The Boring Truth

There's no silver bullet yet. MCP is maturing fast, but A2A is still the Wild West. If you're building production agentic systems — especially in regulated industries or at scale — treat this as an architecture risk, not just a tooling choice.

You don't need to freeze development. But you do need to:

Isolate the integration layer
Version your agent contracts
Plan for migration

The teams that get this right won't be the ones with the cleverest agents. They'll be the ones who can rewire them without a full rewrite.

If you're evaluating MCP, A2A, or any other part of the agentic stack and want a second opinion, teams specialising in AI automation and software development can help you de-risk the architecture before you're too deep to reverse course.

But honestly? Just don't build another ESB. We've been there. It wasn't fun.