Imagine a superannuation member calling about a delayed benefit payment. The call ends, but the enquiry remains open. An AI assistant can draft an answer. A workflow agent can gather the relevant records and route the case. A long-running agent could follow up on missing information and bring it back when something changes.
The last job extends beyond an individual interaction. Someone has to know whether the member's issue was resolved, whether the answer was authorised and what happens when the agent cannot finish.
David Haber at a16z describes the move toward agents that stay with a high-value customer journey. The idea is useful. In Australian financial services, it needs an additional question: who is answerable while the agent is working, and after it stops?
Give the long-running agent a case to manage
An assistant usually has a short-lived task. A workflow agent may complete an interaction. A long-running agent has to retain state across events, people and time. Calling all three an "agent" hides a serious operating difference.
Take the member enquiry. Between the first contact and a satisfactory resolution, a request may pass through administration, a specialist and an external provider. The answer can change when a missing document arrives. A long-running system needs a case record that identifies the member, the request, the evidence received, the next expected event and the person accountable for progress.
It also needs a definition of done. "Respond to the member" is an action; "resolve the issue" is an outcome that must be checked. A drafted response might close a task while leaving the underlying payment problem untouched.
The practical design question is what the agent may do while the case remains open. Reading a record, requesting a missing document, proposing a response and changing an account are different levels of authority. Time spent running does not confer permission to cross from one to the next.
The commercial model changes the risk
Haber sets out several ways an agent business could reach a customer: sell software to the incumbent, take over an existing outsourced service, or operate a business built around the work. Those models are worth examining from the buyer's side.
With software, the financial institution keeps operating the service. It must decide which team owns the agent, how outcomes are measured and who responds when the system stalls. A vendor may have supplied the capability; accountability for the customer journey has not simply moved with the licence fee.
With an outsourced service, there is often an existing budget and an existing service boundary. The contract still needs to say what gets handed back, which records the provider can hold, and how the institution verifies that a case was handled well rather than merely closed quickly.
If the agent provider becomes the regulated business, it takes on a different set of responsibilities. The operating and legal position has to be designed for the activity it conducts.
Outcome pricing sounds attractive in each model. It can also create perverse incentives. If the fee depends on "cases resolved", what stops a case being marked resolved after a plausible but incomplete answer? If it depends on a faster loan application, which party gets credit when an employee fixes the missing data? Before agreeing to an outcome price, the buyer and provider need a shared measure, a baseline and a way to inspect disputed cases. In advice or credit activities, qualified legal review of any outcome-linked remuneration belongs in that discussion too.
Keep authority visible for the life of the case
A long-running agent will encounter events that do not fit its original brief. The member changes their instruction. Two records disagree. A clock runs out. An external system is unavailable. Each event can alter what a safe next action looks like.
The case record should hold:
- The current goal and the named business owner, including who can change that goal.
- The evidence used for each material step, with source and time recorded.
- A list of actions the system may take independently and those requiring approval.
- An escalation route when evidence conflicts, a deadline passes or the agent cannot establish that the goal has been met.
An operator should be able to pick up the case without reconstructing weeks of messages. Build human override into ordinary service operations.
The team can grant narrow authority where it is justified, observe what happens and widen it when the evidence supports the change. The control stack for AI agents goes further into permissions and escalation; a case that stays open for weeks also needs someone watching its progress and closure.
Pick the outcome before the technology
If you are considering a long-running agent, start with a journey that already has a case owner and a recognisable end state. Map what currently ends the case, what causes it to reopen, where the delay sits and which decision must remain with an authorised person. Watch a few real exceptions before promising that an agent can own the whole path.
The first version may do something more modest than the sales pitch: keep the file together, remind the right person and prepare the next decision. That can still be valuable if the member gets a clearer answer and the team can show how it was reached.
If cases keep reopening because context is lost between teams, describe the hand-off that breaks. Our AI engineering work can begin with that case, its owner and the information they need to finish it.