Insights / Operating model
The third operator
Designing work for people, agents and the software you already own, without pretending any of them can do it all.
For most of the history of operations there were two kinds of worker: people and software. Software did the deterministic work, people did the rest, and every operating model was a negotiation about where the line sat.
Agents are a third kind. They are not software in the old sense, because they handle ambiguity and language. They are not people, because they do not carry accountability, relationships or judgement about the exceptional. Treating them as either leads to the two most common redesign mistakes we see.
Mistake one: the agent as a faster person
Drop an agent into the existing process, give it the same tasks a case handler had, and measure how much faster it goes. This is the RPA playbook, and it produces the RPA result: a brittle automation of a process that should have been changed.
Agents change what is worth doing. If an agent can check a pack against the evidence requirements in seconds, the process no longer needs a queue for checking, a queue for re-checking and a queue for chasing. The redesign question is not "which tasks can the agent do?" but "what does this process look like when reading and matching are free?"
Mistake two: the agent as the new system
The opposite error is to route everything through the agent, including work your existing software already does well. A rules engine that calculates affordability correctly does not need a language model in front of it. A workflow tool that can send a chase email on day three does not need an agent to decide to send it.
The systems you already own are usually cheaper, more predictable and easier to audit than an agent for the deterministic parts of the process. The redesign should give them more to do, not less. In several engagements the biggest single time saving came from an integration, not an agent.
Drawing the three lines
A workable operating model assigns every task to one of the three operators, with the reason recorded:
- Existing software keeps anything deterministic: calculations, routing on known criteria, scheduled chasing, status updates, data movement between systems.
- Agents take work that requires reading, matching, classifying, drafting and reasoning over context, where a correct answer exists most of the time and the cost of an error is recoverable.
- People keep judgement about the exceptional, decisions that change a customer's outcome, relationships, and accountability. They also approve the agent's outbound work until the evidence says they no longer need to.
The lines are not permanent. As the evaluation evidence grows, tasks migrate from people to agents. The model should say what evidence would justify each move.
Designing the handoffs
The operating model is only as good as its handoffs. An agent must know when to stop and hand to a person, and the person must receive the case with the agent's evidence trail intact. These stop conditions are designed up front, agreed with risk, and tested before go-live. Discovering them in production is how agents lose trust.
A practical rule: if a task's owner cannot be decided in ten minutes, it is two tasks. Split it until each piece has an obvious operator.
Done well, the third operator does not replace the first two. It makes the software more useful and the people more expert. The case handlers we work with end up doing narrower, harder, better-paid work. That is the version of this change worth designing for.