Most companies building AI agents already have the hardest part in production: the product works, the business logic exists, and in many cases an API already exposes most of what the product can do.
Yet when we build an agent, and then an MCP server, we tend to create new integrations for capabilities that already exist. Over time, we end up maintaining several representations of the same product, with all the duplication and drift that comes with it.
We need to stop treating APIs, MCP servers and agents as separate products. They are different layers of the same stack.
We are rebuilding the same product over and over
Take a common feature such as refunding an order. Your backend already knows how to do it, and your API might expose something like this:
GET /customers/{id}
GET /orders
GET /orders/{id}
GET /orders/{id}/refund-eligibility
POST /orders/{id}/refund
The business rules already live somewhere behind these endpoints: which orders can be refunded, how much can be refunded, which user is allowed to do it, what happens when the payment provider rejects the operation, how the event is logged, and so on.
Then you build an AI assistant inside your product. You create functions such as find_customer, list_customer_orders, check_refund_eligibility and refund_order. That makes sense. The model needs a way to interact with the product.
Later, you decide to expose the same capabilities through MCP so users can access them from Claude, ChatGPT or another MCP-compatible client. You create another set of tools, with another mapping between the model and the same API.
Again, the wrapper code itself may not be huge. That is not really the issue. The problem is that you now have several representations of the same capability, maintained in different places and often by different teams. When the API changes, every representation has to change with it. When a permission changes, every layer needs to behave consistently. When you improve error handling, pagination or output filtering, you need to remember every place where the same integration exists.
This is how drift starts.
How did we get here?
The current situation is actually quite logical when you look at the timeline. APIs have been around for decades and were designed so applications and developers could programmatically interact with a product. Then AI agents arrived, and most early agent projects were experiments: an internal assistant, a chatbot, a Copilot-like feature. Teams wanted to ship quickly, so they created the functions they needed to connect the model to the product.
Then MCP arrived and gave the industry a standard way to expose tools to AI applications. Suddenly, there was a new integration surface to build.
Each decision makes sense in isolation. Together, they create an accidental architecture where the same product capabilities are exposed several times through parallel projects.
The gap is visible in the numbers too. According to Postman’s 2025 State of the API report, 82% of organizations have adopted an API-first approach to some degree, while only 24% of developers say they actively design APIs with AI agents in mind. In other words, the API infrastructure already exists almost everywhere, while the agent infrastructure is being built now.
This is precisely the moment when we can decide whether to reuse what already exists, or create another parallel stack.
Duplication is annoying. Drift is dangerous.
Duplicating a few hundred lines of glue code is rarely what kills a project. The bigger problem appears six months later, when the product starts changing.
Imagine the refund flow evolves and refunds above a certain amount now require an additional validation step. The backend changes, and the API changes with it. What happens next depends entirely on how many independent integrations you have created. Maybe the embedded agent is updated immediately. Maybe the MCP server is updated two weeks later. Maybe another agent keeps using the old flow for three months.
You now have several AI interfaces giving users different behavior for exactly the same product capability.
The same problem applies to schemas, permissions, errors and observability. A field is renamed in one place but not another. A new authorization rule is enforced by one integration while another still accepts the old behavior. A bug gets fixed in the agent tool but not in the MCP tool. None of this is particularly dramatic on day one, but the maintenance cost compounds over time.
Security deserves special attention here because MCP is not just a transparent proxy in front of an existing API. It introduces its own protected-resource boundary and its own authorization flow. That is a good thing, but it also means that every independent MCP or agent integration adds another place where authentication and authorization need to be implemented correctly.
The goal should not be to pretend MCP somehow inherits all the security of the underlying API automatically. The goal should be to keep business permissions centralized in the product and expose them through one consistent, auditable agent-facing layer.
APIs, workflows, MCP servers and agents each have their own job
Part of the confusion comes from mixing responsibilities. An API, an MCP server and an agent are not interchangeable interfaces, and treating them as such usually leads to poor abstractions.
The product should remain the source of truth for data, business rules, permissions and side effects. Whether an action comes from your web app, your mobile app or an AI agent should not change what “refund this order” actually means.
The API is the programmable contract to those capabilities. OpenAPI can describe operations, inputs, outputs, authentication mechanisms and schemas. It tells a developer what can be called and how. This is extremely valuable, but it does not always tell an agent what the user is trying to achieve.
That is where workflows come in. A user does not usually think “call /orders, extract an ID, call /refund-eligibility, then call /refund”. They think “refund John’s last order”. That intent may require one API call or five, and a workflow turns that intent into a deterministic sequence of operations.
MCP then gives AI applications a standardized way to discover and execute those capabilities. A good MCP server should expose meaningful tools without asking the model to understand every internal detail of your API architecture.
Finally, the agent owns the user experience: understanding the request, choosing the right capability, collecting missing information, asking for confirmation when necessary, and presenting the result. That is where the model adds value. It should not be where you reimplement the backend.
Build a stack, not three parallel projects
Once responsibilities are clear, the architecture becomes much simpler:
The important part is what happens at the top of this stack: a new agent is no longer a new product integration. It becomes a new client of capabilities you have already prepared for agents.
An assistant inside your product, ChatGPT or Claude, a Slack bot or a headless agent can all rely on the same MCP server and the same underlying workflows.
And this is where standardization starts paying off.
Changes should propagate, not be synchronized manually
There is one important caveat: putting MCP on top of an API does not magically eliminate drift. If you manually write a server and never update it, it will drift just like any other integration.
The difference appears when each layer is derived from and validated against the one below it. Then a feature change has a clear propagation path:
You still need versioning, tests and agent evaluations. What changes is that you no longer need several independent teams to notice the same change and manually reproduce it in different codebases.
You turn a synchronization problem into a lifecycle, and that is a much easier problem to automate.
APIs already have a mature ecosystem for exactly this kind of lifecycle: contracts, CI/CD, diffs, previews, versioning and breaking-change detection. We should reuse it instead of rebuilding the same machinery for every new agent project.
Build less, ship more
Once your API and agent-facing capabilities live in the same stack, several things become much simpler. You write less integration code as business logic stays behind the API, you reduce drift, you expose better tools perfectly representing user intentions and you get more consistent security and observability models.
But the most important benefit, in my opinion, is that the next agent becomes much cheaper to build. Most of the hard work (connecting to the product, handling authentication, defining and executing tools, observing what happens) has already been done.
The next AI experience becomes mostly an experience problem, which is exactly what an agent team should be spending its time on.
This is what we’re building at Bump.sh
This is also the architecture we’ve been building Bump.sh around.
We already use API contracts as the source of truth for documentation, diffs, previews and developer portals. With the Bump.sh MCP Platform, we now use the same foundation for agents: define workflows on top of your existing APIs using Arazzo or Flower, and turn them into production-ready MCP servers. Bump handles the rest: hosting, authentication, secrets, execution and observability.
The same server can then power any number of AI experiences. Connect it to existing MCP clients, or use Agent mode to embed a chat into your product or build your own experience with the headless client. In every case, agents use the same workflows instead of creating another integration with your product.
This is how we use the platform ourselves. Our API documentation MCP server is built on top of our existing Portal API, with workflows designed for agents rather than a new implementation of the same capabilities. You can read more about it in How we built an API doc MCP server, using our own MCP platform.
Your product already works, and your API already exposes its capabilities. Making it available to agents shouldn’t mean rebuilding them every time a new AI interface appears.
APIs, MCP servers and agents should be one stack, not three products.
