The answer depends entirely on integration.
Agents without integration are just chatbots
Think about what an agent needs to be useful in an enterprise context:
- Access to customer data in your CRM
- Ability to create orders in your ERP
- Context from multiple systems to make informed decisions
- Permission to trigger real workflows across your organisation
Without robust integration, you’ve built an expensive chatbot that can talk about work but never actually do work. Integration isn’t a supporting concern, it’s the foundation that determines whether your agent investment pays off or becomes shelfware.
The MCP protocol changes the game
The Model Context Protocol (MCP) is emerging as a standardised way to expose backend capabilities as tools that AI agents can discover and use autonomously. Instead of manually wiring each agent to each system, MCP creates a layer where:
Backend systems expose capabilities as described tools
Agents discover and understand these tools semantically
Orchestration happens autonomously based on context
As part of our internal competency build-up we recently built a hands-on implementation using IBM’s webMethods hybrid integration and watsonx Orchestrate to explore this pattern in practice.
What this looks like in practice
Our scenario involved customer and order management, common operations that typically span multiple systems. The architecture looked like this:
Integration layer: Using webMethods, we built flow services and workflows for business logic. These connect to backend systems (or in our case, a simulator for quick prototyping). The visual flow builder handles the complexity of orchestrating multiple backend calls, data transformations, and error handling.
API exposure: Selected services become RESTful APIs through the API Gateway. You get OpenAPI documentation, secure access via API keys, and a developer portal automatically.
MCP tooling: Here’s where it gets interesting. APIs can be configured as MCP tools with minimal additional work. The platform automatically translates your API definition into something agents can discover and understand.
Agent layer: In watsonx Orchestrate, agents see these tools and can reason about when to use them. Query customer data, process orders, orchestrate multi-step workflows, all without manual intervention.
Why developers should care
You’re already building the foundation: If you’re doing API-driven architecture, you’re most of the way there. The shift to agent-consumable tools isn’t a rewrite, it’s an extension of patterns you already know.
Visual tools that don’t get in the way: The flow service builder is genuinely useful for complex integration patterns. You’re not fighting with XML or writing boilerplate—you’re focusing on business logic while the platform handles connectivity and transformation plumbing.
One service, multiple consumers: A flow service you build today can serve a traditional REST client, a batch job, and an autonomous agent tomorrow. Building with this flexibility in mind pays dividends.
MCP abstracts the boring parts: You don’t manually describe every parameter and response for agents. The tooling infers this from your API definition. This dramatically shortens the path from “I have a backend capability” to “my agent can use this capability.”
The strategic reality
Organisations with mature API and integration strategies consistently outperform those without—often showing double the revenue growth. As AI adoption accelerates (with predictions of 75%+ of software spend involving AI by 2028), integration becomes the differentiator.
Two companies might deploy the same AI model, but the one with better integration delivers dramatically more value because their AI can actually do more.
AI investment without integration investment is wasted money. Your agent can’t help if it can’t access customer records, create orders, or trigger fulfillment.
Five practical takeaways
- Design APIs for agent consumption from the start: Think about autonomy, clear descriptions, and appropriate guardrails. Retrofitting is harder than building with intent.
- Not every API should be an autonomous agent tool: Architectural decisions matter. Some operations need human oversight, others are perfect for agent autonomy.
- Security models change: Agents need scoped permissions and audit trails. Design for programmatic access patterns, not just human users.
- Test with real agent behavior: Agents use APIs differently than humans—different error patterns, retry logic, and usage sequences. Don’t just test with Postman.
- Start with simulators: In our scenario we used a backend simulator to validate patterns before dealing with real backend complexity. Prototype fast, then connect to production systems.
What’s next
The convergence of integration platforms and agentic AI isn’t future speculation—it’s available to build today. Using unified toolsets like IBM’s webMethods Hybrid Integration and watsonx Orchestrate dramatically shortens time to market because you’re working in one environment with consistent patterns, shared authentication, and automatic translation between layers.
For developers, this means:
Faster prototyping: Get to a working demo in hours, not weeks
Fewer handoffs: Integration developer, API engineer, and agent builder can be the same person
Production-ready from the start: Enterprise-grade features (security, versioning, monitoring) out of the box
- Lower learning curve: Master one toolset instead of stitching together five different technologies
Traditional integration development involves significant overhead across multiple tools and codebases. This unified platform collapses that complexity, letting you validate business value quickly, iterate based on feedback, and scale successful patterns without architectural rework.
The future of enterprise automation isn’t just smarter agents. It’s smarter integration, built with modern tooling, that makes those agents actually useful.