Orchestration as a Service

TL;DR

• Orchestration as a Service is the platform layer that sits above AI agents and makes them work together.
• The category exists because every company is about to run many agents from different vendors with no shared governance.
• It covers three jobs: coordinating agents, governing their behavior, and ensuring they stop and ask a human for help at the decisions that should not be automated.
• Six published requirements, the OaaS Criteria, test whether a platform belongs in the category. FlowRunner meets four and says which two it does not.
• FlowRunner is the first platform purpose-built for this category. Agent builders compete below it; we coordinate them.

What it means

Software vendors are racing to ship AI agents. Salesforce has them. Microsoft has them. OpenAI ships new ones every quarter. Niche startups ship agents for narrow jobs. Inside a year or two, the typical mid-market company will have agents from five to ten different vendors operating across its sales, finance, ops, and support workflows.

Nobody has thought through what happens next. Two agents try to update the same record. A human asks one agent for an answer that depends on data another agent owns. A compliance auditor asks who decided what and when, and the answer is scattered across vendor logs in five different formats.

That is the coordination problem Orchestration as a Service solves. The category has three responsibilities:

• Coordinate. Route work to the right agent. Resolve conflicts when two agents try to act on the same data. Hand off context cleanly between agents so the next one can pick up where the last one left off.
• Govern. Define rules the agents follow when they talk to each other. Produce the audit trails compliance and security teams need. Enforce limits on what each agent is allowed to do.
• Supervise. Pause when an agent hits a decision that should not be automated. Route that decision to a human through the channel they use. Resume cleanly once the human has answered.

The third responsibility is the one most easy to skip and the most expensive to skip. Agents that plow ahead through uncertainty produce confident wrong answers. Agents that know when to stop and ask a human for help produce trust.

What it is not

OaaS is not just an agent builder. Pure agent-building tools like LangChain, CrewAI, and OpenAI’s agent SDK focus on producing capable individual agents and stop there. OaaS includes agent building (FlowRunner does this through the Agent Factory) but adds the layers that make many agents work together: coordination, governance, and supervision. The Agent Factory is the entry point; the orchestration that surrounds it is the destination.

OaaS is not workflow automation. Tools like Zapier and Make connect SaaS apps by trigger and action. They do not coordinate AI agents that operate over time, ask questions, and need supervision.

OaaS is not iPaaS. Enterprise integration platforms like MuleSoft and Boomi move data between systems. They are not designed around agents as first-class actors that make decisions and need governance.

OaaS is not RPA. Robotic process automation drives keystrokes through legacy UIs. AI agents work at the data and intent layer, not the screen.

The way to think about it: agent builders ship the workers. OaaS is the floor where the workers coordinate, the supervisor that watches them, and the auditor that records what happened.

The OaaS Criteria

A definition is an assertion. A category needs a test that anyone can apply, including to the vendor who wrote it. These six requirements are that test. Each one starts with a situation operators recognize, because a requirement has to fall out of a problem people already have, not out of a feature list.

One grading rule applies to all six. A capability every flow author must rebuild is not a platform capability. If meeting a requirement means the person building the workflow implements it themselves each time, the platform scores partial, not meets. Provision counts. Possibility does not. We apply the rule to ourselves first, and it costs us two points below.

1. Agent-invoked human escalation

The situation: the agent is 80% confident. Who decides whether 80% is enough, and who does it ask?

The requirement: the platform can pause a running agent at a point the agent chooses at runtime, route the decision to a named person through the channel that person already uses, keep the full context across the pause, and resume with the answer as a value the agent reasons over. An approval node a workflow always passes through does not meet this. The agent has to be able to decide to ask.

How to check: does the vendor document a human step an agent can call as a tool, with a return value? Or only an approval step placed on the canvas at design time?

2. Durable suspension

The situation: the approval came back Thursday. The run timed out Monday.

The requirement: a run can stay suspended for as long as the business process takes, measured in days or months, not in the platform’s timeout window.

How to check: the published maximum wait per run. Anything measured in minutes fails. Anything measured in hours is partial.

3. Governed coordination over the mediated surface

The situation: two agents, one from the CRM vendor and one the company built in-house, wrote different values to the same record an hour apart.

The requirement: for the actions the platform mediates, ordering, conflict detection, and escalation are provided by the platform rather than reimplemented per agent. And the platform states plainly which actions it does not mediate.

That last clause is the sharpest test in the set. No platform can arbitrate an action it never sees. An agent holding its own credential and writing straight to the system of record is invisible to every orchestration layer. That is a boundary of the category, not a roadmap item, and a vendor claiming universal arbitration fails this criterion for overclaiming. The practical consequence is that the value of one mediated surface rises with every agent vendor a company adds, which is the structural reason the category exists.

How to check: does the vendor document what it mediates, what it does not, and what happens when two mediated actions conflict?

4. Auditability as a platform property

The situation: the auditor asked why the agent denied that claim in March.

The requirement: every agent decision, every human intervention, and every escalation is recorded in a retained, exportable trail, and that trail is included on a self-serve plan with a published price, not reserved for the custom-priced top tier. The question is not whether an audit log exists. It is at what price governance starts.

How to check: the pricing page. Which tier unlocks audit retention and export.

5. Agent-callable composition

The situation: the agent needs to call the company’s existing approval process, not rebuild it inside the agent. And the person who understands the process cannot code, while the person who can code does not understand the process.

The requirement: existing workflows, actions, and knowledge bases are exposed to agents as callable tools with their own inputs and return values. Composition runs in both directions: agents as steps inside workflows, and workflows as tools inside agents.

How to check: does the vendor document an existing workflow being invoked by an agent as a tool, with the agent receiving the result? Or does composition run only one way, agents placed as nodes inside a workflow?

6. Interrogable escalation

The situation: the agent asked an approver to sign off on something. The approver had a question. There was nobody to ask.

The requirement: when an agent escalates a decision, the person receiving it can question the automation about that decision. What did you see. Why this one and not the other forty. Has this vendor done this before. The automation answers from its own execution context, and the person decides better as a result. A static approval payload, however well formatted, is an approval gate. An approver with a question and nobody to ask either digs through three other systems or rubber-stamps, and rubber-stamping is what turns human oversight into theater.

How to check: does the vendor document a person replying to an escalation with a question and receiving an answer drawn from the run, before deciding?

How FlowRunner scores

Four of six, held to the same rule as everyone else.

Criterion	FlowRunner	Basis
1. Agent-invoked escalation	Meets	Human-in-the-loop flows are callable tools an agent invokes at runtime, over email, Slack, WhatsApp, or phone, with context preserved and the answer returned to the agent.
2. Durable suspension	Meets	A run can wait up to 30 days on Free, Starter, and Growth, and up to a year on Professional and above, using no runtime while parked.
3. Governed coordination	Partial	FlowRunner mediates every write that passes through its connectors and its MCP tools. Ordering and conflict handling across those writes is built per flow by the flow author today, not provided by the platform. Agents holding their own credentials to a target system are outside the mediated surface.
4. Auditability	Meets	Audit trails and role-based access from the Professional plan at $299 a month. SLA tracking and compliance reporting from Business.
5. Agent-callable composition	Meets	Flows, actions, and knowledge bases are exposed to agents as tools, and a complete workflow can be called by an agent or by another workflow.
6. Interrogable escalation	Partial	Achievable today as a per-flow implementation the flow author builds and maintains. A platform-provided version is on the roadmap.

The two partials are the point. Criterion 3 is the hardest requirement in the set and the reason the category exists. Providing it at the platform level, rather than leaving it to each author, is the work in front of us. Criterion 6 names the actual failure mode of human oversight in production, and it is the requirement we most want to be measured against once it ships.

What the criteria do not measure

Connector breadth, template ecosystems, community size, and how permissive the code runtime is. Those matter to buyers, other platforms win some of them, and the comparison pages say where. They are left out here because they measure a platform’s reach, not whether it can coordinate, govern, and supervise agents. A scorecard grading the field against all six, with sources, is the next page in this series.

How FlowRunner implements it

FlowRunner is the first OaaS platform. The product is organized around three pillars that map directly to the three responsibilities of the category.

• The Agent Factory is FlowRunner’s visual and conversational interface for assembling AI agents from connectors, MCP services, other agents, and existing flows. It is how new agents enter the orchestration environment without an engineering team.
• The Agent Directory is a curated library of pre-built agents that are ready to deploy and reuse.
• The Code of Conduct is the platform-enforced governance layer that defines how agents communicate, escalate, and leave audit trails.

Human-in-the-loop is the supervision pattern that runs through all three. Agents do not just produce outputs and hope. They pause autonomously when they hit uncertainty, assemble the context and decision choices, route to a human through the right channel, and resume the moment the human responds.

Flow conversation is the complementary pattern for ongoing dialogue with a running workflow: an operator asks a flow about its state, gives it new instructions, or steers it with fresh context without pausing it. Today a flow author builds that dialogue inside the flow. It is a pattern the platform supports, not a capability it provides on its own, which is why criterion 6 above scores partial.

The result is a platform a COO can buy with confidence today (it eliminates the manual processing eating their team’s time) and that becomes more valuable every quarter (as the company adds more agents that need coordination).

Where the term comes from

Orchestration as a Service is the category FlowRunner is naming. Other vendors describe what they do as workflow automation, AI agent platforms, or intelligent automation. None of those names captures the coordination, governance, and supervision job that becomes critical when a company runs many agents.

The naming choice is deliberate. Orchestration is the right verb because the job is to make many actors play in time, not to produce any single output. As a Service signals that it is a platform commitment, not a feature. The platform takes responsibility for the orchestration; the customer does not have to build it.

A category name is a bet that the industry will need a word for this job before too long. FlowRunner is the bet.