An AI agent that pays suppliers, and a human who is actually in charge of it.

The situation

A finance team has an AI agent that drafts supplier payments: it reads invoices, matches them to purchase orders, and proposes a batch to pay. That is useful. It is also the exact kind of action the Human Gate exists for: money is about to leave the company, and the question every board eventually asks is simple. Who said yes?

Before a Human Gate, the honest answer is often "the agent, and nobody checked." A log entry that an agent wrote about itself is not evidence a human was in charge. This example shows how one implementation makes the answer checkable instead of assumed.

How it gets put in place

This is one reference implementation of the standard, the approach FLOCORE uses, laid over the finance team's existing accounting system. The standard itself does not mandate this exact mechanism, any conformant implementation can decide its own way to work out who the right approver is. This is a concrete example of one way that works well.

1. The organogram goes in. The finance team's existing role-based org chart, reporting lines and all, is read once. Nothing about the org chart is redesigned for this: it is used as it already exists.
2. The job descriptions go in. Each role's actual written authority, a Financial Controller can approve up to a stated amount, a CFO above it, is read from the job descriptions already on file. This is what turns "someone in finance" into a named, authorized approver for a specific action.
3. The gate sits above the accounting system, not inside it. Nothing in the existing payment platform is replaced, rewritten, or ripped out. The gate watches for one thing: a world-affecting action about to run, and holds it.
4. The agent's proposal is routed to the right human. Not a shared inbox, not whoever is free, the named person the organogram and the job description say actually has authority over a payment of that size.
5. That person approves or refuses, having seen the real context. The approval is signed at that moment: who, the exact action bound by a content hash, and when. That signed receipt is the Human Seal.
6. The dashboard updates itself. Because every approval already carries who, what, and when, a per-role KPI view falls out for free: how many payments this Controller approved this month, how fast, how many were refused. Nobody has to build that separately, it is the same data the receipt already recorded.

What this gets you on day one

What this example is not claiming

See the rest

This is one example, at Level 2 and pointed toward Level 3. The full mechanics, including how present-human step-up and dual control work for the highest-risk actions, are in the standard and the levels.