Redesigning a Process Around an AI Agent Instead of Bolting One On

Start by watching, or asking someone to walk you through, how a process actually happens today, including the workarounds nobody wrote down. Documented processes and lived processes diverge constantly, and redesigning around the documented version means missing the real friction points. Write down every handoff, every wait, and every step that exists only because a previous tool couldn't do something an agent now can.

A good sign you've found the real process rather than the documented one: someone says "well, technically we're supposed to do X, but actually we do Y because X takes too long." That Y is what a redesign needs to account for, not the official X nobody actually follows anymore.

Once the process is mapped, tag each step as judgment-based (requires weighing tradeoffs or context a document can't fully capture) or mechanical (follows a consistent rule regardless of context). Agents are strong at the mechanical steps and weak at genuine judgment calls, no matter how sophisticated the model. A redesign that tries to automate judgment steps just moves the errors from a person to a machine, without actually reducing them.

A useful gut check: if two experienced people would reliably reach the same answer given the same inputs, it's probably mechanical. If they'd reasonably disagree, it's a judgment call and belongs with a person.

The biggest gains usually come from collapsing handoffs, not from speeding up any single step. If a request currently passes through four people before reaching someone who can act on it, an agent that can route directly to the right person, using the same judgment the intermediate steps were providing, removes three handoffs at once rather than just making each one faster.

Count the handoffs in your current process map before you touch anything else. Each one is a place where context gets lost, a queue builds up, or a request sits waiting for someone's attention. A redesign that removes two handoffs usually beats one that makes all four handoffs marginally faster.

For example, suppose a purchase request passes from the requester to a manager, then to finance, then to procurement before anyone can act on it. An agent that reads the request, checks it against the spend rules, and routes it straight to the person who can approve it removes the middle steps entirely. The common mistake is keeping every old handoff and simply making each one faster. Before removing a handoff, ask what it was really providing, such as a policy check or a budget confirmation, and make sure the agent or a written rule now covers it. A handoff that only passed information along can go; one that carried judgment should stay with a person.

Pick one process with clear before-and-after metrics, run the redesigned version alongside the old one for a few weeks, and compare actual outcomes rather than assuming success. A common mistake is redesigning five processes simultaneously and losing the ability to tell which change actually caused which result when something goes wrong.

Choose a process where a mistake is recoverable for the pilot, not your highest-stakes workflow. An internal IT request queue is a reasonable first pilot. A customer-facing billing process is not, no matter how confident the redesign looks on paper before it's been tested against real volume.

Run the pilot in this sequence:

1. Choose one process with clear before-and-after metrics where a mistake is recoverable, such as an internal IT request queue.
2. Run the redesigned version alongside the old one for a few weeks, so outcomes can be compared directly.
3. Compare actual results against the old process instead of assuming the redesign worked.
4. Change one process at a time, so any result can be traced back to a specific change.
5. Write the new process down as an SOP, including rejected alternatives, before rolling it out to other teams.

Once the pilot proves out, write the new process down as a real SOP before rolling it to other teams, capturing not just the steps but the reasoning behind which parts stayed manual. A tool like ClickUp for tracking the rollout, paired with a checklist tool like Trainual for training the teams adopting it, keeps the redesign from becoming tribal knowledge that only the original team understands.

Include the rejected alternatives in that documentation too, not just the final design. Knowing that a fully automated version was considered and rejected because it removed a necessary judgment call saves the next team from proposing the same automation again in eighteen months without knowing it was already tried.