Shaping an integrated AI platform strategy

In 2024, Workato planned to enter the agentic market with a standalone SKU, separate from its orchestration platform.

The logic was reasonable. A separate product would be easier to explain, package, and sell. It would also be easier for Customer Success and the wider business to learn, support, and bring to market.

Most AI products treated an agent as something to talk with. Workato was already connected to the systems where business work happened.

That gave us a different position in the market. An agent could decide what needed to happen, while Workato workflows executed the decision reliably across applications. Existing platform controls kept every action visible, governed, and auditable.

That gave us a compelling product model:

Each agent had a job description, knowledge it could draw on, and skills it could invoke. A skill could be an existing Workato workflow coordinating several systems in a reliable sequence.

An order-management agent, for example, could investigate a delayed order by checking the CRM, reviewing warehouse inventory, contacting the shipping provider, and notifying the account team. The agent decided when to invoke the skill. The workflow controlled how the work was performed.

Beginning in August 2024, the design team explored how to divide the experience.

The deeper we went, the less convincing the split became. Building a capable agent required access to workflows, connections, data tables, reusable schemas, APIs, environments, security, and governance. None of these were optional dependencies. They were the source of every agent's power.

Basic tasks would require people to leave the agent product, enter the orchestration platform, create or update an asset, and then return. Creating product boundaries would simplify the sales story while making the experience harder to understand.

By early 2025, the design team had enough evidence to show that the split was producing a weaker product.

At our March sales kickoff, design partnered with product and engineering leaders to present a shared case to the executive team. We used the broken journeys, platform dependencies, and context switches we'd uncovered to show why a standalone product would lose the capabilities that differentiated Workato.

The proposal to keep the products separate was reversed. Planning for the reversal began while the standalone public beta continued toward release. In April, the merge became a formal initiative, and we worked through where Genies, Skills, and knowledge bases should live in the reunited product.

Reversing the split was a major win for the experience, but it created a difficult delivery problem. We'd spent months designing and engineering toward separation. Now we had to bring the product back together for the June general release, a date that couldn't move.

By June, the teams had brought the agent capabilities back into the main platform. The release worked, but it didn't yet feel like one product.

Knowledge, skills, testing, configuration, and governance lived in different tabs. The necessary capabilities were present, but the interface didn't explain how they worked together. The effort required to split and reunify the platform was still visible in the experience.

With two months left before the user conference, I advocated for a cohesive experience pass.

I first tried to build support from the bottom up with the engineering team responsible for the release. The proposal met heavy resistance. The team had already reworked the product under intense time pressure, and another substantial change felt unrealistic.

When that approach stalled, I changed tactics. I escalated the decision to our CPO, who is accountable for design, product and engineering. I made the case that cohesion had to be a release requirement. Once we had that alignment, the design team partnered directly with engineering to reduce the scope and cost of the changes.

By August, we had an Agent Studio experience that brought the essential pieces into a shared model.

After launch, research became an ongoing part of how we developed Agent Studio. We studied first-time builders, mature teams, competitive products, and customers running agents in production.

An early study with a major observability company gave us a clear initial signal. Participants described Workato as the most complicated agent platform they had evaluated. Their proof of concept took three weeks when they expected roughly one. Nontechnical partners couldn't participate without help, and even experienced builders struggled with terms such as "Genies," "agents," "skills," and "tools."

The finding was uncomfortable but useful. We had brought powerful capabilities together without making that power understandable.

We treated the study as a starting point. Over the next year, our research team followed builders through interviews with advanced users, follow-ups with mature and dissatisfied customers, a competitive study, and rolling research on Genies. We compared those findings with usage data, sales calls, product planning, and internal reports.

Four problems appeared repeatedly:

These findings were also evidence that customers were progressing. They were moving beyond early experiments, building more sophisticated agents, and putting them into production. As their practices matured, their requirements evolved. Our product now needed to evolve with them.

Research shaped the roadmap at two levels.

First, it showed us where the existing build-experience created unnecessary work. The platform had the right capabilities, but it still asked people to manage too many concepts, destinations, and interruptions.

For example, creating a skill makes the problem clear. A builder has to leave Agent Studio, navigate to the recipe editor, create the workflow, and then return to the original agent.

We began an in-context editing initiative to remove that interruption. A builder can now open the skill editor inside Agent Studio, create or modify a workflow, and return to the agent without losing their place. We applied the same principle to knowledge and other supporting assets. This helps the platform keep its power, but people no longer need to understand its entire information architecture before completing one task.

Second, research showed us what customers needed as their agents became more important to the business. We shipped or expanded:

Our original model treats an agent as an independent decision-maker with deterministic workflows available as skills.

As N8N has grown in popularity, it has established a different model in customers' minds: an agent as part of a visible flow that combines AI decisions with deterministic steps. However, it recently introduced an agent as a separate entity. Even though N8N popularized one definition, it is now making room for another.

Our research reflects the same ambiguity. Some customers write prompts tens of thousands of characters long to force an agent through a precise sequence. Others build chains of agents without clear product guidance. They want the flexibility of AI in some parts of a process and explicit control in others.

Our definition is intellectually consistent, but it leaves little room for these emerging patterns. In 2026, we are redesigning the builder around a flow model that can hold deterministic steps, agent decisions, human review, and collaboration between agents in one understandable structure.

As agents become more capable, their interface can't stop at the builder.

We're exploring how organizations can:

I set the product and design direction across this work, represented the experience in executive decisions, and coordinated design across teams responsible for AI, Platform, Security, and the core interface.

Designers and researchers owned the detailed flows, prototypes, and studies. My role was to give the team a clear model to work from, critique the consequential decisions, maintain the quality bar across product boundaries, and remove organizational obstacles when the experience required a change in direction.

The most important decisions I led were:

Customers are building repeatedly, and usage is growing faster than creation.