At last year’s World of Workato (WOW) event, Workato was largely focused on assembling the pieces needed to build and run agentic systems at enterprise scale — extending its orchestration platform with agents, Model Context Protocol (MCP) infrastructure and new governance capabilities.

This year, the company is consolidating and simplifying that foundation to create what it calls the "New Workato” — a neutral enterprise control and execution plane fronted by the company’s multi-agent interface, AIRO (an acronym of AI-driven, Intent-based, Real-time Orchestrator).

During this year’s opening keynote, Chief of AI Products & Solutions Bhaskar Roy framed the announcement as a shift in focus — one intended to address the “intent-to-outcome gap” between rapidly increasing investment in AI and the somewhat less rapidly increasing business results.

And he positioned this shift as a way of accelerating delivery by enabling users to get the outcomes they need simply by explaining their intent to the platform — while allowing them to step away from the complexity of implementation and operation.

The main announcements in support of this new positioning fall into four broad areas — agentic experience; better context on how the business actually operates; new ways of sharing and tracking AI assets; and an expansion of Workato’s AI governance capabilities beyond assets built on its own platform.

The headline announcement at the event was AIRO, a multi-agent interface which Roy described as “the new face” of Workato — and a common interface for business, IT, operations and line-of-business users.

It is intended to become the primary interface across the entire solution lifecycle — from understanding a requirement and designing a solution through to building, testing, monitoring and improving it once it is running. In this new model, the company claims that users are no longer expected to decide whether they need to build a recipe, workflow, agent or skill — and then use different tools to assemble and deploy the resulting solution — but to simply describe what they are trying to achieve and allow AIRO to determine how that intent should be implemented on their behalf.

Underneath that interface, AIRO is built from a set of interlocking components — Foundry for specialist agents; Memory for understanding what already exists; Playbooks to capture important architectural conventions; Acumen for oversight and recommendations; and Connect for external access to AIRO.

Workato says several thousand people have already used AIRO during its phased rollout, and claims customers have seen up to a 74% reduction in time to go live.

What I found particularly interesting is that a lot of platforms have announced an agent as an additional development tool — which makes Workato’s announcement seem relatively workaday on the surface. But what’s notable is that Workato appears to have gone further than anyone else I have seen in asserting that this is now the primary interface to its platform.

One of the big recurring issues raised by Chief Product Officer Bhagat Nainani during the keynote was the difficulty of enabling agents to understand the shape and performance of the business in which we want them to operate. His assertion was that giving agents this kind of business-specific context is becoming increasingly critical to the delivery of useful business outcomes.

Workato divides that additional context into three types. The first is what the business knows — policies, documentation, customer history and other enterprise knowledge. The second is how the business was designed to run — the recipes, APIs, processes, agents and other assets that make up its structure. And the third is how the business actually runs — including paths taken at runtime, decisions made, errors encountered and events processed.

To address this, Workato announced Enterprise Process Context and Live Process Graph, new additions that build on the company’s existing Knowledge Graph to enable agents to not only access organizational knowledge assets, but also to understand the structure of business processes and how they actually execute. In this way, Nainani claimed that Workato was offering a new semantic layer to turn process understanding into something AI can reason over.

What’s interesting is that this kind of context visibility feels like a fairly natural fit with Workato’s existing strengths as an orchestration platform that both spans applications and already gathers metrics on the processes that link them. Nainani contrasted this with application vendors that can only see the part of a process running inside their own systems, arguing that Workato’s position between applications gives it visibility across those boundaries — something that seems like useful context for agents trying to understand and improve business outcomes.

As organizations move beyond isolated AI projects, Workato also sees a growing problem simply keeping track of what has been deployed.

Nainani cited one design partner whose estimate of 40 AI assets — across models, agents and MCP servers — turned out to be wrong by more than a factor of two. Workato’s argument is that visibility therefore becomes a prerequisite for governance: you cannot control assets you do not know exist.

Workato’s new AI Registry is designed to overcome that problem by providing a central place to catalogue and discover approved assets from across the enterprise — including those built or running outside Workato.

Administrators can see which assets exist, decide which are approved for listing, control access and review usage. Users in turn can search for approved assets and request access rather than adding another model, agent or MCP server — taking advantage of what already exists in order to avoid uncontrolled sprawl.

The company also announced XChange, an internal marketplace intended to address the packaging and distribution of Workato assets across distributed teams and encourage reuse.

Assets created in one workspace — including agents, MCP servers, APIs, connectors, data tables and workflows — can be packaged as versioned releases, reviewed by a curator and then made available to other Workato workspaces. Workato also tracks what has been deployed, where, and on which version.

The more interesting point is the combination of the two. If Workato succeeds in making AI development accessible to a much wider group of users, then decentralization creates its own co-ordination problem. More people can build more things, but without visibility and distribution mechanisms the likely result is duplication, inconsistent versions and a steadily expanding collection of assets nobody quite owns.

One of the more consequential positioning themes throughout the keynote was the idea of Workato as a neutral layer that acts as a control plane across the typical enterprise’s heterogeneous network of components — whether applications, integrations and MCP servers, agents, or AI models.

Nainani said that after the vendor introduced Enterprise MCP last year the most common feedback from customers was that this needed to work beyond Workato’s own MCP infrastructure — because MCP servers might also be supplied by SaaS vendors, run on-premise or built in-house. That same logic now extends beyond MCP, with Workato applying the gateway model across third-party MCP servers, agents and AI models while retaining common authorization policies, fine-grained permissions, rate limits, guardrails and audit controls.

Of particular interest in the current climate is the Model Gateway — Workato’s governed endpoint that sits in front of models from OpenAI, Anthropic and Google, as well as open-weight or internally deployed alternatives. While the basic premise is that the underlying model can change without requiring changes to the application, it also has additional capabilities in routing and policy application.

And this is what I found most interesting, because as an intelligent router, the Model Gateway can be used to apply routing rules based on the nature of the call received and the parameters of the business outcome in question. It can select models according to factors such as cost, latency, availability, geography, data sensitivity and task complexity — and also apply budgets, quotas, usage caps or rate limits, as well as provide visibility into where tokens are being consumed.

This seems like an important layer of additional policy control when Workato is talking about turning ‘intent into outcome’, since an outcome is not simply the completion of a task, but the completion of a task within a specific set of parameters. And so it feels that if Workato wants users to specify an outcome rather than an implementation, then the platform also needs to understand the constraints under which that outcome should be achieved — and have the tools available to manage those policies at runtime.

The most consequential announcement at WOW this year was probably one of direction rather than product development. Workato’s shift towards the idea of intent-to-outcome is a bold one — particularly when combined with wrapping the platform in an agent intended to fill the gap between the two.

I’ve believed in this general idea of opinionated architectures and simplified development for a long time — and so the combination of platforms and agents feels directionally inevitable if still nascent. Workato’s implementation is clearly at an early stage too, but it also feels like something the company is treating as a new principle — that users will increasingly describe what they want and leave the platform to take more responsibility for deciding how to achieve it.

It will be fascinating to follow how that proposition matures in the hands of customers — not just technically, but narratively.