“Agent orchestration” is turning up in finance job postings.
A Draup analysis reported by CNBC found that references to the skill rose 1,721% year over year. That is a measure from one hiring-data firm, not a universal count of the labour market. But the shape of the demand is more useful than the headline number.
The firms are not only looking for people who can build models. They want people who can place AI inside trading, compliance, back-office operations, and other real business functions. CNBC describes forward-deployed engineers who combine technical capability with domain knowledge. Their job includes deciding which agents are needed, what each one should do, which technology to use, and when a human must step in.[1]
That last part is where the scarce skill sits.
It is not knowing the happy path. It is understanding the exceptions.
A procedure is not the whole job
Ask someone how an invoice is processed and they may give you a neat sequence:
- Receive the invoice.
- Match it to the purchase order.
- Confirm receipt.
- Post it to the ERP.
- Route it for payment.
That sequence is easy to document. It is also the least interesting part of the work.
The value of an experienced accounts payable specialist appears when the sequence breaks.
What if the supplier name differs from the master record? What if the purchase order is in one currency and the invoice in another? What if goods were received in two batches? What if a credit note exists but has not been applied? What if the amount is within tolerance but the bank details changed yesterday? What if the invoice is technically valid but the project owner is disputing the delivery?
A junior employee sees a mismatch.
An experienced operator sees several different kinds of mismatch, each with a different consequence.
That judgment is often tacit. It lives in habits, remembered incidents, side conversations, and the mental model of the person who has handled the process for years. It may never appear in the official SOP because the SOP was written to explain the normal case.
This is why companies can automate a clean demo and still struggle in production. The demo proves that the agent can follow the path. The business needs confidence that the system will react correctly when the path branches.
The Agent Boss is not the best prompt writer
There is a temptation to treat agent orchestration as a new technical speciality that belongs entirely to engineers.
Engineering matters. Agents need tools, identities, data access, tests, logging, and reliable execution. But the person designing the work also needs to know what a correct business outcome looks like.
That person may be a controller, an operations manager, an ERP owner, a sales-operations lead, or a service manager.
They do not need to become a software engineer. They need to make their judgment legible.
I use Agent Boss as a useful description of this responsibility. It is not a claim that every company has created a formal job title. It describes the person who turns an outcome into bounded assignments for digital coworkers.
A capable Agent Boss can answer five questions:
- What starts the work? A new invoice, a CRM status change, a month-end deadline, or another explicit event.
- What may the agent decide? Which cases are routine enough for the agent to complete without intervention?
- What must the agent escalate? Which exceptions require evidence, approval, or specialist judgment?
- Who owns the next decision? Escalation to “a human” is not enough. Name the role.
- How will we know the outcome is correct? Define the business result, not just whether the model returned an answer.
The agent framework cannot invent these boundaries for the company. They come from domain expertise.
Turn tacit judgment into four operating elements
Most teams do not need to begin with a large automation programme. They need to capture one exception-rich workflow and make its hidden rules explicit.
Start with four elements.
1. Triggers
Define the event that creates work.
For an invoice workflow, it might be “a new supplier invoice arrives in the approved inbox.” That is better than “check invoices regularly” because it gives the system a clear start condition.
Also define the events that should restart or suspend the work. A revised invoice, a changed purchase order, or a supplier-master update may invalidate an earlier conclusion.
2. Decision boundaries
Separate what the agent may decide from what it may only recommend.
The agent may be allowed to match an invoice when supplier, currency, amount, purchase order, and receipt all agree within a documented tolerance. It may be allowed to prepare a posting draft.
It may not be allowed to approve a changed bank account, waive a missing receipt, or release a payment.
A boundary is useful only when it is specific enough to test.
3. Escalation rules
Describe the exception and the destination.
“Escalate anomalies” is vague. “Send bank-detail changes to the finance manager with the old value, new value, change timestamp, supplier contact record, and verification status” is operational.
The quality of the escalation package matters. A human should receive the evidence needed to decide, not a notification that creates another investigation.
4. Measurable outcomes
Do not measure success by the number of agent actions.
For accounts payable, useful measures could include correctly matched invoices, exception precision, review time per escalated case, duplicate-payment prevention, posting accuracy, and cycle time from receipt to ready-for-payment.
More agent activity is not the goal. Better business throughput with controlled error is.
One workflow before an army of agents
The CNBC report describes financial institutions stringing together specialised agents for tasks such as inspecting data, analysing documents, and checking compliance.[1] That makes sense when the work genuinely benefits from separate responsibilities.
But more agents do not automatically create a better process.
Every handoff can lose context. Every additional tool adds another failure point. Every automated decision needs a clear owner when the business rule changes.
For an SME, I would start smaller:
- one recurring workflow;
- one clearly defined outcome;
- one agent with a bounded responsibility;
- one named reviewer for exceptions;
- one set of acceptance measures.
Only split the work across more agents when the separation improves reliability, accountability, or cost.
This is orchestration as an operating discipline, not a software collection hobby.
Domain experts are closer than they think
The rise of agent orchestration should not send finance and operations professionals into a panic about coding.
It should make them take their process knowledge more seriously.
The person who knows why a customer receives different credit treatment, why one supplier exception is harmless and another is dangerous, or why month-end adjustments need a second pair of eyes holds valuable design knowledge.
The next step is to make that knowledge explicit enough for a digital coworker to follow and constrained enough for the business to trust.
This week, choose one recurring workflow with frequent exceptions. Sit with the person who resolves them. For each exception, write down:
- what evidence they inspect;
- what decision they make;
- what the agent may do;
- what the agent must escalate;
- who approves the next step;
- how the completed outcome will be checked.
Do that well and you have more than an SOP.
You have the first job specification for an agent, the first review guide for its human supervisor, and the beginnings of a real Agent Boss capability.
The scarce AI skill is not creating more digital workers.
It is knowing where the work stops being routine.
Sources
[1] https://www.cnbc.com/2026/10/02/ai-redefining-wall-street-jobs.html — How AI is redefining Wall Street jobs — and boosting demand for this new hottest skill by 1,721%