Every post in this series so far has told an OMG story. BPMN models the process, CMMN models the case, and DMN models the decision. All three come from one standards body, the Object Management Group. The series has argued that reusing them beats inventing something bespoke for AI agents. A reader could fairly take that argument as an OMG preference, because it had not been tested against a standards body Kirto Flow had no prior reason to favour.
Now it has. connectors/openapi and connectors/arazzo execute a different standard: Arazzo, published by the OpenAPI Initiative. That is the body behind the OpenAPI Specification most of the API world already writes against. Arazzo has been its companion spec since version 1.0 in 2024: OpenAPI describes single operations, and Arazzo declares multi-step sequences of API calls. Flow executes it the same way it executes BPMN and CMMN. Nobody on the team treated that as a second architecture to design. It fell out of the first one.
The verb is execute
The constant across the last three posts is easy to find. Flow executes the standard that already exists instead of inventing a format for the same job. A sub-agent dispatch reuses the tool-call path instead of a bespoke hand-off protocol. A tool grant is a CMMN planning-table evaluation instead of a new permissions list. A decision is a DMN table instead of a rules DSL. The OMG was the standards body behind every one of those because the OMG is the standards body for process, case and decision modelling. The discipline is the verb, execute. The body that wrote the spec is incidental.
Two domains, one boundary
Every one of those OMG standards governs something a case or process does to itself: the shape of its lifecycle, the plan items it can activate, the table it evaluates to reach a decision. None of them governs what happens when the case reaches past its own boundary to call a different system, such as a payments API, a CRM or a partner’s fulfilment service. That crossing is ordinary. In practice a BPMN service task or a CMMN task usually is one, once it stops being an internal state transition and becomes an HTTP request to somebody else’s server.
Most process engines handle the inside rigorously and hand-wave the outside. They offer a generic “REST call” task. Authentication, parameter placement and any multi-step sequence (authenticate, then create, then poll, then fetch) live in bespoke integration code inside whoever implemented that task. The model reasoning about the case cannot see that code, and whoever audits the case later cannot read it. Flow answers that boundary the way it answered the one inside the case. A standard for it already exists, written by the people who own API description and composition, and Flow uses it.
The document is the connector
openapi:call executes any operation a deployed OpenAPI document declares, addressed by the document and the operation’s id. Parameter placement (path, query, header, cookie) comes from the document’s own parameter definitions, with no hand-authored mapping. The modeler generates one authoring form per operation from the same schema. Pointing Flow at a new API needs no new connector. The document a decent API already ships is a complete enough description to be one.
The sequence lives in the document
A single call is the easy case. The harder one is a sequence: authenticate, create a resource, poll until it is ready, fetch the result. That pattern sits behind almost every real integration. Every team that touches an API hand-codes it again, because there was no shared way to declare it. Arazzo is that shared way. Runtime expressions carry values from one step’s response into the next step’s request, and success criteria decide what happens next. The whole sequence is one document instead of one team’s bespoke retry loop.
Flow’s executor wraps a third-party implementation of the spec, pb33f/libopenapi, around one substitution point, RunStep. A durable host journals each call the engine makes through it and owns no Arazzo-specific logic itself. Retries follow the same discipline. The engine never retries on its own. A retry is a document-authored onFailure action, the way a BPMN boundary event declares what happens on failure. The spec already had an answer, so Flow’s engine invented no retry knob. Transport failures are the one exception: the durable layer’s step retry policy owns those. Every HTTP response, whatever its status, goes back to the document’s criteria.
flowchart LR OMG["OMG<br/>BPMN, CMMN, DMN"] OAI["OpenAPI Initiative<br/>OpenAPI, Arazzo"] DISC["Execute the spec<br/>invent nothing"] ENGINE["One durable engine"] OMG -->|governs the case| DISC OAI -->|governs the boundary| DISC DISC --> ENGINE
Why two standards bodies is the point
The OMG and the OpenAPI Initiative have no relationship to each other. Nobody coordinated BPMN and Arazzo to fit together. Executing a DMN table implies nothing about how to execute an API workflow spec. Flow applies the same discipline to both: execute the real spec, wrap the one seam that has to be durable, invent no vocabulary of its own. Applying it to a body Flow had no prior reason to favour turns the discipline into a claim about the architecture. The engine/driver split was never OMG-shaped. It is reducer-shaped, and the three OMG standards were the first reducers it ran.
The parallel has limits. Arazzo is young: version 1.0 came out in 2024. It lacks BPMN’s and DMN’s decade of adoption and their TCK-grade conformance testing. The “checkable by an external body” argument lands hardest for DMN, and it lands less hard here for now, because Arazzo has not had the years of scrutiny DMN has. The structural discipline carries over in full, and the maturity does not: a real spec in, one durable seam around it, nothing bespoke in between.
Flow
BPMN, CMMN and DMN come from the Object Management Group. Arazzo comes from the OpenAPI Initiative. The two bodies have never coordinated, and Flow treats both the same way. That is one discipline, applied wherever a real standard already exists, and the list is longer than the three this series started with.
Later posts cover the second half of that list. One covers what openapi:call gives over per-vendor SDK wrappers and agent-only tool-calling toolkits. Another looks at what it means for retry semantics to live in the document instead of the engine. For the discipline applied to process and case, see Orchestration and choreography in one model.