Technology
AI Orchestration
Multiple agents, models and rules coordinated as one workflow, with state, retries and escalation handled for them.
The concept
Coordinating agents and models inside one workflow
Which agent runs next, what it is given, which tools it may call and what happens when it fails. The process around the agents is workflow orchestration.
A single supplier invoice in FinSuite passes through several agents. One reads it, one matches it to the purchase order and goods receipt, one checks tax, one routes it for approval and one posts it. Each is narrow on purpose. Something has to sit between them, decide which runs next, hand each one what it needs and nothing more, and notice when one of them fails. That is the AI orchestrator. Agents never call each other. They return a result to the orchestrator, which writes it to the item's record and picks the next step.
Most of its work is about limits. Each agent is given a context assembled for its job: the Matching Agent receives the invoice lines, the vendor and the PO reference, and does not receive the image or the vendor's bank details. Each agent has a declared set of tools, and the orchestrator executes calls to those and refuses the rest. Where a model is involved, its output is checked against a schema before the orchestrator accepts it. A call that times out is retried. One that keeps failing is parked with the reason, and a step that changes an outside system is never repeated blindly.
The two kinds of orchestration are easy to confuse, and worth keeping apart. The AI orchestrator works in seconds, between machine steps: agent, model, tool, result. The workflow engine works in hours and days, across people and systems: the AP exceptions queue, the approver's eight-hour clock, the move to cover when nobody acts, the posting window at month end. When an agent's work needs a person, the AI orchestrator hands the item to the workflow engine and waits. Both write to the same record, so the full history of an item is in one place.
Where it sits
The orchestrator across the five stages
PTAS AI workflows run as Perception, Intelligence, Orchestration, Action and Verification. The AI orchestrator owns the machine side of the third stage and touches every other one.
Two orchestrators
AI orchestration and workflow orchestration, side by side
The same invoice, seen by both engines at the same moment. One is moving it between agents. The other is tracking who owes it a decision. Values are illustrative.
One invoice, two orchestrators. Illustrative example
If the question is which agent runs next and what it may touch, that is AI orchestration. If it is who has to act and by when, that is workflow orchestration.
In the products
How agents are coordinated inside DocPro and FinSuite
In DocPro the orchestrator routes documents to the right agent and checks what comes back. In FinSuite it runs a chain of agents over one record and hands over to people where policy says so.
DocPro
Routing by document type
A classified document goes to the agent for its type: Invoice, Receipt, Bank Statement, KYC & Identity, Purchase Order or a custom document agent. One that could not be classified goes to review before any agent sees it.
DocPro
Context cut to the job
An extraction agent receives the pages and regions of its own document and the extraction instructions for that sender. It never sees the other documents that arrived in the same bundle.
DocPro
Output checked before hand-off
Each agent's result is checked against its output schema and validation rules before anything else reads it. A malformed result is retried once, then sent to review with the raw output attached.
FinSuite
One record, many agents
Each FinSuite agent adds to the item's record and the next one starts from it: lines and vendor, then PO and GRN, then tax status, then approval. What an agent knew is what the record held at its step.
FinSuite
Write permission held by one agent
Only the Posting Agent holds the ERP write tool, through the integration method agreed in assessment. The orchestrator calls it once, after approval, and waits for the document number to come back.
FinSuite
Hand-off to people
When a result needs a person, a variance outside tolerance or an amount above a band, the orchestrator passes the item to the workflow engine with the reason. When the person acts, the agent chain resumes.
Worked example
Five agents on one invoice, and what one of them was allowed
The orchestrator's view of one supplier invoice moving through the chain. Then the limits it set for a single agent at a single step. Values are illustrative.
One invoice, five agents, no handover meeting · Illustrative example
Narrow jobs are deliberate. An agent that does one thing can be tested, measured and replaced; one that does everything cannot.
No agent calls another
Each returns its result to the orchestrator, which writes it down and picks the next step.
State lives on the record
The Posting Agent works from what four agents established, without re-reading the invoice.
A failure stays in its step
When a lookup failed, only that step was retried. Nothing upstream ran again.
Now open the second step. Before the Matching Agent ran, the orchestrator decided what it would be given and which calls it could make. The record of that step shows both, along with a lookup that timed out and was retried.
What the Matching Agent was given. Illustrative example
An agent cannot misuse data it was never given or a tool it was never declared. Cutting the context to the job is as much a control as cutting the tools.
Given what the job needs
Lines and vendor in. Image and bank details withheld, because matching needs neither.
Tools declared in advance
Read PO and read GRN were available. Posting was not, so it could not be attempted.
Every call on the record
The timeout, the retry and the accepted result sit in the trace with their times.
Limits and controls
What orchestration cannot fix
An orchestrator coordinates. It does not make a weak agent strong. If the Invoice Agent reads a quantity wrong with high confidence, the orchestrator passes that wrong quantity on as faithfully as a right one, and the match fails two steps later for a reason that started upstream. The record shows where it started, which is much of the reason for keeping it.
Orchestration also adds moving parts. More agents means more hand-offs, and each hand-off is a place where context can be cut too thin for the next job. We keep chains short, give each agent the context its job needs and test the chain as a whole as well as each agent in it. And the orchestrator follows the sequence it was given. A chain designed in the wrong order runs in the wrong order, reliably.
Declared tools only
The orchestrator executes only the tool calls declared for the calling agent. Anything else is refused and written to the record with the agent and the step.
Context assembled per step
Each agent receives the fields and records its job needs. Images, bank details and personal data go only to the agents whose job requires them.
Retries that cannot double-post
Read calls are retried after a pause. A call that changes an outside system carries a key, so a retry after a timeout cannot create a second document.
Escalation into the workflow
When an agent's result needs a person, the item moves to a workflow queue with the reason and the agent chain waits. Nothing is held in an agent's memory in the meantime.
How a single agent is bounded is covered under Agentic AI Architecture. What happens once an item reaches a person, with its queue, owner and clock, is under Workflow Orchestration.
FAQ
Questions architects ask about AI orchestration
What is the difference between AI orchestration and workflow orchestration?
AI orchestration coordinates agents and models: which agent runs next, what context it is given, which tools it may call, and what happens when a call fails. It works between machine steps, usually in seconds. Workflow orchestration runs the business process around those steps: queues, owners, approval routes, clocks and escalation across people and systems, over hours or days. When an agent needs a person, the item passes from the first to the second and back again, and both write to the same record.
Can one agent call another agent, or pass it data directly?
No. Agents return results to the orchestrator, which writes them to the item's record and decides the next step. The next agent reads from that record, cut to what its job needs. Direct calls between agents would make the path of an item depend on how each agent was written, and would leave hand-offs that nobody recorded.
Which failures are retried, and which are not?
Reads are retried: a purchase order lookup that times out runs again after a pause. Output that fails its schema check is retried once, then sent to review with the raw output. Anything that changes an outside system, such as a posting, carries a key so a retry cannot duplicate it, and it counts as done only when the receiving system confirms. Repeated failures park the item in a queue a person owns, with the step and the reason shown.
Can we add our own agent to an existing chain?
Yes, as engineering work. A custom agent is declared with its context, its tools, its output schema and its place in the chain, tested with the chain as a whole, and released like any other change. Adding it does not widen what the existing agents may see or call.
Keep reading
Where AI orchestration connects
Workflow Orchestration
The process engine: queues, clocks, approvals and escalation across people and systems.
Read more →Agentic AI Architecture
How one agent is built: context, declared tools, rules and a verifier.
Read more →Autonomous AI Agents
The named agents the orchestrator coordinates, and the job each one owns.
Read more →AI Security and Governance
How agent permissions are granted, reviewed and audited.
Read more →Next step
Map the agent chain for one workflow
Bring one process. We will lay out which agents it needs, what each one sees and may call, and the points where the chain hands over to people.