From API to Agent

For as long as I’ve built software, the contract was the same: humans operate interfaces, interfaces operate systems. Agents break that chain. More and more, software is being operated by software — you describe what you want, an agent goes and does it, and the interface you’d normally click through never enters the picture.

This isn’t science-fiction shorthand anymore. You can already find people running setups like this — an agent maintaining a project more or less on its own, the human stepping in mostly to check what it did and approve. A small team of autonomous workers, supervised rather than operated.

None of this is a single breakthrough. It’s a couple of quieter shifts stacking up — in how we talk to machines, and in what we let them do once they understand us. Worth pinning those down before guessing where they lead.

What’s actually changing#

Strip away the hype and the shift is concrete. The conversational interface (CUI) has crossed a threshold where “ask the machine in plain language” is a usable interaction model, not a party trick. At the same time, agents — models that don’t just answer but take actions in a loop — have gotten good enough to chain several steps together without falling apart.

Put those together and the center of gravity moves. The interface stops being the thing you operate and starts being something an agent operates for you. That’s a genuine change in what an “app” is. It might be a chat. It might be a voice. It might be no visible surface at all, just an outcome that appears.

What’s been missing, until recently, is the boring connective tissue: how does the agent actually reach your systems? A model that can talk but can’t touch your data or trigger a real operation is just an eloquent dead end.

MCP, and why the API stays central#

That connective tissue is what the Model Context Protocol (MCP) standardizes. It gives an agent a way to discover which tools exist, understand what each one expects, and call them safely. An agent might discover a create_order operation, learn that it needs a customer and a list of products, and invoke it — without a developer hand-writing a separate integration. It’s young and moving fast, but it’s the most credible bridge I’ve seen between “the model understood you” and “the system actually did the thing.”

And here’s the part that matters for those of us who build software for a living: MCP doesn’t replace the backend, it consumes it. The agent still needs something on the other side that knows the rules — what’s allowed, what validates, what’s secured, what an “order” or a “customer” even means. That something has been the API all along. The chain just gains a link: Human → UI → API becomes Human → Agent → API, sometimes Human → Agent → UI → API. The interface shifts or disappears entirely; the API remains the boundary around what the business can actually do.

This is the part that excites me. For years the API has been the cleanest entry point a company has into its own logic — the place the business rules live, stable while front-ends came and went. The agentic layer is just the newest consumer knocking on the same door. You don’t rebuild your domain to make it “AI-ready”; if you modeled it honestly, the work is largely done. Which turns the broad question — how do existing systems expose themselves to agents? — into a concrete one: how does your API do it?

I maintain API Platform, so I’ll point at what I know: it integrates MCP directly. The same metadata that already described your resources, your validation and your security becomes the set of tools an agent is allowed to call. Your existing #[ApiResource] turns into something an agent can use, without a second, parallel description of your domain written just for the AI. The API stays at the center; MCP is the adapter.

Where it gets genuinely uncertain#

Here’s where it gets fun. MCP even has an extension, MCP UI, where a tool can return a rendered interface — a form, a chart, a confirmation — drawn inside the conversation. So just as you’d bet the graphical interface is dissolving, it walks back in, summoned by the agent exactly when a human should be the one looking — which is either reassuring or the whole problem, depending on the day.

Which leaves the big question wide open: will apps become conversational, or stay graphical, or turn into some hybrid we don’t have a word for? I genuinely don’t know, and I’m wary of anyone who claims they do. If the conversation can draw a screen, and the screen can hand control back to the conversation, then “CUI versus GUI” might just be the wrong way to frame it. And underneath sit harder questions — if an agent can read the very interface it rendered, who is that screen still for? Does it stay the place a human stays in the loop, or quietly become a process we no longer watch?

I don’t have answers. What I’m fairly sure of is the foundation. Whatever an “app” turns into, it needs a layer underneath that holds the rules, guards the data, and exposes operations safely. For developers, that’s still the API — the one constant from the click-a-button era through to whatever this becomes.

So if you’d rather poke at this future than be handed a verdict about it, start from something you already have. API Platform is one way in: take an existing API, expose its operations through MCP, hand it to an agent, and see what happens.

The future of the interface is up for grabs.

The API, I think, is not.