What does it take to build an agent platform in an evolving market?

When Workato entered the agent market in 2024, most AI products treated an agent as something to talk with.

Workato had a different advantage. The platform was already connected to the systems where business work happened. Its workflows could execute actions reliably, follow defined rules, expose errors, and maintain an audit trail.

That gave us a compelling product model:

Every agent was composed of three parts:

A skill was not merely a single API call. It could be an existing Workato workflow that coordinated several systems in a reliable sequence.

For example, an order-management agent could investigate a delayed order by checking the CRM, looking up warehouse inventory, contacting the shipping provider, and notifying the account team. The agent decided when the skill was appropriate. The workflow controlled how the work was performed.

This distinction mattered. We were not adding AI as another node inside a workflow. We were giving an agent access to dependable capabilities it could choose among.

The initial commercial strategy was to position the agent product independently from Workato's existing orchestration platform.

There was a reasonable argument for this. A separate product would be easier to explain, easier to package, and less burdened by the complexity of the larger platform.

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, and governance. These were not optional dependencies. They were the source of the agent's power.

We could separate the navigation. We could not separate the work.

Some tasks would also require people to leave the agent product, enter the automation platform, create or update an asset, and then return. The product boundary simplified the sales story while making the user experience harder to understand.

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

At our March sales kickoff, we presented the case to the executive team. We showed where the proposed boundary broke important workflows, where platform constraints forced context switching, and why a standalone agent product would lose the capabilities that differentiated Workato.

The proposal to keep the products separate was reversed.

This was a major win for the experience, but it created a difficult delivery problem. We had spent months designing and engineering toward the split. We now needed to bring the product back together before our user conference in August.

The teams moved quickly. By June, the capabilities had been brought back into the main platform.

The release worked, but it did not yet feel like one product.

Every capability lived in a different place. Knowledge, skills, testing, configuration, and governance were available, but the interface did not explain how they worked together. The effort required to split and reunify the platform was visible in the experience.

With two months remaining before the user conference, I advocated for another experience pass.

Engineering teams had already reworked the product under significant time pressure, so another change was understandably difficult to support. I partnered with our CPO to establish a cohesive experience as a product requirement, while the design team worked directly with engineering to reduce the cost of getting there.

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

After launch, we studied how people actually built agents.

One builder study with a major observability company produced the clearest signal. Participants described Workato as the most complicated agent platform they had evaluated.

Their proof of concept took three weeks against a market expectation of roughly one. Nontechnical stakeholders could not participate without help. Even experienced builders struggled with terminology such as “genies,” “agents,” “skills,” and “tools.”

The finding was uncomfortable, but it was also useful. We had optimized for bringing powerful capabilities together. We had not yet made that power understandable.

The study reframed our next phase of work.

The main problem was not the absence of capability. It was the number of concepts, destinations, and interruptions a person had to manage while building an agent.

Creating a skill was a good example. A person working in the agent builder had to leave, 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 open the skill editor from inside Agent Studio, create or modify the workflow, close it, and return to the agent without losing their place.

The same principle applies to knowledge and other supporting assets. The underlying platform remains powerful, but people no longer need to understand its entire information architecture before completing a task.

We also shipped or expanded the enterprise capabilities agents needed to become dependable products, including:

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

Over time, customer behavior exposed the limits of that model.

Some customers wrote prompts tens of thousands of characters long, trying to force an agent to follow a precise sequence. They wanted the flexibility of AI in some parts of the process and explicit control in others.

At the same time, the broader market began calling almost every AI-enabled workflow an agent. Our purist definition was intellectually consistent, but it made emerging patterns such as agent orchestration and collaboration harder to represent.

In 2026, we began redesigning the agent builder around a flow model. This allows deterministic steps, agent decisions, human review, and collaboration between agents to exist in one understandable structure.

The product model is still evolving because the capability is still evolving.

As agents become more capable, their interface cannot stop at the builder.

We are also 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: