AI Workflow Orchestration: Script or Agent?

Most AI workflow orchestration guides list the parts: models, agents, tools, data sources and review steps, connected into one process. That list is correct, but it skips the design decision that decides whether the workflow can be trusted.

The decision is who chooses the next step. Either a model plans and dispatches the work, or code does, and the models only run the steps they are given.

I have built both kinds. This article explains the split I now use by default, with two systems as examples: a coding-agent studio run by a Python orchestrator, and a production document pipeline for construction plans.

What AI workflow orchestration means

AI workflow orchestration is the layer that coordinates the steps of an AI workflow: which step runs next, which inputs it receives, where its output goes, what happens when it fails, and when a person has to approve before the workflow continues.

The steps themselves can be anything: a vision model reading a document, a language model drafting a reply, an agent writing code, a rule checking a value, an API call that changes a record. The orchestrator does not do that work. It holds the order, the state and the handoffs between steps.

That is also what separates orchestration from a single AI task. One prompt gives one answer. An orchestrated workflow has to remember where it is, pass the right context forward, stop in a known state, and avoid doing the same external action twice.

Two ways to orchestrate: a model or a script

In agent-driven orchestration, a model acts as the coordinator. It reads the goal, breaks it into tasks, decides which agent or tool runs next, and judges when the work is done.

In deterministic orchestration, code is the coordinator. A script, a queue or a workflow engine dispatches tasks in a fixed or rule-based order, and models are called inside individual steps with a bounded job and an expected output.

The trade-off is straightforward:

A model coordinator adapts to goals nobody planned for, but the same input can produce a different plan on the next run, and a failure is hard to trace to one decision.
A code coordinator cannot improvise, but every transition can be logged, replayed and tested, and a skipped step is a bug you can find, not a choice a model made.
Both still need models for the steps that interpret: reading, classifying, drafting and recommending.

For workflows that touch real records, code, money or customers, I put the coordination in code. The judgment that needs a model happens inside steps, and the decision about what happens next stays readable.

A deterministic orchestrator for five coding agents

My MVP studio ran five specialized OpenClaw coding agents on a single VPS. The coordinator was not a sixth agent. It was a Python loop.

The loop polled the project KANBAN every 60 seconds, picked the next ready task in dependency order, started the right agent, sent finished work to the reviewer agent, and merged once the reviewer approved. Status messages went to Telegram directly from the script.

Two of the hardest problems in that project were orchestration problems, not model problems: preventing race conditions between the developer and reviewer agents, and keeping task dispatch deterministic instead of agent-driven. Escalation was a rule too. A task still blocked after three review cycles went to me.

Judgment stayed with the agents that needed it. A PM agent wrote the plan and asked me for approval before any code was written, and developer agents decided how to implement each task. When something broke, I read the script and found the cause, instead of guessing why a model had chosen to skip a task.

Read the OpenClaw MVP studio case study. Five AI coding agents, one deterministic Python orchestrator and a Telegram approval flow on a single VPS.

The same split in a production document pipeline

AnalyzTech verifies floorplans and long construction documents for technical engineers and compliance controllers. Its pipeline runs in a fixed order: PDF input, wall and door detection with Kreo, furniture and open-door detection with YOLO, room extraction, room classification with a vision-language model, post-processing, then AI agent verification.

The models do the interpretation: detecting elements on a plan and classifying rooms. The order of the stages, the post-processing and the hand-off to verification are fixed by the pipeline. Engineers inspect the extracted room polygons on the plan before triggering AI-assisted checks, so the professional judgment stays with them.

The earlier floorplan pipeline I upgraded at BTP Consultants follows the same pattern: polygon extraction, post-processing that enriches the polygons with context, then rule-based checks for accessibility and fire safety, followed by a report. The rules are code, so a controller can see why a check passed or failed.

See the AnalyzTech pipeline case study. Detection, extraction and classification models inside a fixed verification pipeline, with engineers reviewing the result on the plan.

Where AI workflow orchestration usually breaks

The failures I see most often are in the coordination, not in the model’s answer:

Context does not travel: a later step does not receive the output or the source an earlier step produced, so it works from a guess.
Two workers change the same state: a developer agent and a reviewer agent, or two retries, act on one task at the same time.
A retry repeats an external action: without idempotency, a timeout creates a second record or sends a second message.
A model decides to skip a step: a coordinator model judges a check unnecessary, and nothing records that it was skipped.
The approval sits in the wrong place: a person signs off every intermediate answer, or nobody signs off the action that is expensive to undo.
The first version is too broad: orchestrating many agents and many workflows at once before one of them runs reliably.

The last one is a lesson from my own AI Agent Framework, a solo R&D framework for orchestrating agent swarms. The key learning was that orchestration complexity has to be managed early. If I restarted it, I would ship a narrower first version and add features step by step.

Read what belongs in the deterministic layer. State, validation, retries, idempotency, approvals and actions are rules, so code should own them.

How to orchestrate your first AI workflow

If you are planning an orchestrated AI workflow, this is the order I would follow:

Write down every step of the current process, with its input, its output and who uses the result.
Mark each step as interpreting (reading, classifying, drafting, recommending) or deciding (checking, calculating, routing, changing a record).
Put the order, the state, the retries and the escalation rules in code: a script, a queue or a workflow engine, whichever is the simplest that fits.
Give each model step one bounded job and a structured output that the next step validates before using it.
Place one human approval before the action that is expensive to undo, and show the reviewer the evidence behind it.
Log every transition, so a failure can be traced to one step and one decision.
Start with one workflow and run it reliably before connecting a second one.

Models are good at the messy parts of a workflow. The workflow itself should be boring, inspectable code. If you want help designing or building one, the hire page explains how I work on AI agent and automation projects.

Read where the human approval belongs. Approve the action that is expensive to undo, show the reviewer the evidence, and make sure the gate can say no.