Should Workflows Have Their Own APIs?

TL;DR Workflows could be treated as APIs in their own right. In this episode of “Getting APIs to Work,” Frank Kilcommins explains how giving workflows an API interface would make them discoverable, governable, and reusable, just like standard APIs. It shifts orchestration from design-time code to run-time execution, where agents can call complete workflows such as “create account” or “process order.” The idea builds on the Arazzo specification and could extend existing API governance and security models to automation workflows.

The Question: "Should Workflows Have Their Own APIs?"

APIs define how digital systems talk to each other. But the real value often comes from how multiple APIs work together through the workflows that connect them. In this new episode of “Getting APIs to Work,” I talk with Frank Kilcommins, Head of Enterprise Architecture at Jentic and co-editor of the OpenAPI Initiative’s Arazzo specification, about an idea that sounds simple but could change how we think about automation:

If workflows orchestrate APIs, why not give workflows their own APIs?

It’s not just a semantic twist. Giving workflows an API interface would let them participate in the same ecosystem of gateways, catalogs, and policies that already makes APIs so powerful. It would make workflows discoverable, governable, and reusable at scale.

From Design-Time to Run-Time

Developers use APIs at design time, and they write code against fixed interfaces. Agents and automation systems, by contrast, operate at run time: they discover, select, and invoke APIs dynamically to achieve goals.

By exposing a workflow as an API, we make that orchestration available at the same run-time layer. Instead of pre-coded logic, an agent could call a workflow like “create account” or “process order,” with Arazzo handling the sequence underneath. That makes workflows first-class citizens in the automation landscape.

Using the API Ecosystem

As Frank points out, treating workflows as APIs means we can reuse everything the API world already does well: security, rate limiting, observability, versioning, and governance. Workflows could appear in API catalogs, be controlled through existing gateways, and be managed under familiar policies.

It also surfaces interesting parallels with the Model Context Protocol (MCP) conversations, where enterprises are grappling with similar questions around authorization, delegation, and runtime control. Many of those ideas could carry over directly to workflow APIs.

What’s Next

The goal right now isn’t to define a final solution but to explore what it would take to make this real from both a technical and organizational perspective. If you want to dig deeper into this idea, hear how it connects to Arazzo and OpenAPI, and what kinds of opportunities it opens up for API-driven automation, watch the full discussion here.