One decision matters most. I made the call go to the contact on file, never the one in the request, because a fraudster controls every detail in the request, including the phone number.

Designing the flow: when agents work and when people step in

Agents prepare, people decide, and every case ends with the payment being released or a complaint being raised with the supplier.

Design rules behind the flow: The checks run in parallel so a genuine supplier is not kept waiting. Each problem goes to the person who can judge it: security reviews fraud signals, and the finance manager reviews contract rules. When anything fails, the default never changes: hold the payment, change nothing, tell the person. An agent that is down or missing information never guesses. Silence never counts as approval: if nobody responds, the case waits and no agent proceeds on its own. A stuck case escalates after two working days, which is my proposal.

When an agent gets it wrong: An agent can be confidently wrong or invent a contract rule. So every agent passes its confidence on, and low confidence stops at a person. The policy check may only quote rules from the contract on file and say so when it finds none. A fraudster's request may contain hidden instructions, so the request reader can read but never act.

When a real supplier is held by mistake

A hold must never become a dead end. Anyone who clears a flag must say why, and the requester sees the new step.

  • What is logged: Who released it, when, which agent's flag it was, and a short reason they must write.

  • What the requester sees: The status screen shows the new step and its owner, for example, "Cleared by security review; call the contact on file next", so nobody has to chase.

Designing what each person sees

Nobody hears "the risk agent says"; they hear what it means for them. Three screens carry the trust: step progress for the requester, a call checklist for the caller, and a senior approval view with a "Why?" on every flag.

Requester. Where the case is, who owns it, and how long it has waited. Payments are clearly on hold. This is a status view: the requester decides nothing. Showing the owner and the wait lowers anxiety and stops people chasing by email outside the system.

Caller. The number comes from the register, not the request. The questions are written for them, and the outcome is recorded here.

Caller. The number comes from the register, not the request. The questions are written for them, and the outcome is recorded here.

Approver. Every agent result and the call outcome sit on one screen, each with a "Why?". Full bank details appear only here. The "Why?" lets an approver see the reason behind a flag instead of a bare warning, which helps prevent alert fatigue.

Learning from overrides (proposed): When a security reviewer clears a flag or an approver rejects an agent's hold, the approval view would ask for a reason from a short list, with an optional note. The security reviewer and the finance manager review these reasons regularly and decide whether a rule or threshold should change. Agents never retune themselves: every change is made and approved by a person.

Approver. Every agent result and the call outcome sit on one screen, each with a "Why?". Full bank details appear only here. The "Why?" lets an approver see the reason behind a flag instead of a bare warning, which helps prevent alert fatigue.

Learning from overrides (proposed): When a security reviewer clears a flag or an approver rejects an agent's hold, the approval view would ask for a reason from a short list, with an optional note. The security reviewer and the finance manager review these reasons regularly and decide whether a rule or threshold should change. Agents never retune themselves: every change is made and approved by a person.

What I would test next

This is a concept built from desk research, so each choice above is a hypothesis, and the stuck-case timings are my proposal. I would first interview accounts-payable staff, then run each agent's instructions on a real model 3 to 5 times, including a request with hidden instructions, and measure four things, each defined so I can tell whether the design works:

  • False holds. Genuine supplier requests held up by a flag that turned out to be wrong. This is the cost of caution: real suppliers kept waiting.

  • Genuine flags caught. Fake or altered requests stopped before payment, including test cases I plant. This is the reason the system exists.

  • Time to release. Time from request to payment released, for genuine changes. It shows whether safety is slowing real suppliers.

  • Override rate per agent. How often a person clears or reverses each agent's hold. It shows which agent's flags are noisy or weak.

Reflections

Designing for agents is mostly deciding what they may not do. The safest system was not the smartest agent. It was one where any agent could stop a case, and only a person could let it go.

Speed and safety only coexist when every hold has a visible owner and a visible reason.

Results

Results

Results

Reflections

Designing for agents is mostly deciding what they may not do. The safest system was not the smartest agent. It was one where any agent could stop a case, and only a person could let it go.

Speed and safety only coexist when every hold has a visible owner and a visible reason.

Reflections

Designing for agents is mostly deciding what they may not do. The safest system was not the smartest agent. It was one where any agent could stop a case, and only a person could let it go.

Speed and safety only coexist when every hold has a visible owner and a visible reason.

Back