A few weeks ago, I was working on a normal backend POC. APIs, authentication, a database, a few services talking to each other. Nothing new, nothing exciting.
Around the same time, I was playing around with AI agents on the side. And one question kept bothering me: what happens to all this backend stuff once the client isn’t a frontend app anymore, but an agent?
I’m not asking “will AI replace backend developers” — I stopped taking that question seriously a while ago. If the thing calling my API is actually reasoning about why it’s calling it, does anything about how I build that API need to change?
Instead of just reading docs about it, I decided to build something small and find out for myself.
Step 1: I picked a backend I already knew
For years, the flow was simple: a user clicks something, the frontend sends a request like GET /orders/123, and the backend knows exactly what that means.
Web / Mobile App
|
v
REST API
|
Database
So I imagined a small e-commerce backend — get an order, get a customer, cancel an order, check inventory, create a support ticket. Nothing I hadn’t built ten times before. Then I put an AI agent in front of it. Instead of the app calling GET /orders/123, the user just types "where is my order?"
User
|
v
AI Agent
|
Orders / Customer / Inventory APIs
|
Database
Same backend underneath. Completely different kind of client talking to it.
Step 2: I actually built the thing
I used Google’s Agent Development Kit and deployed it on Cloud Run — an agent with a few tool functions wrapping the same order, customer, and ticket APIs I’d have written anyway. Google now has a clear, documented way to put ADK agents on Cloud Run, with different setups depending on whether the agent is quick and request-based or long-running.
Honestly, this part felt familiar. I wasn’t learning a whole new way to deploy software. The only difference was that this app could think a bit before deciding what to do.
Step 3: I hit the real problem — and it wasn’t the AI
I assumed the hard part would be “is Gemini smart enough to understand the user.” It was fine. That’s not where I got stuck.
What actually slowed me down were questions I already knew as a backend developer, just aimed at a new kind of client. Who is this agent? What is it allowed to access? What happens if a tool call times out — does the agent retry it, and is that safe to do twice? How do I even see what it did afterward?
If anything, agents made these problems louder. Auth, permissions, retries, logging — none of it goes away. The “client” isn’t a fixed set of screens anymore. It can ask for almost anything.
Step 4: I found MCP, and it changed how I saw my own APIs
While building this, I kept running into the Model Context Protocol — a standard way for agents to talk to tools instead of every app writing custom glue code for each one.
What actually mattered to me wasn’t the protocol. It was the question it raised: should my existing APIs become tools an agent can call? Turns out Google Cloud lets you host MCP servers on Cloud Run, and a tool called Apigee can turn your existing APIs into agent-friendly tools without you rewriting them.
That’s a big deal — the backend you already built doesn’t get thrown away. It just gets a new front door.
Before: Now:
Frontend User / Agent
| |
v v
REST API Tool / MCP
| |
v v
Backend REST API -> Backend
Step 5: I hit a wall — permissions
Once my agent could read orders, cancel them, and issue refunds, one problem became obvious fast. I really didn’t want “the agent can do anything” to be my security model. I needed to know exactly which agent did what, on whose behalf.
Google’s building for this with Agent Identity — giving each agent its own identity when talking to other agents or services — and Agent Registry, so you can actually see what agents exist instead of tracking them in a spreadsheet. This part felt a lot closer to normal backend work than to “type a prompt, get an answer.”
What I walked away with
I went in expecting to spend most of my time on the model. I ended up spending almost all of it on the same things I already care about — permissions, retries, error handling, knowing who did what and why. The agent didn’t remove any of that. It just handed it a new client to worry about.
If you already build backend systems, my honest take is: don’t rush to “become an AI engineer.” Ask a few sharper questions about what you’ve already built instead. Can your APIs be safely called by an agent? Who’s checking what it’s allowed to do? Which of your endpoints should actually become tools?
Those are backend questions. They always were. The only thing that’s changed is who’s asking them — a person clicking retry, or an agent deciding to on its own.
By the end of this, I wasn’t thinking about how smart the model was anymore. I was thinking about whether my backend was actually ready for a client that could reason. That’s the question I’d leave you with, too: not “will AI replace me,” but “is what I’ve already built ready to be used by one of these things?”
Google Cloud Is Going Agentic: What Actually Changes for Backend Developers was originally published in Google Cloud – Community on Medium, where people are continuing the conversation by highlighting and responding to this story.
Source Credit: https://medium.com/google-cloud/google-cloud-is-going-agentic-what-actually-changes-for-backend-developers-d1157d6f543b?source=rss—-e52cf94d98af—4
About the Author
