Beyond MCP
How Capability, Ecosystem, and Systems Thinking Deliver Real Strategic Value
One of my last LinkedIn post sparked more debate than I expected. I questioned whether the Model Context Protocol, MCP, really represents the future for AI integration or if it is simply setting us up for the next generation of vendor lock-in and brittle architectures. Guilhem Maillebuau jumped in with the kind of question that cuts to the core:
“So, what is your solution after saying that?”
It is the right question and deserves an honest, detailed answer.
This debate has grown, drawing in perspectives from Erik Wilde’s thoughtful takes on workflow patterns, Mike Amundsen’s call for ecosystem-first service design, and most recently Julien Simon’s clear-eyed critique of MCP’s technical shortcuts.
Taken together, these conversations challenge us to look past short-term convenience and ask what it really means to build for a world where digital ecosystems are driven by autonomous agents and not just humans.
The Allure and Limits of MCP
Why does MCP seem so appealing? It promises speed and simplicity. By wrapping business logic and context into a single contract, MCP makes it seem as if AI agents can integrate instantly, without grappling with legacy complexity. In organisations under pressure to deliver, this shortcut is deeply tempting. Barriers melt away, demos look impressive, and early experiments are easy to launch.
Yet this surface-level convenience hides real risk. Julien Simon points out that MCP skips decades of hard-won lessons from distributed systems and remote procedure call design. Without mature standards, every implementation can interpret data types, error handling, and versioning in its own way. The quick wins of today become technical debt, integration headaches, and support issues tomorrow.
As MCP wrappers multiply, so do hidden dependencies and brittle silos. Instead of true openness, you end up with new flavours of lock-in. Practical dangers like missing error handling, inconsistent observability, and weak data validation can become existential risks in domains where resilience and trust are critical. The shortcuts eventually catch up with you.
Capability Thinking: Focusing on What Matters
If shortcuts cannot create resilient openness, what is the real alternative? Capability Thinking is an approach rooted in enterprise architecture, event-driven design, and modern API strategy. The focus shifts from exposing data or technical resources to clarifying what your system can actually do for its consumers.
When you design around capabilities, you express your platform in terms of discrete, intention-driven business functions. Actions like “Process Payment,” “Ship Order,” or “Approve Loan” become self-contained building blocks with clear inputs, outputs, and business meaning. Capability Thinking insists on documenting and standardising these capabilities, making them discoverable, reusable, and easy to compose. Julien Simon’s critique of MCP only reinforces this need for discipline. With a clear capability model, you reduce the temptation for workarounds and build the foundation for flexibility.
This thinking draws from sources like TOGAF’s capability mapping, Domain-Driven Design’s aggregates, and the broader field of business architecture. It is about enabling business value, not just technical access.
Ecosystem Thinking: Designing for Real Collaboration
Defining capabilities is only the beginning. The real impact emerges when you design for participation in a larger network, an ecosystem.
Ecosystem Thinking means designing APIs, services, and capabilities with the intention that others, inside and outside your organisation, will discover, use, and build on them. Mike Amundsen’s advocacy for discoverability and indirect value, Mark Boyd’s detailed analysis of API economies and platform roles, and my own work on API thinking and federation all point in the same direction. Technology is only a part of the ecosystem; business models, roles, shared governance, and patterns of trust are just as important.
When you invest in documentation, discoverability, and standards, your platform becomes more than a set of technical functions. It turns into a landscape where new connections and value can emerge. Ecosystem Thinking is about opening up, designing for collaboration, and welcoming innovation, even from unexpected sources. It is a commitment to interoperability, clarity, and enabling others to create value beyond what you imagined.
The Limits of Resource-Centric Design
As we move toward Capability and Ecosystem Thinking, it is important to honestly assess our tools. Most API description languages like OpenAPI are built around REST and resource orientation. REST is excellent for exposing data entities and relationships with standard verbs, and OpenAPI brings discoverability and machine readability to this world. If your business needs public data services or CRUD operations, this approach is still the gold standard.
But capabilities are not data resources. They represent intent, business outcomes, and meaningful actions. Forcing these into resource endpoints often leads to awkward abstractions or diminished clarity. Event-driven and command-driven architectures, described using standards like AsyncAPI and CloudEvents, offer a much more natural way to model what your business can actually do. They express actions and outcomes such as “Process Payment,” “Ship Order,” or “OrderShipped” directly and explicitly.
The honest conclusion is that you should not limit your architecture to resource-based design. Use REST and OpenAPI for data-centric scenarios. For true business capabilities, lean into event-driven and command-driven patterns. This lets both humans and agents understand, compose, and extend your business with clarity and intent.
Workflows as Bridges: Connecting Capabilities to Real Outcomes
Workflows are where capabilities, resources, and ecosystems intersect. Every meaningful business outcome is a workflow, a sequence of actions that delivers value. Erik Wilde’s catalog of workflow patterns demonstrates how these can be orchestrated through engines, direct service calls, or even agent-driven logic.
What matters most is the quality of your capabilities and how discoverable and reusable they are. When workflows are composed of strong, well-documented capabilities, they are easier to adapt, recombine, and extend. This gives your architecture the resilience to evolve with business needs and the flexibility to participate in larger, more dynamic ecosystems.
Systems Thinking: Seeing the Bigger Picture
To build platforms and ecosystems that thrive over time, we must step up to systems thinking. Donella Meadows’ foundational book, Thinking in Systems, provides the vocabulary and insight to see technology, people, processes, and incentives as an interconnected whole. She explains that to change a system, you must pay attention to feedback loops, leverage points, and the structure that shapes outcomes, not just the individual components.
Peter Senge brought these ideas into organisational life with The Fifth Discipline, teaching leaders to use systems thinking to foster learning and adaptability. Michael C. Jackson, in Critical Systems Thinking and the Management of Complexity, shows how organisations can use multiple perspectives to address interconnected challenges. Diana Montalion brings this tradition directly to the software world, showing architects and engineers how to treat architecture as a living, dynamic system of feedback, context, and emergent behaviour.
With systems thinking, every protocol, capability, and workflow is seen as part of a much larger pattern of interactions and feedback. Decisions about how to design or document an API ripple out to affect teams, governance, operational risk, and business value. Feedback loops matter. A shortcut like MCP may deliver initial speed but bring hidden costs that surface later. A clear, open capability model may be slower at first, but it creates positive feedback, enabling learning, partnership, and unexpected value.
Systems thinking also brings the human and organisational dimension to the foreground. Team incentives, culture, documentation practices, and governance are just as much a part of the architecture as protocols and services. The system is not just technical; it is social, economic, and adaptive.
A Playbook for Architects: Principles into Practice
How do you put all of this into action? Start by cataloging your system’s capabilities in language that makes sense to both business and technical audiences. Use standards intentionally, with OpenAPI for data resources and AsyncAPI or CloudEvents for business actions and events.
Design each capability with both the ecosystem and the broader system in mind. Make your documentation open, clear, and discoverable. Regularly review how your architecture supports learning, adaptation, and positive feedback. Pay attention to how teams use, combine, and build on what you have created, and treat these signals as opportunities for continuous improvement.
A Practical Example: Capabilities in Action
Consider a classic order fulfilment use case. Traditional design might expose endpoints for order creation, inventory checking, and shipping. With Capability Thinking, “Ship Order” becomes a well-defined business action, modelled using AsyncAPI or CloudEvents. The action and its outcome are explicit and open to both human and agent consumers. As partners or requirements change, the capability stays stable and workflows adapt without rewrites.
Systems thinking pushes this further. You monitor how “Ship Order” is used, look for emergent uses and feedback, and refine both the technical and organisational systems supporting it. The architecture and the behaviours it enables form a living, evolving system.
Conclusion: From Architecture to Living Systems
The next generation of digital platforms will not be defined by the latest protocol or even by technical capabilities alone. The real foundation is in designing and sustaining living systems. Capability Thinking and Ecosystem Thinking give us the building blocks. Systems Thinking weaves them into a resilient, adaptive, value-creating whole.
The real solution is not just another tool, but the discipline to define clear capabilities, the vision to design for participation and emergence, and the maturity to govern and evolve the entire system as it grows. When you approach architecture this way, you create platforms that are robust, innovative, and ready for whatever the future brings.
Do the hard work now, and you position yourself not just for immediate wins, but for lasting and collective value, created by people, partners, and the autonomous agents that are shaping the next era.