Over the past year, one phrase has been making the rounds in AI circles:

> Stop building apps for people. Start building them for AI agents.

That sounds super confusing to me. That sounds like “we should build backend apps so the agents can do API call”. For me, that sounds nothing novel. Naturally, I had to dig deeper.

The conclusion I came to is that this phrase is partly insightful and partly hype.

A better version of that point with more nuance is:

> AI agents will increasingly become the primary way humans interact with software. People still must have the ability to click and see the UI.

Let's put that into practice.

Sorry if I just made you crave pizza.

Let's start with how we've all been doing it for years.

The traditional, human-first approach

You:

1. open the pizza app

2. browse the menu

3. pick your toppings

4. enter your address

5. pay

Simple.

The application is designed around you clicking buttons.

Every screen, every interaction, every animation exists because a human is sitting in front of it.

We've all done this thousands of times.

Now let's imagine the same situation a few years from now.

The agent-first approach

Instead of opening anything, you simply tell your AI:

> "Order the same pizza as last Friday, but make it vegetarian and have it arrive around 7"

Your AI then:

- remembers your previous order

- knows your preferences

- talks directly to the pizza service

- places the order

- pays

- adds a reminder

- tells you when it's arriving

You never opened the pizza app, but the pizza app still exists.

The restaurant still has software.

Payments are still processed.

Orders are still tracked.

The difference is that another piece of software became the customer in your name.

The pizza application was no longer primarily designed for your eyes.

It was designed so another application, a.k.a your AI agent, could understand it and interact with it.

Booking travel is one of the best examples because it's something we've all experienced.

Today

Planning a business trip usually looks something like this.

You:

- open Google Flights

- compare 30 different options

- open Booking.com

- read reviews

- compare hotels

- reserve a rental car

- copy confirmation emails into your calendar

It isn't difficult, but it’s boring and super repetitive.

Agent-first

Now imagine saying only this:

> "I need to be in Berlin next Tuesday for two days. Keep the total trip under €800."

Your AI:

- finds suitable flights

- compares prices

- chooses a hotel

- checks your loyalty memberships

- books transportation

- pays

- sends receipts

- updates your calendar

Instead of opening six different websites, you review the final result.

The travel companies expose capabilities that your AI can consume automatically.

Again, the apps didn't disappear.

The way we interact with them changed.

For decades, software looked like this:

Human

↓

Application

Increasingly, we're moving toward this:

Human

↓

AI Agent

↓

Many Applications

The AI becomes the coordinator and the applications become services.

The human focuses on what needs to happen.

The AI figures out how to make it happen.

This is where things become really interesting.

Developers still need to ask the traditional questions.

> "How do we make this interface intuitive?"

> "How do we design a beautiful user experience?"

Those questions are not going away.

People will continue using applications directly, but there is now another equally important question.

> "How can another AI understand and use our product?"

That means thinking about things that weren't always considered first-class citizens.

For example:

- well-designed APIs

- structured data

- machine-readable documentation

- authentication and authorization for agents

- clear business actions such as "Create invoice", "Book meeting" or "Send email"

The graphical interface is no longer the only interface that matters.

Your API increasingly becomes part of your product.

This was actually my first question.

If we've had REST APIs for years, what's supposedly new?

And honestly...

That's a fair question.

A large part of what people call "building for agents" is simply building a really good API.

If you already expose a clean REST API and publish a proper OpenAPI specification, you're already much closer to being "agent-ready" than many people realize.

REST tells computers how to communicate.

OpenAPI tells developers, and increasingly AI systems, what your API does.

So why is everyone suddenly talking about agents?

Because an API alone isn't enough.

An AI doesn't magically discover your endpoints and start making requests.

Something still needs to tell the model:

- what actions are available

- when each action should be used

- what every parameter means

- what the expected outcome is

- which operations are safe

- which operations require confirmation

That's where the idea of tool calling comes in.

Instead of the model inventing HTTP requests, it is given a curated set of capabilities.

Think less:

> "PATCH /orders/{id}"

and more:

> "Cancel an order."

Think less:

> "POST /customers/messages"

and more:

> "Send a payment reminder."

Notice the difference.

One describes a technical endpoint and the other describes an intention. This was the key "AHA!" moment for me.

That's much easier for both humans and AI systems to reason about.

Traditional APIs often mirror database entities.

You might have endpoints like:

- GET /customers

- PATCH /orders

- POST /messages

That's perfectly fine for software developers.

But an AI works better when it understands higher-level concepts.

Instead of exposing dozens of low-level CRUD operations, you might expose capabilities such as:

- Find overdue invoices

- Draft a payment reminder

- Schedule a follow-up

- Send customer message

These map much more closely to how humans think.

The REST API underneath might not change at all.

You're simply exposing a more meaningful layer on top of it.

If you've been following AI development recently, you've probably heard about MCP, the Model Context Protocol.

A lot of people describe MCP as if it replaces REST.

It doesn't.

Think of it like this.

REST is still your engine.

OpenAPI is the technical manual.

MCP is the standardized plug that allows AI applications to connect to your system.

An MCP server typically exposes three things:

- tools (things an AI can do)

- resources (things an AI can read)

- prompts (reusable workflows and instructions)

Behind the scenes, those tools might simply call your existing REST API.

For example:

create_invoice

↓

POST /api/invoices

search_customers

↓

GET /api/customers

schedule_followup

↓

POST /api/tasks

Your REST API doesn't disappear.

MCP simply gives AI applications a standard way to discover those capabilities and use them.

In many ways, it's an adapter layer between your application and the growing ecosystem of AI assistants.

Because large language models have crossed an important threshold.

They're no longer just good at generating text.

They're becoming good enough to operate software.

They can:

- search

- reason

- compare options

- call tools

- combine multiple services

- execute multi-step workflows

They're starting to behave less like chatbots and more like junior digital employees.

Not at all.

Think about cruise control.

Cruise control didn't eliminate the steering wheel.

It eliminated repetitive work.

The same thing is happening with software.

People will still want interfaces for:

- browsing

- comparing options

- making important decisions

- editing information

- reviewing results

- handling exceptions

What disappears isn't the interface.

It's the repetitive clicking.

Searching.

Copying data.

Filling forms.

Switching between five browser tabs.

Agents become responsible for the busywork.

Humans remain responsible for judgment.

Imagine you're building a CRM.

Ten years ago, your roadmap probably looked something like this:

- customer list

- search

- edit customer

- sales dashboard

Today, you'd still build all of those.

But you'd also think about things like:

- APIs for creating contacts

- APIs for querying deals

- APIs for scheduling follow-ups

- permissions for AI agents

- structured documentation

- discoverable tools

- machine-readable schemas

Now imagine your user saying:

> "Find every customer we haven't contacted in the last 90 days and prepare personalized follow-up emails based on our previous conversations."

Instead of clicking through dozens of screens, the AI orchestrates everything.

The CRM becomes a platform rather than just an interface.

This is why I think the phrase:

> "Build for agents, not people."

is catchy, but ultimately misleading.

We're changing how people interact with software, but people are still here and must have a way to interact.

A much better way to say it would be:

> Build software that works beautifully for both humans and AI agents.

Humans still define the goals.

Humans still approve important decisions.

Humans still handle exceptions.

AI agents increasingly handle the repetitive execution in between.

The more I looked into this topic, the more I realized that the future isn't about replacing applications.

It's about changing who or what is using them.

The apps remain.

The APIs remain.

REST remains.

OpenAPI remains.

Your frontend remains.

What's changing is that another layer is emerging between people and software, AI agent.

The companies that succeed over the next decade probably won't be the ones that build exclusively for humans or exclusively for agents.

They'll be the ones that build exceptional experiences for both.

Because in the near future, your next user might not be sitting behind a keyboard.

It might be another piece of software acting on behalf of the person who is.