Proactive agency:why AI agents need process intelligence
Agents can do remarkable things, but only with what they can see. Pair them with process intelligence and the process asks for help before the customer has to.
Introduction
Agents are the most capable automation we have had. They can read a document, reason about a customer's situation, choose a tool and act in seconds. Most deployments point that at one question: can we do this faster? Usually, yes.
But capability is not the same as sight. An agent can only act on what it is shown, when it is asked. It cannot know that a customer three steps into a journey is heading for a disappointing outcome, because nothing has told it.
Give it that sight and an agent can do far more than speed things up. It can put a customer's journey right before the customer has to ask. That sight is process intelligence.
The short version
Agents can only act on what they can see, and most are called once something has gone wrong. Process intelligence gives them sight: it learns good and bad journeys from history, spots live ones drifting and estimates whether each will meet expectations. Where it will not, an agent steps in; workflows keep the rest consistent and cheap.
Every agent needs a trigger
An agent does not wake up on its own. Even a well-governed agent is answering a request that something else decided to make.
There are two kinds of trigger that matter here:
- Reactive: after something has happened. A complaint lands, a queue breaches, a customer opens the chatbot to ask for help. By then the customer has already felt it.
- Proactive: before it is too late. The journey is drifting from its path or its promise, and there is still time to change how it ends.
Most organisations only have the first kind. Take the most common: the chatbot. The agent may answer brilliantly, but the customer still had to ask. What if they did not need to?
Example scenario: falling behind on car finance
Someone buys a new car on credit. A few months in, money gets tight and the payments start to slip.
The usual way. Missed payments build until the account crosses a threshold and moves to collections. By then the arrears are large, the conversation is a demand for payment and the options are few. The lender may recover some money, but has probably lost the customer.
The proactive way. The first payment is a few days late, which on its own means little. But the customer also banks with you, so process intelligence sees the wider picture: growing pressure in their current account, though they can still afford most of the payment. It also knows how journeys like this tend to end if nobody acts. That is the trigger. An agent assembles the context and surfaces the support that could fit, such as a temporary reduced payment or a payment holiday. An authorised specialist then talks it through with the customer and decides.
The customer gets help before the arrears build, and the lender has a far better chance of avoiding harm, recovering what it is owed and keeping a customer who remembers being helped rather than chased. Joining current-account and finance data like this needs a clear lawful purpose, transparency and data minimisation.
So how does the process recognise that first late payment for what it is?
Process intelligence supplies the proactive trigger
A proactive trigger needs timely insight into running journeys, not last month's numbers. That is process intelligence (PI), which combines two complementary capabilities. Process mining uses event history to reveal how journeys really run: the paths, delays and repeated work. Process performance monitoring, building on long-standing business activity monitoring (BAM), tracks running journeys against their targets. The trigger comes from monitoring, sharpened by what mining has revealed.
- The journey's context. Where this case is now, against the path and promise it was meant to keep.
- The upstream flow. How it got here: which steps it took, what it waited on and what it went round twice. Watch those loopbacks: each adds a wait, a re-task, a repeated question and frustration.
- Knowledge of what usually comes next. From thousands of cases like it, what typically happens from this point, and how often it ends well.
BI says conversion fell last month. PI might say this applicant stopped at the income step two days ago, like forty others this week who came in through the same broker, and that most cases that stay stalled here for three days never complete.
Nothing has broken, and nobody has complained. The journey is simply heading away from its goal. Add predictive monitoring, which estimates where a journey will finish from how comparable journeys ended, and you have foresight while there is still time to act. It is an estimate, not a certainty, so act only as firmly as the evidence allows.
How it works, in four steps
The four steps in detail
Know what good and bad look like. From the evidence, not a workshop: thousands of past journeys show which paths reach the goal, how long they take and where they go wrong.
Spot divergence live. Compare every running journey with those patterns now, not in next month's report.
Judge the divergence. Not every deviation is bad: some are better than the typical path and worth learning from; others match known bad patterns, such as repeated loopbacks.
Expectations and gap analysis. Take an end-to-end, goal-centric view: compare what the customer and the business expect with where the journey is likely to finish, and act on the gap.
The fourth step matters most: the gap between what is expected and the likely finish, not a single late step, decides whether to act. Where a journey is likely to fall short, an agent can steer it back, find a new path to the goal or refer it to an authorised person.
Take a customer at step 3 of 5. PI sums up how the first three steps went, estimates the last two from similar cases and compares the likely finish with what they expect.
Play to everyone's strengths
Few organisations want to rip and replace what already works, and they should not. Their workflows hold years of domain logic and hard-won customer experience. Keep that logic, and redesign the journey around it where needed: in McKinsey's State of AI in 2026, nearly three-quarters of AI high performers had fundamentally redesigned workflows, against about a quarter of everyone else. So let each do what it does best:
- Workflows bring consistency, standardisation and lower cost. They carry the journeys that are on track.
- Agents bring judgement: handling the unexpected, personalising the experience and steering a journey back on course.
- Process intelligence gives both of them sight: it knows which journeys are on track and which need an agent.
Let the workflow carry the on-track journeys and handle known responses too: a forecast can trigger a plain reminder. Call an agent in where the fix needs judgement: reading the context, choosing between options or coordinating several actions. That is personalisation where it counts, without spending tokens on steps the workflow already handles well. Decisions reserved by law or business policy go to an authorised person, the boundary I set out in Structure at the edges, freedom in the middle.
Everyone wins: the customer's needs are met, the workflow keeps its know-how and low cost, and the agent personalises where it matters. And you can prove it: compare journeys an agent helped with similar ones it did not.
Conclusion
An agent that only reacts answers the customer who had to ask. Give it sight, and it steps in before they need to, exactly where it makes a difference.
Getting there takes three things, and only one is the agent: journeys that declare their goals, gap rules the business can approve and test, and an agent with a boundary. None of it starts with prompts. It starts with someone who can say what good and bad look like for a real process: the Agentic Analyst.
Agents are the muscle. Process intelligence is the foresight.
Let's talk
Putting agents on live journeys, or defining what "on track" means for a process you own? Drop me a message. I am keen to compare notes.