Workflow Redesign

Introduction to Agentic Workflows

Concept · 3 min read

An agentic workflow is a process in which a software system is given a goal rather than a sequence of steps, and works out the steps itself within limits you set. The shift matters less than it sounds: the hard part is not making the system capable, it is deciding how much of the process to hand over and what the system must never do on its own.

What makes a workflow agentic

Traditional automation executes a fixed path. A rules engine reads a form, validates a field, writes a record — the same way every time. An agentic system is given an objective, such as reconciling a shipment against the purchase order and flagging anything that does not match, and chooses its own tools and sequence to reach it. It can look up a record, call a calculation, ask a person, or stop when it is unsure. The difference is not intelligence for its own sake but the ability to handle variation that would previously have required a person.

That flexibility is also the risk. A fixed process fails predictably; an agentic one can fail in ways nobody anticipated. The design question therefore moves from what the steps are to what the goal is, what resources the system may touch, and where it must stop.

Bounded autonomy and escalation

Every agentic workflow needs four things defined before it runs. A clear objective, stated as an outcome rather than a task. A boundary of where it can act — which systems it may read, which it may write, and what volume or value it may commit. An escalation path for the cases it should not resolve alone. And a feedback loop that records what it did and how often it was overridden, so the boundary can be tightened or loosened with evidence.

The instinct is to start with the most impressive end-to-end process. In practice the workable starting point is a narrow, high-volume task with a clear right answer and a person close at hand to catch errors.

• Objective, not task list — state the outcome the system must achieve and let it choose the method.
• Bounded resources — define exactly which systems, budgets and records it may act on.
• Escalation on uncertainty — when confidence is low or the case is out of scope, hand it to a person rather than guess.
• Logged decisions — record every action, tool call and override so the boundary can be tuned over time.

Questions to ask

• Which of our processes varies enough that a fixed rule book keeps failing, and is that variation worth the cost of an adaptive system?
• What is the worst outcome if this system acts incorrectly and nobody checks — and is that acceptable?
• Who owns the boundary when it needs to change, and what evidence would justify widening it?
• How will we know the system is working, beyond the fact that it has not gone wrong yet?

Process Mining for AI Readiness

Method · 3 min read

Most organisations redesign processes from the diagram they believe they follow, not from what actually happens. Process mining closes that gap by reconstructing the real flow from the timestamps and events already sitting in your systems. It is the least glamorous step in AI readiness and usually the most decisive.

From the map to the territory

Every enterprise system — ERP, manufacturing execution, ticketing, workflow tools — writes a log of what was done, by whom, and when. Process mining reads those logs and rebuilds the sequence of events for each case: an order, a claim, a maintenance job. The result is a picture of the process as executed, including the loops, skipped steps and workarounds that never appear on the approved diagram.

This matters because AI aimed at the official process will miss the real one. If a step is bypassed half the time, an automation built for it will sit idle; if a bottleneck is caused by rework rather than volume, adding capacity elsewhere will not help.

What to look for before automating

Three findings change how a workflow should be redesigned. First, variation: the same case taking many different paths, which tells you where an adaptive system earns its keep and where a fixed rule already suffices. Second, rework and loops: the steps repeated because an earlier step was incomplete, which are often better removed than automated. Third, handoffs: the points where work waits between people or systems, which are the usual home of delay.

The order matters. Removing a wasteful step is almost always cheaper and safer than automating it. Mining first turns the question from what could we automate into what is worth automating, and what should simply stop.

• Map the real flow — reconstruct the executed process from event logs, not the approved diagram.
• Quantify variation — count how many distinct paths each case type takes and how often each is used.
• Find the rework — identify loops and repeated steps caused by earlier incompleteness.
• Locate the wait — measure idle time at each handoff, where delay usually accumulates.

Getting the logs to speak

Process mining is only as good as its event data. Logs need a case identifier, a timestamp, and an activity name recorded consistently. Systems that were never designed to be analysed this way rarely meet all three, so a short data-preparation step is normal. That preparation is itself a useful readiness test: if you cannot reconstruct a process from your own records, neither can an AI system.

Questions to ask

• Can we reconstruct any core process end to end from our existing system logs today?
• How many distinct paths does our most important case type actually take?
• Which approval or handoff adds the most waiting time relative to the work it contains?
• Where is rework masking itself as volume?

Designing Human-in-the-Loop Systems

Design · 2 min read

Human-in-the-loop is not a fallback for when the AI is not good enough; it is a deliberate design choice about which decisions a person should keep. The goal is not to keep humans busy but to place them exactly where their judgement changes the outcome.

Deciding where the human sits

There are three common placements, and they are not interchangeable. Human-in-the-loop means the system cannot proceed until a person approves. Human-on-the-loop means the system proceeds but a person monitors and can intervene. Human-out-of-the-loop means it runs unattended. A well-designed workflow uses more than one: routine cases run unattended, unusual or high-value cases pause for approval, and everything is visible to someone watching.

The choice should follow two variables: the cost of being wrong, and how reversible the action is. A wrong internal draft is cheap and easily corrected. A wrong payment, a dispatched batch, or a message to a customer is not. Place the human where error is costly or hard to undo, and leave them out where it is neither.

Making decisions reviewable

A person cannot judge a recommendation they cannot see through. Effective review shows the inputs the system used, the reasoning in plain terms, the confidence or uncertainty, and the alternative it rejected. Reviewers need to be able to act on that in seconds — approve, amend, or send back — without hunting through three systems.

Equally important is what happens to the review itself. If a person overrides a decision, that override is the most valuable training signal the system will ever get. Capture it, categorise it, and feed it back. A loop that catches errors but learns nothing from them is not human-in-the-loop; it is human-as-failsafe.

• Match placement to risk — unattended for cheap, reversible actions; approval for costly or irreversible ones.
• Show the reasoning — inputs, rationale, uncertainty and rejected alternatives, not just a score.
• Make action instant — approve, amend or escalate in one step, without switching tools.
• Learn from overrides — treat every human correction as a signal and route it back into the system.

Questions to ask

• For each AI-assisted decision, what is the cost of being wrong and how hard is it to reverse?
• Can a reviewer see enough to disagree with the system, or are they only able to rubber-stamp it?
• What happens to a human correction after it is made — is it captured, and does it change future behaviour?
• Are we measuring how often humans override the system, and what that rate is telling us?

Automation Patterns for Industry

Patterns · 3 min read

Most useful automation in industry falls into a handful of recurring patterns. They differ in ambition and in what they demand of your data, but they share a logic: pick the pattern that matches the maturity of the information you already have, not the one that sounds most advanced.

Four patterns and what they need

Document intelligence reads unstructured documents — invoices, delivery notes, inspection forms, contracts — and extracts structured fields for downstream systems. It needs a steady stream of similar documents, a clear set of fields to capture, and a person to handle the low-confidence cases. Its failure mode is silent: the system extracts a plausible but wrong value, and nobody notices until the error surfaces downstream. Confidence thresholds and spot checks are not optional.

Retrieval assistants answer questions from an organisation's own documents and procedures — a technician asks how to reset a machine, a planner asks for the current handling rule, an office team asks which form applies. They need clean, findable source material and a way to show where an answer came from. Their failure mode is confident-sounding invention: an answer that reads well but draws on a procedure that has been superseded. Attribution and dated sources are what keep it honest.

Monitoring and planning

Anomaly alerting watches sensor, quality or transactional data for readings that fall outside normal behaviour and raises them for attention. It needs historical data clean enough to define what normal looks like and, more importantly, a clear destination for every alert. Its failure mode is alert fatigue: too many marginal warnings, after which the real one is ignored. Precision matters more than recall here — a system that flags fewer, better events will be trusted for longer.

Scheduling and planning generates or proposes sequences — production runs, maintenance windows, delivery routes, staff rotas — against constraints a person would otherwise balance by hand. It needs the constraints written down explicitly and an accepted definition of a good plan. Its failure mode is an answer the planner cannot explain or adjust, after which they return to the spreadsheet and the tool is abandoned. The output must be editable and traceable to the constraints it used.

• Document intelligence — extract fields from documents; needs similar inputs and confidence handling; watch for silent wrong values.
• Retrieval assistants — answer from your own documents; needs clean sources and attribution; watch for confident invention.
• Anomaly alerting — flag abnormal readings; needs a baseline and a home for each alert; watch for alert fatigue.
• Scheduling and planning — propose sequences under constraints; needs explicit constraints and editable output; watch for abandonment.

Choosing where to start

The patterns are not ranked by sophistication but by how much your current data supports them. A retrieval assistant over well-managed documents will outperform a planning engine fed by inconsistent records. Start with the pattern your information is already ready for, prove it in one team, and let that success buy the data work the next pattern needs.

Questions to ask

• Which of these four patterns does our current data most plausibly support today?
• For each candidate, what is the failure mode, and would we notice it before a customer or auditor did?
• Who receives the output — a person who can act on it, or a queue nobody owns?
• What is our plan for the second pattern, once the first has proved itself?

Digital Twin Readiness

Technology · 2 min read

A digital twin is a working model of a physical asset, line or plant that stays current with the real thing. It is not a one-off simulation or a three-dimensional visualisation; it is a live counterpart you can query, test scenarios against, and use to close the loop between what a machine is doing and what you decide. Readiness is less about the model than about the data feeding it.

What readiness actually requires

Four conditions separate an organisation that can build a useful twin from one that cannot. The asset must be instrumented — sensors or system records that capture its state at a useful frequency. Operational technology and business systems must exchange data, so readings on the line connect to orders, quality and maintenance records. Data must follow consistent standards and identifiers, so a machine means the same thing in every system. And there must be a specific decision the twin will inform.

The last condition is the one most often skipped. A twin built simply to have a twin becomes an expensive dashboard nobody uses. A twin built to answer a particular question — where is the bottleneck on this line, which maintenance interval minimises downtime, how does throughput change if we alter this setting — has a reason to exist and a way to prove its worth.

Starting small and proving value

The realistic starting point is a single machine, cell or line, chosen because it matters and because its data is already reasonably good. Model it, connect it, and use it to answer the one question that justified it. Then compare what the twin predicted against what happened. That comparison — not the model's elegance — is the measure of success.

Scaling comes only after that loop closes. A twin that has repeatedly been right about one line earns the right to extend to the next, and each extension teaches you which data and standards were actually load-bearing. Attempting a plant-wide twin before any single asset has proved its value is the most common way these programmes fail.

• Instrumented asset — sensors or system records capturing state at a frequency the decision needs.
• Connected OT and IT — line-level readings linked to orders, quality and maintenance data.
• Shared identifiers and standards — the same machine, part and code meaning the same thing everywhere.
• A specific decision — one question the twin exists to answer, with a way to check its answers.

Questions to ask

• Which single asset has both operational importance and data clean enough to model first?
• What decision would change if we could see this asset's state and behaviour more clearly?
• Can our operational technology and business systems currently exchange data about that asset?
• How will we compare the twin's predictions against reality, and who will act when they diverge?