Enterprise integration
API-led connectivity still matters in the agent era
Agents need tools. Tools are APIs. The MuleSoft and Azure programmes you already paid for are the substrate, not a legacy side quest.
It is fashionable to speak as if integration were a solved, slightly embarrassing problem from 2018. Then someone asks an agent to “update the customer,” and you discover the customer is four systems, two of which are batch, and one of which is a stored procedure named sp_do_the_thing.
API-led connectivity — system, process, experience — was never about MuleSoft as a religion. It was about not building a new point-to-point every time a channel appeared. Agents are just another channel. A very impatient one.
What we reuse
If you already have:
- stable system APIs with auth that a human can understand,
- process APIs that encode “quote to cash” instead of “call these seven things,”
- an experience API that a portal already uses,
then an agent’s tool catalog is mostly mapping and policy. That is a weeks-long job. If you do not have those, the agent project becomes a covert ESB rebuild with a chatbot on top. That is a years-long job, badly named.
Events, not just request/response
Agents that poll are expensive and late. The interesting enterprise patterns now are: event in, agent proposes, human or policy approves, write back, event out. Kafka, EventBridge, Service Bus — pick the one your platform team can operate at 2am.
Governance that people will follow
The graveyard of API programmes is a portal nobody searches and a review board that meets monthly. Agents will ignore both. Put contracts in the repo. Generate the catalog from the same source. Make breaking changes loud.
We still implement this on MuleSoft, Azure Integration Services, AWS, Kong, and the rest. The platform is a choice. The need for a contract is not.
If your 2026 AI roadmap does not have a line item for “make the APIs real,” it is a 2024 demo with a new title.
