A workflow has to work in production, not just in a demo.
Our design method is BEACON. It forces six questions to be answered before consequential AI is trusted with real work.
01
Candidacy
Should AI be here at all? Can "good" be defined, checked and measured?
02
Economics
Does the workflow make economic sense at production volume — not only in a pilot?
03
Architecture
How should models, data, retrieval, software, routing and human escalation fit together?
04
Boundary
What may the workflow access, do and decide? What must it never do?
05
Oversight
Where do people review, approve or take over — and who is accountable?
06
Navigation
How will the workflow be evaluated, monitored and changed after go-live?
Read: BEACON — six questions to answer before your AI goes to production →
HOW WE REDESIGN
AI will sometimes get it wrong. Where that matters, it does not decide alone.
AI is not ordinary software. Ask it the same thing twice and you can get two different answers. On a draft of an internal summary, that is fine. On a payment released, a claim decided or a customer declined, it is not.
So before anything goes live, we agree which cases the workflow handles on its own. That sits in the system itself, not in a policy document. Everything else stops, or goes to a named person.
ACT
The case is clear and inside the agreed boundary. The workflow moves it forward on its own.
ASK
Judgement is needed. The case goes to a named person, with the context ready.
STOP
The case is outside the boundary. The workflow does not proceed.
AI does not earn more autonomy because a demo looked good. It earns it because the workflow performed against agreed evidence.
Read: Accountable autonomy — five levers for AI you can let act →
Economics
Most AI business cases are written at pilot prices.
A pilot runs a few hundred cases and the cost barely registers. The same work at full volume runs hundreds of thousands. The number that matters is the cost of one run — one document, one ticket, one claim — times how many you actually do.
We work that out before anything is built, and again before it goes live. Not the licence cost. What it costs to run the work.
Which model, where
The largest models are not needed for every step. Matching the model to the step is usually the biggest single lever on what a workflow costs.
How many times round
Every retry, re-read and extra step multiplies. A workflow that goes round twice costs twice.
How often a person is pulled in
Human review is worth it where the consequence demands it, and expensive everywhere else.
A workflow can work perfectly and still not be worth running. Better to know that before it is built.
OUR SYSTEM
Encoded, not improvised.
The way we work is written down rather than carried in someone’s head, so every engagement uses the same methods and the same standards.
Behind them sits our advisory intelligence system — the patterns that hold up in production, what particular models and vendors are good for, what they cost to run, the controls that matter, and what has gone wrong elsewhere. Every engagement draws on it, and every engagement adds to it.
BEACON
The design method. The six questions above, and the evidence each one has to produce before a workflow is allowed to go live.
Read the articleORBIT
The operating method. What gets watched once a workflow is live: whether it is still accurate, what it costs to run, which exceptions keep coming back, and who owns each of those.
Read the articleFORGE
A neutral reference stack. Where you would rather not start from a vendor's architecture, it gives you a working starting point that runs in your environment and locks you into nothing.
Read the articleThese travel with every engagement, and you keep whatever we produce with them.
Technology
Your environment. Your constraints.
We start from your environment, not from a product. The workflow is designed around your cloud, systems, approved models, data-residency requirements and security controls.
Technology choices follow the workflow and its economics, not a vendor quota.
Bring us a workflow
The quickest way to judge a method is to see it applied to work you already know. Bring one workflow and we will do that.