APIs were originally built to connect software. Today, they’re increasingly being designed to communicate with something entirely different—AI agents capable of reasoning, planning, and making decisions.
Introduction
Technology evolves in interesting ways. Sometimes a completely new idea replaces an old one. More often, however, familiar technologies quietly adapt to new realities without anyone noticing.
I believe APIs are going through exactly that transformation.
For nearly three decades, APIs have been the backbone of modern software. They allowed mobile applications to communicate with backend services, connected ERP systems with warehouses, synchronized CRMs with e-commerce platforms, and powered virtually every cloud service we use today.
Despite all the changes in programming languages, frameworks, and architectures, one assumption remained remarkably consistent.
The client consuming an API was another application written by a developer.
That assumption is beginning to change.
Today, more and more API calls are initiated not by deterministic software, but by AI agents. These agents don’t simply execute predefined instructions—they analyze user requests, discover available capabilities, choose the appropriate tools, and orchestrate entire workflows autonomously.
This may sound like a subtle shift.
In reality, it changes almost everything about how APIs should be designed.
APIs Were Designed for Software
Traditional APIs are remarkably predictable because their consumers are predictable.
Before a single HTTP request is ever sent, a developer has already read the documentation, selected the appropriate endpoint, understood the authentication mechanism, and implemented the integration.
A typical REST endpoint looks familiar to every software engineer.
POST /api/orders
Content-Type: application/json
{
"customerId": 142,
"items": [
{
"productId": 15,
"quantity": 3
}
]
}The response is equally predictable.
{
"orderId": 8174,
"status": "Created"
}Nothing here is left to interpretation. Every request follows a predefined contract, every response has a known structure, and every possible error condition has hopefully been documented somewhere in the API reference.
The API assumes something important.
Its consumer already understands how it works.
That assumption made perfect sense when the consumer was another piece of software.
It becomes much less obvious when the consumer is an AI.
AI Doesn’t Read Documentation the Way We Do
Imagine asking an AI assistant to create a sales order in your ERP system.
Unlike a traditional application, the model doesn’t have a hardcoded function called CreateSalesOrder() waiting inside its source code.
Instead, it starts with a much simpler question.
What tools are available that could help me solve this task?
That difference fundamentally changes how APIs are exposed.
Instead of presenting only endpoints, modern systems increasingly present capabilities.
Rather than exposing an HTTP operation, they describe an action.
{
"name": "create_sales_order",
"description": "Creates a sales order in Microsoft Dynamics 365 Business Central for an existing customer.",
"parameters": {
"customerId": "integer",
"items": "array"
}
}Notice what has become just as important as the parameters.
The description.
For years, documentation existed primarily for developers.
Now it exists for machines capable of understanding natural language.
We’re witnessing an interesting shift.
APIs are no longer explaining themselves only to humans.
They’re beginning to explain themselves to AI.
Function Calling Changed More Than We Realized
When OpenAI introduced Function Calling, many developers viewed it as just another feature added to an LLM.
Looking back, I think it represented something much larger.
Instead of asking the model to generate HTTP requests or invent API payloads, the application simply provides a collection of available tools. Each tool contains a name, a description, and a schema describing the expected parameters.
The model doesn’t execute anything itself.
It reasons.
It decides which tool best matches the user’s request, generates structured arguments, and hands the decision back to the application.
The application remains in control.
The AI remains responsible only for choosing the right capability.
This separation is elegant because it allows models to focus on reasoning rather than implementation details.
Whether the underlying system uses REST, GraphQL, SOAP, SQL, or even communicates directly with an ERP system becomes almost irrelevant.
To the model, everything looks like another tool.
JSON Is Becoming the Language of Intelligence
In a previous article, I wrote about how virtually every modern database is gradually becoming a JSON database.
Exactly the same evolution is happening at the API level.
Traditional software often exchanged JSON because it was convenient.
AI systems exchange JSON because they depend on it.
Consider these two responses.
The order has been created successfully.
Its identifier is 8145.
Expected delivery is Friday.A human immediately understands that response.
An AI agent has to interpret it.
Now compare it with this.
{
"orderId": 8145,
"status": "Created",
"estimatedDelivery": "2026-08-14"
}There is no ambiguity.
The model doesn’t have to guess which number represents the order identifier or whether “Friday” refers to this week or next week.
Everything has explicit meaning.
This is exactly why technologies such as Structured Outputs and JSON Schema have become so important.
Ironically, the rise of AI is making interfaces more structured rather than less.
OpenAPI Found a Second Life
One of my favorite examples of technological evolution is OpenAPI.
When Swagger first became popular, its primary purpose was helping developers understand APIs and generate client libraries automatically.
Nobody expected that years later those same specifications would become incredibly valuable for AI agents.
An OpenAPI document already describes endpoints, parameters, request bodies, authentication methods, and response structures in a machine-readable format.
It turns out that this information is almost exactly what an AI system needs to understand available capabilities.
Modern platforms can automatically transform existing OpenAPI specifications into AI tools with surprisingly little effort.
An API originally designed for software suddenly becomes understandable to intelligent agents without changing a single endpoint.
That’s a remarkably elegant evolution.
MCP Makes AI Integration Feel Like USB-C
If Function Calling changed how individual models interact with tools, Model Context Protocol (MCP) is trying to standardize the entire ecosystem.
I often compare MCP to USB-C.
Before USB-C, connecting external devices meant dealing with dozens of different connectors. Every manufacturer had its own solution, and every integration required custom adapters.
USB-C didn’t replace computers.
It standardized the connection between them.
MCP follows a very similar philosophy.
Instead of every AI application building custom integrations for every ERP system, CRM platform, file repository, or internal business service, organizations expose those capabilities through an MCP server.
Any compatible AI client can connect, discover available tools, understand what they do, and invoke them using the same protocol.
The underlying implementation remains completely hidden.
Whether a tool eventually calls REST endpoints, executes SQL queries, invokes Business Central APIs, or communicates with legacy enterprise software doesn’t matter anymore.
The agent sees one consistent interface.
For enterprise software, this may become just as important as REST APIs were fifteen years ago.
APIs Are Becoming Conversations
Perhaps the most fascinating change is that APIs are no longer limited to isolated, one-off requests. They have become active participants in ongoing conversations.
Imagine an AI assistant receiving a single, high-level request: “Find all unpaid invoices from last month, group them by customer, prepare a summary, and send it to the finance department.”
No developer had to explicitly code this multi-step workflow. Instead, the agent reasons through the task on its own. It discovers the available invoice service, calls the reporting tool, generates a summary, uses an email capability, verifies the results, and finally reports back to the user.
In this new paradigm, the API is no longer just answering individual requests – it is participating in reasoning. This represents a profound shift in how interfaces are used.
Designing APIs for the Next Generation of Clients
The fundamental principles of good API design remain unchanged. Authentication, versioning, reliable error handling, performance, security, and backward compatibility are still just as critical as they ever were.
What is changing is the identity of the primary client.
Tomorrow’s APIs will no longer be consumed solely by developers writing code in Python, Java, or C#. Increasingly, they will be used by autonomous AI agents — systems capable of reading rich descriptions, understanding schemas, recovering from failures, and intelligently selecting the most appropriate tools for a given task.
As a result, clear and detailed descriptions are becoming more valuable. Comprehensive metadata is gaining importance. Consistent and well-defined JSON schemas are no longer optional – they are essential.
An API is no longer merely a technical interface. It is evolving into a language that intelligent systems must be able to understand and reason with.
Conclusion
Looking back, it’s remarkable how quietly this transformation has taken place. There was no single revolutionary announcement declaring the end of traditional APIs. REST isn’t disappearing. OpenAPI isn’t becoming obsolete. JSON remains as relevant as ever.
Instead, all of these technologies are becoming more important than before.
What’s changing isn’t the core technology – it’s the client.
For decades, APIs were designed for deterministic software that followed predefined instructions. Today, they are increasingly serving systems capable of reasoning, planning, and making decisions on behalf of users.
Soon, we may stop talking about “AI APIs” altogether. They will simply be called APIs.
Because in the near future, every successful API will be expected to communicate naturally with both traditional software and intelligent agents.
And perhaps that is the most interesting part of this evolution: the biggest change wasn’t how APIs work – it was who started calling them.