Your Tools Already Talk. You Just Can't Hear Them.

The forty-seven percent

We measured this inside three client organisations over the last year, with stopwatches and observed workflows. The number came out in a narrow range, between forty-two and fifty-one percent. Nearly half of knowledge-worker time in a modern enterprise is spent moving information between tools that could technically talk to each other but do not.

That is the invisible tax. It does not show up on any P&L. It does not show up in any workforce-planning spreadsheet. It shows up as people reading emails and typing the same information into a CRM, or receiving a Jira ticket and copying fields into a customer portal, or watching a Slack thread and updating a spreadsheet at the end of the day.

None of it is necessary. All of it is possible. Making it automatic is what we mean by orchestration.

A real workflow, anonymised

To make this concrete, here is an actual workflow we rebuilt for a European professional services firm in Q4 2025. Before and after.

Every node between "client email" and "project kickoff" was a human action. Receiving the email, deciding which channel to post in, summarising it in the CRM, pinging legal, drafting the contract, confirming the signature, creating the project, setting up invoicing. The total elapsed time from inbound inquiry to an active project was fourteen business days on average. Nine of those days were waiting time between handoffs.

After orchestration, the same flow has three human decisions: whether to engage the prospect at all, whether the contract shape is acceptable, and whether the project can kick off. The rest is automatic. The elapsed time went from fourteen days to two.

That is the before. The after is the same sequence compressed to three days: inquiry lands, is routed automatically to the right account manager with a draft reply and a risk score, the account manager approves or edits, the system handles contract generation and project creation in parallel, and the human decisions all happen on the critical path.

What actually had to change

Most of the work in rebuilding this was not AI. About sixty percent of the work was the unglamorous plumbing between systems. Reading the inbound email via Gmail API, classifying it, enriching against the CRM, routing to the right Slack channel, posting a draft reply, watching for approval, writing to the CRM, triggering a contract template, and so on.

The AI did three things specifically: it read the inbound email and extracted structured intent, it drafted the account manager's first reply in their voice, and it generated the initial contract draft from the CRM data plus a standard template. Everything else was classical integration work.

This is the quiet truth about orchestration. The AI is not the hard part. The hard part is a reliable, observable, testable translation layer between systems that were never designed to talk to each other. That layer is code. It lives in git. It has tests. It is boring. It is also what creates the value.

The five orchestration patterns we use most

Across more than thirty workflows we have rebuilt for clients, five patterns do most of the work. If you know what these are, you can spot the opportunity in your own organisation.

1. Inbound triage. Email, form submissions, support tickets. The AI reads, classifies, enriches, and routes. A human approves the routing only when confidence is below a threshold.

2. Meeting-to-action. Transcribe the meeting, extract decisions and actions, write them into the right system (Jira, Linear, Asana, CRM). The human edits if needed.

3. Draft-and-approve. Any written output that a human currently produces (reply emails, reports, contract first drafts, proposals). The AI drafts, the human edits. The edit itself becomes training signal for the next draft.

4. Cross-system reconciliation. When the same entity (a contact, a deal, a project) lives in five different systems with five different identifiers, the AI maintains the mapping and flags inconsistencies. This is the unglamorous one and also the one that most organisations need first.

5. Exception escalation. The AI watches the boring parts of the workflow. When something is out of range (a ticket aging beyond SLA, a client signal that looks concerning, a metric drifting), it writes to the right person with the right context. Not a dashboard alert. A message.

How to find your own candidates

A concrete exercise we run with clients in the first week of a diagnostic: pick five knowledge workers in different roles. Have each of them track, for three days, every time they copy information from one tool to another. The format is one line per transfer, including the source system, the destination system, and the fields moved.

At the end of three days, you have between thirty and a hundred transfers per person. Group them by source-destination pair. The top five pairs in your list are your orchestration candidates, full stop. Each one represents work that is currently done by a human and could be done by the translation layer.

We have never seen this exercise produce a boring list. We have seen it produce lists that change how the client thinks about where the bottlenecks actually are.

What orchestration is not

Worth being precise about the boundary. Orchestration is not:

• A chatbot in front of your data. That is a copilot. Useful. Different category.
• A no-code builder that promises to connect everything. Those tools exist and can do simple things. Anything that needs to survive a six-month regression, a compliance audit, or a change of vendor requires code.
• An agent framework. Those are libraries. They help you build orchestration. They are not orchestration by themselves.
• RPA. Robotic process automation operated at the UI layer. It is brittle by design. It breaks when a button moves. Orchestration operates at the API layer.

Orchestration is specifically: reliable, observable, version-controlled software that moves information between the systems your team already uses, with AI steps where they make sense and classical steps where they do not.

The economics

The question we get after every demo is "what does this cost to run." The honest answer for the example above: the orchestration layer for that workflow costs about EUR 180 per month to run in inference, hosting, and SaaS API usage. The upfront build cost was four weeks of one engineer and one designer, landing around EUR 55,000 all-in.

Against that, the client freed up roughly 1.4 FTE of account-manager time per year across their caseload, which at loaded cost is north of EUR 90,000 per year. The programme paid back inside nine months. The year-two ROI is not the right way to think about it. The right way is that the AMs now spend their time on client relationships rather than copying fields, and that is a quality-of-work change that shows up in retention and revenue in ways the spreadsheet cannot easily capture.

Where to start if you are convinced

We end every diagnostic with the same recommendation: pick one workflow, do it properly, ship it, measure it, and then pick the next one. Do not try to rebuild six in parallel. Do not buy a platform to solve all of them at once. Orchestration is a discipline, not a product, and the muscle is built one workflow at a time.

The first one should be an internal workflow, not a customer-facing one. The risk of getting it wrong is lower, the feedback loop is tighter, and you get to build the operational muscle of running a production AI workflow inside your own walls before you put one in front of a customer.

If you want help running the three-day logging exercise with your own team, we ship the template. It is free, it takes a week, and at the end you will know which workflows to rebuild first.