DEV Community: Anshul Prakash

Agents Are the New Microservices — And Google Just Proved It at Next '26

Anshul Prakash — Fri, 24 Apr 2026 14:45:16 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

I'm at Google Cloud Next this week, and something someone said in passing between sessions stuck with me:

"Agents are the new microservices."

At first it felt like conference hyperbole. By the end of the keynotes, I wasn't so sure.

We've Been Here Before

Cast your mind back to 2012–2015. We were breaking apart monoliths. The pitch was compelling — smaller, focused services, independently deployable, easier to reason about. The reality took years to catch up. We needed service meshes to manage traffic, distributed tracing to debug across boundaries, circuit breakers to handle failures gracefully, and IAM policies to figure out which service could talk to which.

The decomposition was easy. The discipline was hard.

I think we're at the exact same inflection point with AI agents — and what Google shipped at Next '26 is the clearest signal yet.

The Announcements That Made It Click

Google didn't just talk about agents in the abstract. They shipped the infrastructure primitives:

Agent Identity — Every agent gets a unique cryptographic ID with scoped permissions and audit trails. Agents can operate autonomously but within defined authorization boundaries, and escalate to a human when they hit the edge of their scope.

Agent Gateway — Centralized policy enforcement for all agent-to-agent and agent-to-tool interactions. It understands MCP and A2A natively, inspects every interaction, and integrates with Model Armor for runtime protection against prompt injection and tool poisoning.

Agent Registry — They literally called it "the DNS of your internet of agents." Agents advertise capabilities via signed Agent Cards. Other agents discover and route to them. Sound familiar?

A2A Protocol v1.2 — Now in production at 150+ organizations including Microsoft, AWS, Salesforce, SAP, and ServiceNow. Governed by the Linux Foundation. IBM's competing ACP protocol voluntarily merged into it last year. The standard is settling.

The Architecture That's Forming

Here's the mental model I came away with:

MCP = how an agent connects to tools and data (think: the service's internal dependencies)
A2A = how agents communicate with each other across platforms and orgs (think: the inter-service API contract)
Agent Identity = trust and authorization (think: mTLS + IAM, but for agents)
Agent Gateway = policy enforcement at the boundary (think: your API gateway / service mesh)
Agent Registry = discovery (think: service registry / DNS) If you squint, it's a microservice architecture. The components map almost 1:1. The difference is that the nodes in this network are nondeterministic — they don't return a predictable response to a given input the way a REST endpoint does. That changes the failure modes significantly.

What's Actually Different (And Harder)

With microservices, failure is binary and observable. A service either returns 200 or it doesn't. You can write deterministic tests, set SLAs, and build dashboards around clear metrics.

With agents, failure is semantic. An agent can return something that looks correct and is completely wrong for the task. Observability isn't just logs and latency anymore — it's did the agent do the right thing, which is fundamentally harder to instrument.

Google's response to this is Agent Observability and Model Armor — but we're early. The tooling for semantic correctness is nowhere near as mature as distributed tracing was at the microservice maturity peak.

Who Has the Advantage

The engineers who survived the microservices wars — who built retry logic, designed for idempotency, drew service boundary diagrams, and debugged cascading failures at 2am — are going to have a serious edge here.

The instincts transfer: keep agents focused on a single responsibility, design for failure at every boundary, don't share mutable state between agents, make every interaction traceable.

What doesn't transfer is the assumption that a system that runs is a system that works. That's the new discipline we're building.

Where I Think This Goes

A2A reaching the Linux Foundation with 150+ production orgs in under a year is legitimately impressive. For context, it took years for microservice tooling (Kubernetes, Istio, Jaeger) to reach equivalent adoption. The compression is real.

I left the keynotes thinking the analogy isn't just rhetorical anymore. The same organizational forces that pushed teams toward microservices — scale, team autonomy, independent deployment — are pushing toward multi-agent architectures. And Google just built the Kubernetes-equivalent control plane for it.

The question isn't if this becomes the dominant enterprise architecture. It's whether your team builds the discipline before you're debugging agent spaghetti at 2am.

Written from the conference floor at Google Cloud Next '26, Las Vegas.

I added GenAI System Design to my interviews. Then I tried to pass one myself.

Anshul Prakash — Tue, 31 Mar 2026 14:00:00 +0000

I've been interviewing software engineers for a while. Recently I started incorporating GenAI system design into the loop — RAG pipelines, agent architectures, evaluation strategies. The kind of questions that are now standard at OpenAI, Anthropic, Google, and Meta.

Before I started asking candidates these questions, I wanted to make sure I understood what a strong answer actually looked like from the other side. So I went looking for reference material. That search led me to an AI-powered mock interview tool built specifically for this type of question.

I figured I'd run through a session. I've conducted hundreds of interviews. I know this material cold.

I was not expecting what happened next.

The Session

The question was a system design problem. The kind I've watched candidates struggle with dozens of times. I've sat on the other side of this exact type of question. I know what a strong answer looks like.

I started talking. I went into architecture. I covered components. I felt fine.

The session ended. The scores came back.

1/5. Across every dimension. Architecture. Scalability. Trade-off analysis. Requirement coverage. Communication. All ones.

The summary: "The candidate demonstrated minimal technical depth and failed to present any coherent system architecture or design.."

I stared at it for a while.

What Actually Happened

The feedback was right, and once I read it I knew exactly why.

I had walked in thinking about the problem the way I think about it when I'm reviewing a candidate's answer — from a position of already knowing the destination. I wasn't narrating my reasoning. I was stating conclusions and moving on, assuming the listener could follow my logic without seeing it.

That's not how interviews work. The interviewer has no access to your internal reasoning. They only have what you say out loud. And what I said out loud, apparently, didn't add up to much.

The sharpest note in the feedback: I had jumped straight into implementation without spending a single minute on requirement gathering. No clarifying questions. No scope definition. Just architecture.

*The #1 fix the tool highlighted: *"Practice the opening 2 minutes religiously — have a memorized script for requirement gathering that you can deliver even under extreme stress."

I give that exact note to candidates regularly. I had just failed to do it myself.

Why This Keeps Happening

There's a specific failure mode I see repeatedly in GenAI system design interviews, and I now realize I'm not immune to it myself.

Most engineers prepare by studying. They read papers, go through architecture blogs, maybe build a small RAG prototype. They accumulate knowledge. And then they walk into an interview and treat it like a solo design session — thinking in their head, stating conclusions out loud.

That's not what an interview is. An interview is a real-time window into your reasoning process. The interviewer isn't just evaluating what you know. They're watching how you think — how you handle ambiguity, how you weigh tradeoffs, how you respond when challenged.

Silence reads as uncertainty. Jumping to implementation without framing reads as shallow. These aren't signals that you don't know the material. They're signals that you haven't practiced communicating it.

What These Questions Actually Look Like

In case you haven't encountered them yet, here's the shape of what's showing up in AI/ML interview loops right now:

Agent design:
"Design an agent that can autonomously manage X." The follow-ups are about failure modes, escalation logic, tool interface design, and how you'd evaluate whether the agent is performing well in production.

RAG architecture: "We need a system that answers questions grounded in our internal documentation." The follow-ups are about chunking strategy, retrieval quality, handling stale data, and latency vs. accuracy tradeoffs.

Evaluation strategy: "How would you measure whether this AI system is working?" The follow-ups are about what you do when you don't have ground truth, and how you catch regressions.

Prompt engineering tradeoffs: "Should we fine-tune or use RAG here?" The follow-ups are about when each approach breaks down, and how you'd make that call given specific constraints.

None of these have a single correct answer. The interviewer is watching your reasoning, not your conclusion.

What I Changed After This

I now run through at least one practice session before any role where I'll be on the interviewer side of a new question type. Not because I don't know the material — but because there's a gap between knowing something and being able to explain it fluently under pressure, and that gap shows up faster than you expect.

If you're preparing for AI/ML roles and you've only been studying — not practicing speaking — you might have more of that gap than you think.

Try explaining your last system design out loud, to no one, for ten minutes straight. See how long it takes before you go quiet.

That's the thing to fix.

Have you tried a GenAI interview yet? Share your experience or your favorite "clarifying question" in the comments below!

Kubecon 2020: Istio Simplified

Anshul Prakash — Tue, 25 Aug 2020 00:53:21 +0000

Last week I attended Kubecon 2020 Europe and have tried to write a summary on Istio simplified session which talks about changes in Istio 1.6 and a shift from microservices design pattern to a monolith design. Please do share your views in the comment section.
Medium post