OpenAPI, Arazzo and Overlays for agents

Why this conversation

Most teams that run APIs already describe them with OpenAPI. The question now is what happens when the caller is an agent rather than a developer reading the documentation. Agents can call APIs, but they do not always call them in the same order or in the same way, and a business that depends on a process needs to know which steps will run. The host met Erik Wilde, OAI Ambassador at the OpenAPI Initiative, on the morning of 14 October at the Nordic APIs Platform Summit in Stockholm, the day after Erik’s own talk there. The story of the week is in Nordic APIs 2026: your next customer is an agent.

It is a short conversation, about five minutes, and it covers three things: the new specifications, why written workflows matter for agents, and how to take part in the work.

More than one specification

OpenAPI has been around for about twelve years, and the conversation opened on how widely it is used. For most of that time the OpenAPI Initiative had one specification, OpenAPI itself. It now has two more: Arazzo, a workflow standard, and the Overlay standard. The idea, Erik says, is to give the community more tools to build on, so that products can implement them and work together.

He draws a line between two words that often get mixed up. Interoperability is about choice: if you use OpenAPI, there are literally thousands of products that support it in some way, and you pick the one you want. Composability is different. If you have several APIs described with OpenAPI, Arazzo lets you compose them into a workflow. His example is booking a ticket: the workflow says that to book a ticket you do this step, then this one, then the next. That matters for agents in particular, because agents sometimes have a hard time stitching things together.

Deterministic where it counts

The host raised accountability, a big topic in Europe. Erik’s answer is practical. If a business tells an agent to carry out a task, the agent might do it, but it might also do it differently from one time to the next. It is not deterministic. With Arazzo the workflow is defined: it can be reviewed, changed, versioned and checked by someone else. A team then knows that the task will be done in the steps it prescribed.

That was also the main message of his talk the day before: “use as little AI as possible”. AI is good, he says, but it also has its downsides. Some things should be deterministic, and should be handled that way, rather than throwing every problem at an agent “and just hope for the best”.

Getting involved and keeping up

The starting point is openapis.org, the OpenAPI Initiative’s site (the plural was the only domain available). openapi.tools lists the software components that implement OpenAPI. Those who want to join the technical work will find it mostly on Slack, in active channels for each specification and for other work in the API space.

New versions are always being developed. The last one, OpenAPI 3.2, came out about a year ago, and more will follow. Erik encourages people to join, because standards improve with feedback and with more people doing the work. He is candid about upgrades: in a large company with many tools around, some of those tools may not support the latest version yet, so moving up is hard, as versioning always is. In the long run, he says, it still makes sense to keep asking how to get from where you are to a better place.