Composable Integration for Intelligent Systems

Depending on who you talk to, AI is either the biggest opportunity or the biggest threat since the dawn of computing… or both! Whichever side of the debate you’re on, navigating this precipice will be the predominant challenge for software engineers over the next several years. This is especially true for enterprise organizations trying to balance their existing assets with the seeming need to rewrite everything from scratch for an agentic world. Existing data sources and APIs can provide essential contributions to intelligent systems, but it’s easy to forget the value of what already exists when there is so much focus on novelty.

Indeed, groundbreaking innovations, combined with the acceleration enabled by AI coding assistants (and a dose of FOMO), are driving a huge wave of new software. It’s reinvigorating engineering teams, but enterprise organizations are right to be a little paranoid. The Model Context Protocol (MCP) exemplifies this tension perfectly. New powerful tools are available daily, and agents can start working with them after a simple config file update. Yet these new interaction models are moving so fast that security measures are not able to keep pace. This is a pattern we can expect to see many times as novel AI technologies and protocols continue to emerge.

The enterprise challenge boils down to this: don’t rewrite everything, but do recognize the need to disrupt the status quo in order to take full advantage of the opportunity. The Agentic Enterprise requires a mindset shift but still benefits from traditional integration strategies. It’s likely going to require breaking down silos and decomposing monolithic systems. But re-composing what’s salvaged and aligning those components with new types of infrastructure and middleware is an integration problem. And like any integration problem, it requires well-defined boundaries.

Boundaries

Boundaries should be explicit and enforceable. Essentially, they provide the contracts for what can be connected. They also establish the seams that enable directing attention where it’s needed for building a self-regulating system.

Some key examples of such seams:

• determinism vs non-determinism: knowing where to expect liability
• human vs agent-driven: knowing where to enforce policy
• pure logic vs side-effects: knowing where to monitor change
• differentiated vs un-differentiated: knowing where to focus effort

Composition

Clear boundaries enable composition, but a component model that supports nesting and enforces isolation enables much more.

Nesting adds a dimension that fully unlocks the promise of an adaptive system across dynamic environments. Wrapping components can apply cross-cutting concerns without requiring redundant implementations.

Isolation ensures that the power of composition can be utilized without sacrificing security. Isolation combined with nesting enables encapsulation of data or functionality that should not be accessible beyond its boundaries even across components within the same process.

The Wasm Component Model meets that definition with:

• sandboxed execution
• explicit imports and exports
• least-privilege capability enforcement
• portability across environments
• nest-able polyglot composition

The Component Model is still in preview status, but it already delivers on the above characteristics. It’s an immensely promising technology for meeting the needs of agentic integration as both continue to evolve. The Modulewise perspective is that the stronger the need for zero-trust and composability, the more apparent it will be that Wasm is the enabling technology. As you will see in future posts, Wasm Components are already capable of addressing current gaps and playing a valuable role for integration.

Integration

As we’ve seen with MCP tools, there’s a strong demand for making connections between new things and existing things. And just as agents need to connect to tools, they also need to connect to each other. Indeed, multi-agent collaboration is proving to be powerful, and agent frameworks are increasingly where the action is. But as with APIs, data services, and the cloud native landscape, the typical enterprise organization will end up using many models, agents, tools, protocols, and frameworks. We can expect this proliferation and fragmentation across the AI landscape to continue indefinitely.

Meanwhile, customers expect new business outcomes faster than ever, and that means not only building features but continuously adapting to changing dependencies. In other words, it’s an integration problem.

The integration patterns look familiar but with some new twists:

• transformers: augment prompts and generate content from prompts
• routers: delegate across agents and models
• aggregators: combine results from multiple agents and models
• adapters: expose APIs and data sources as tools to agents

The above list just scratches the surface. You can expect much more in future blog posts, including composite patterns and the role of messaging in the management of agentic autonomy. That is a key part of the shift: allowing freedom by managing constraints. And that leads to thinking in systems.

Systems Thinking

As seems to happen after any significant trend in software, we are entering the inevitable phase of the workflow engines. But this time is different, because taking full advantage of an intelligent system means allowing agents to drive some degree of the decision-making and action-taking. How much they drive should be configurable, and that’s why observability and security measures are more important than ever. And all that stuff above about boundaries and contracts is not just theoretical. It’s all about enabling a shift from predetermined imperative actions to contextual declarative goals. From a workflow perspective, the emphasis should be on “flow”. That means embracing non-determinism but being able to adapt and react as needed.

Thinking in systems means thinking of agents as themselves being loops. At times it does make sense to have a human in that loop, able to accept or reject the agent’s decisions and actions at a fine-grained level. Realistically though, in enterprise-scale systems, there will be many such loops where decisions and actions are too frequent to be monitored individually. Humans exist in their own loops, providing and receiving feedback.

This is the Modulewise view of the Agentic Enterprise:

Agents will call Tools, and they will coordinate with each other by sending and receiving Messages. Humans need to automate as much of the “in the loop” part as possible. They do that by adding Observers, which may record an audit log of tool calls or subscribe to the same Messages as the Agents. Observers may be configured with Service Level Objectives (SLOs) where they react based on thresholds. That could involve suspending an action while awaiting explicit human approval, or Observers could pass context to Advisors. The Advisors may apply policies, such as access control rules, or they may delegate to Agents to act on their advice. Agent identity will be an important piece of allowing this degree of autonomy.

To be clear, this is an initial high-level vision, and it will certainly evolve as the various pieces are built. Those pieces are currently being built as Wasm Components with the benefits as described earlier.

Building Castles

The four component categories above reveal a fitting acronym: MOAT (Messages, Observers, Advisors, Tools). Agentic enterprise systems are like a castle: sprawling and fortified yet open for commerce. As these systems evolve, new models, tools and frameworks will enter the castle grounds. Modulewise is unopinionated about which models, languages, or frameworks you use for building agents. We know that space will be in flux for quite some time.

That is why we are focusing on the integration layer, facilitating interactions between agents and tools, between agents themselves, and between humans and agents as they collaborate on business outcomes. Modulewise aims to insulate your differentiated business value from changes in the ecosystem and to surround your agentic enterprise castle with observability, access control, and various components that promote self-regulation.

What’s Next

This post introduced why composable integration is especially relevant to intelligent systems. The next post will provide a first look at what’s being built to support the vision above, starting with Tools. It will feature an MCP Gateway that hosts Wasm Components by dynamically generating their MCP Tool interfaces. It will also feature a “Toolsmith” meta-Tool that generates Tool Components through composition with reusable base Components while enabling credential encapsulation and observability. In the meantime, you can find Modulewise on LinkedIn and X.