Technical possibility is no longer the hard part
The question “Can we build it?” is becoming irrelevant in enterprise technology.
Vibe coding has collapsed the distance between an idea and a working demo. The market has mistaken that for collapsing the distance between a demo and production. It has not. Business users can now build useful interfaces and automations without waiting for traditional development cycles, but ease of creation does not provide architecture, governance, resilience, security, or operational ownership.
An employee can access an enterprise application in a conversational way through an MCP-connected interface. One Genie can begin a task and assign part of the work to another Genie. A conventional workflow can use an LLM to interpret a document before continuing through established business logic.
The technology can support all of these patterns.
The more consequential questions are whether the resulting capability can be reused, governed, and continue to work when the agent platform, model, protocol, or interface changes.
That is why architecture is the central challenge of enterprise AI.
The agent is visible to the user. The architecture beneath the agent determines whether the experience can survive prolonged contact with the enterprise.
Three AI patterns should not become three technology stacks
If every AI experience requires a new integration, the architecture has already failed.
Massimo’s article, “To Succeed With Agentic AI, You Need an Orchestration Strategy”, describes three dimensions of enterprise AI orchestration. Enterprises must connect agents to applications and data, enable agents to work with one another, and incorporate agents into deterministic business processes.
Those dimensions map closely to the patterns I encounter with Workato.
The first pattern is conversational access to systems of record through MCP.
MCP connectivity can provide a practical route for connecting AI interfaces to enterprise applications, bringing the context and actions the enterprise needs to AI, making it much more useful.
The second pattern is collaboration between agents.
A Genie may begin a task, determine that another Genie has the right specialisation or access, and hand off part of the work. This allows a complex process to be divided into bounded responsibilities, rather than requiring a single agent to understand and perform everything.
The third pattern is AI embedded inside a traditional workflow.
When an invoice is received, AI can parse it to extract the supplier, invoice number, total, and line items. A Workato recipe can then validate the information, retrieve the associated purchase order, locate the relevant NetSuite records, apply business rules, identify discrepancies, and determine next steps.
These experiences may look very different, but they should participate in the same governed capability architecture, whether they consume, orchestrate, or represent an enterprise capability.
MCP can standardise connectivity and still create chaos
A common protocol does not guarantee a coherent enterprise.
MCP is creating an increasingly important way for AI interfaces and agents to discover and invoke tools. But protocol standardisation does not automatically make those tools reusable, efficient, governed, or production-ready.
An MCP server can expose dozens of granular application operations and leave the model to decide which actions to call, in what sequence, what information to retain, and how to recover when a step fails.
Technically, that may work. Architecturally, it recreates the worst characteristics of point-to-point integration. Each agent is responsible for its own sequencing, business rules, application dependencies, failure handling, and process interpretation. As more agents are added, the same enterprise process is implemented repeatedly in slightly different ways. Connections multiply, logic diverges, controls drift, and every application change creates a growing web of dependencies.
The protocol may be standardised, but the architecture is still point-to-point. It is simply point-to-point integration with a model making the calls, and the architect’s worst nightmare.
The Workato article on why AI agent costs keep rising describes the difference between exposing a collection of low-level actions and exposing a bounded, outcome-oriented business capability. When the agent must coordinate each operation itself, the process requires more reasoning, more context, more latency, and more opportunities for error.
An agent does not need unrestricted access to every raw operation in an application. It needs access to the right enterprise capability. That capability should have clear inputs, bounded behaviour, embedded business rules, predictable failure handling, and a structured result.
Speed to the first connection should not be confused with the final enterprise architecture. As a use case matures, its tools should become part of a reusable and governed capability layer. Otherwise, every new agent brings its own connections, credentials, workflow logic, and interpretation of the same business process.
That is not an AI strategy. It is an integration sprawl with a conversational interface.
In Workato, we used the starter templates provided by the product to quickly roll out MCP servers that matter most to our users – assessing customer context across Salesforce and Gong, retrieving calendar events for the day from Google Calendar, or creating Jira tickets. The team then examined how our users interacted with these MCP servers and iteratively enhanced them to better fit our needs. The MCPs were also built from the start as services that all MCP clients will use to connect to systems of record, and were implemented across all MCP clients used in the company.
This gave us a scalable onboarding and governance pattern: any MCP client could consume the same managed servers instead of reinventing the wheel. No matter what new MCP clients or AI tools we onboard, they will all connect to the same governed, scalable MCP servers hosted on Workato, with a consistent baseline of safeguards already in place from day one.
Cross-agent collaboration should pass work, not complexity
A task handoff should not become an architecture handoff.
The same principle applies when one Genie assigns work to another.
The value of cross-agent collaboration lies in specialisation. One Genie may understand the broader goal, while another has the appropriate knowledge, access, or business responsibility to complete a particular task.
But the receiving Genie should not have to reconstruct an entire application process from a list of unrelated operations. It should receive a bounded assignment and access a governed capability that completes the relevant work.
For example, a finance Genie may determine that an invoice falls outside established matching rules, then delegate a bounded assignment to a specialist Genie that represents the governed enterprise capability
The specialist Genie is the reusable enterprise capability. It receives a bounded assignment, retrieves the relevant records, applies established rules and judgment, and returns a meaningful result. The finance Genie does not need to understand or reconstruct the underlying invoice process.
This makes the handoff easier to test, secure, govern, and evolve. Agents can specialise while the enterprise capability remains consistent.
Reuse is a governance strategy
Every duplicate AI workflow is another policy exception waiting to happen.
Reusability is often presented as a development advantage. It is also one of the most practical forms of governance. Every unnecessary duplicate introduces another implementation to secure, test, monitor, version, and maintain, and another place where policy can drift.
When an MCP client, a Genie, a conventional recipe, and a data pipeline can all invoke the same enterprise capability, the organisation has fewer implementations of its core business logic to secure, test, monitor, and maintain.
The core business rules and capability contract can remain consistent, while execution, identity, approval, and recovery policies vary according to the authorised channel and operating context. When the process changes, the enterprise can update the shared capability instead of searching for several agent-specific versions.
Massimo warns that an opportunistic approach may work for a proof of concept, but becomes unsustainable when an organisation begins deploying dozens or hundreds of agents. The result can be overlapping tools, unmanaged orchestrations, inconsistent governance, rising operational costs, and technical debt that becomes difficult to retrofit.
A shared capability layer does not mean that every AI project must be built by a single centralised team. Teams should share a common platform, common standards, and a common understanding that enterprise capabilities are reusable assets. Each shared capability needs a named domain owner, governed access, versioning, support expectations, and a defined retirement process. Without that operating model, reuse becomes another form of unmanaged dependency.
At Workato, ownership remains with the domain closest to the business process. For example, Marketing Operations owns the governed MCP capability for creating campaigns in Marketo, including the business rules, data and policies surrounding campaign creation, which is then shared as a custom Workato MCP tool. New AI interfaces can reuse the capability without having to recreate the campaign process or transfer ownership to a central platform team.
The interface may belong to a particular team. The capability beneath it is an enterprise asset with an accountable domain owner.
The interface will change. The capability should survive.
An agent-specific workflow masquerading as an enterprise process is technical debt wearing an AI label.
Models will change.
Agent platforms will change.
Protocols will mature.
New interaction channels will appear.
Even amidst these rapid changes in the AI technology stack, the underlying enterprise capability must remain stable, governed, and reusable, regardless of what happens in the layers that interact with it.
Workato has helped my team avoid treating MCP connectivity, cross-agent collaboration, embedded LLM steps, data pipelines, and traditional orchestration as separate technology estates. The same process can begin with a person speaking to an AI interface, a Genie assigning a task, a document arriving, an application publishing an event, or a scheduled data pipeline running.
The entry point changes, but the enterprise logic does not need to. This is the architecture enterprise AI requires. Build the capability once, then allow every authorised interface to use it.
That solves the first problem: fragmentation.
It does not solve the context problem.
An agent can only make a useful decision when the surrounding system has assembled the right information and determined when AI judgment is actually needed.
That is the focus of Part 2.