The agent is not the architecture
The fastest way to make AI unscalable is to let every agent invent its own route into the enterprise.
An AI chat interface can connect to enterprise applications through the Model Context Protocol (MCP). One Genie (agent) can begin a task and hand part of it to another Genie (agent). A conventional business workflow can use AI to intelligently parse an invoice and match the information with the appropriate records in NetSuite.
The technical possibilities are expanding quickly.
But that creates a more difficult architectural question: How do we support all these interaction patterns without allowing each one to become its own integration stack, security model, process definition, and operational exception?
In “To Succeed With Agentic AI, You Need an Orchestration Strategy”, Massimo describes the challenge as agent-to-environment, agent-to-agent, and intra-environment orchestration.
In Workato, these correspond to MCP-enabled access to enterprise capabilities, collaboration between Genies, and composite recipes that coordinate deterministic work across systems.
An enterprise capability is a governed, callable unit of business execution composed of assets, policies and access, exposed through interfaces, events, and people.
MCP connectivity gives AI interfaces access to enterprise capabilities. Agent task assignment allows specialised Genies to collaborate. AI embedded in a traditional workflow adds interpretation or judgment to a process that still depends on deterministic execution.
These are three distinct orchestration domains that should share one coherent platform strategy. Workato’s advantage is not that it can support each of these patterns separately. It is that they can share the same underlying enterprise capabilities.
AI should not get its own parallel enterprise
If every new agent requires a separately engineered integration, identity, policy, and data stack, the architecture is already fragmenting.
Where practicable, the same underlying business capability should be reusable through an MCP-connected chat interface, invoked by a Genie, delegated between Genies, or triggered by a conventional business event.
It should also remain available outside AI.
A process that validates an invoice, retrieves a customer record, approves a request, or updates an application should not need to be rebuilt simply because a new agent or interface has appeared.
This is where reusability becomes much more than a development advantage.
When we reuse the same process, we can also reuse the same governed capability and its core business logic, while allowing channel-specific execution, identity and error-handling policies. Improvements can be implemented centrally and adopted across authorised consumers through governed versioning and lifecycle controls.
Without this shared foundation, enterprises risk recreating the point-to-point integration problem at a new layer. The interfaces may look more intelligent, but the underlying architecture is still spaghetti.
That is how an exciting proof of concept becomes technical debt at machine speed.
Orchestration is not background plumbing
An agent without enterprise orchestration is a demo with production access.
AI discussions often focus on what an agent can reason about or decide. Far less attention is paid to how the agent receives the context required to make that decision.
That context does not simply appear.
Orchestration may need to synchronise relevant operational information into Salesforce to provide the agent with a trusted customer context. It may need to retrieve records from multiple applications, resolve inconsistent data, apply policies, determine the current state of a transaction, and package the relevant information before the agent is invoked.
AI agents should be held to the same expectations for ownership, observability, security, supportability and operational discipline as deterministic recipes.
A proactive system uses deterministic recipes to monitor enterprise events, filtering out the routine and activating an agent only when nuanced judgment is required. After the model applies its interpretation, the process returns to reliable automation to manage notifications and approvals, ensuring humans are engaged only when judgment, accountability, policy, or genuine exception handling requires them.
Much of the work that makes an agent appear intelligent, therefore, happens before the model does anything. The resulting experience is proactive, even though the trigger and much of the execution are handled by traditional automation.
Proactivity is a capability of the complete system. It is not proof that every step needs to be controlled by a model.
Cheaper models will not fix expensive architecture
A cheaper token cannot rescue a workflow that asks the model to rediscover the process every time it runs.
The architectural choices surrounding an agent also affect its economics.
“Cheaper Tokens, Bigger Bills: Why AI Agent Costs Keep Rising” argues that agent cost is not simply a model-pricing problem. It is an execution architecture problem. When an agent must select, sequence, and interpret every granular tool call, the workflow repeatedly returns to the model, adding context, latency, cost, and more opportunities for failure.
A governed business capability creates a clearer division of responsibility.
The model can interpret intent, resolve ambiguity, and apply judgment. The deterministic workflow can handle sequencing, established business rules, approvals, retries, and recovery.
This is not about reducing the importance of AI. It is about using AI where it contributes something distinctive.
A model should not have to rediscover the same invoice validation process on every run. It should not have to reason through routine system coordination simply because the operations were exposed as separate tools.
The most expensive model call may be the one the architecture never needed to make.
The metric that really matters is the cost of producing a reliable, compliant and auditable business outcome.
Governance cannot be added after the agents arrive
If an agent can take action but no one can prove who authorised it, the system is not autonomous. It is unaccountable.
As agents gain access to enterprise tools, the architecture must answer three questions:
- Who is the agent acting as?
- What is it allowed to do?
- What did it do?
Identity cannot disappear simply because an action begins in a conversational interface. Authorisation must determine which capabilities an authenticated user, agent, or workload may access and under whose authority the resulting action is executed.
These are the questions the Workato MCP control plane is designed to address. It governs identity, authorisation, policy enforcement, tool access, execution context, and observability across the full path from the AI client through the recipe to the backend application.
With Verified User Access, Workato effectively separates process logic from its execution environment. This ensures that when a Genie acts, the actions execute under the user’s individual permissions while preserving the complete mediated chain through the Genie, MCP tool, recipe, and backend application.
Execution records must then show which tool was called, which inputs were provided, what happened in the workflow, and what result was produced in the backend system, while applying appropriate masking, redaction, and retention controls.
Standardising on a shared foundation must strengthen security through consistent identity, authorisation, policy enforcement, and observability rather than weakening those controls for convenience. The more capable agents become, the less acceptable it is for their actions to be anonymous or opaque, as the blast radius widens and the risk increases.
What this series will examine
The future of enterprise AI will be shaped by architecture decisions that look unremarkable until they fail.
Over the next three articles, I will explore the questions enterprises must answer before agentic AI can move from promising experiments to dependable business infrastructure.
Part 1: Your AI Agents Are Not the Problem. Your Architecture Is.
The first article examines why MCP interfaces, agent collaboration, embedded AI, traditional automation, and data pipelines should access a common set of reusable enterprise capabilities rather than create separate technology silos.
Part 2: Your AI Agent Is Only as Smart as the Workflow Behind It.
The second article explores how orchestration creates context, enables proactive execution, and reduces unnecessary model reasoning and cost.
Part 3: An Agent Without Identity Is a Security Problem.
The final article focuses on the control plane required to answer who an agent represents, what it can access, and how its actions can be traced from the original request to the backend system.
Workato has allowed my team to compose agentic experiences from the same governed automation assets they already use to run the business. This is liberating, but it also raises the standard for enterprise architecture.
The important question is no longer whether an agent can connect to an application or complete a task. It is whether that capability can be reused across interfaces, operate with the right context, execute under the right identity, remain economically sustainable, and leave a complete record of what occurred.
Everything may be technically possible.
That does not make every agent action permissible.