Where to put the human reviewer when an agent runs in a client's finance department

Picture your first week at a client’s office. The agent that reads invoices already works on sample data. Then the chief accountant asks a question that has nothing to do with the model: “If it posts a wrong journal entry, who signs off?”

On finance projects, questions like that decide whether an agent reaches production. CrossCountry Consulting describes itself as a transformation partner to the Office of the CFO, the finance function of a business.

So the firm’s FDEs work mainly with the client’s finance and operations teams. Its posting for a Forward Deployed Engineer & Agentic Workflow Engineer sets out a very specific requirement: design HITL/HOTL control points proportionate to the risk and materiality of each workflow step.

This skill sits outside prompt writing and model selection: knowing where to put people in a process that involves money and audits. And it can be learned, if you practise on a concrete workflow.

Clients ask about accountability first, the model second

CrossCountry describes its approach to AI as putting process before technology, and its services run from pilot to production, including orchestrating multiple agents. That order has a reason. In a finance department, the real product is a process the auditors can accept. The agent is only one part of it.

The time pressure is also real. The posting asks FDEs to deliver the AI Jumpstart package within the first week of an engagement. These are small, fast deployments that create value immediately, without large upfront investment or complex infrastructure changes.

With only a week, you cannot wait for auditors to approve every line of code. The control design has to exist from day one and be clear enough for people outside software to understand.

HITL makes the workflow wait, HOTL lets it run

With HITL, the workflow stops completely and waits. The agent proposes, a person clicks approve, and only then does the next step run. With HOTL, the agent carries on by itself. A person watches through a dashboard or alerts and has the power to stop it when something looks wrong.

The two differ in cost. HITL is safe but consumes people’s time and slows the process. Put HITL on every step and you have simply rebuilt the old manual process with a few extra button clicks. HOTL is fast, but it only fits when an error can be detected and corrected before it does harm.

So the question to ask of each step has two parts. How serious are the consequences if this goes wrong (materiality)? And can it be fixed, before the money leaves or the numbers reach a report?

Scoring each step of an accounts payable workflow

Take a hypothetical example familiar to any finance team: processing supplier invoices. Break the workflow into steps, then score each one against the two questions above.

Step	Risk if wrong	Reversible?	Control level
Agent reads the invoice, extracts amount, supplier, date	Wrong input data	Yes, before posting	Automated, with format checks
Match against the purchase order and goods receipt note	Approving a mismatched invoice	Yes	HOTL: runs on its own, alerts on discrepancies
Propose the general ledger account	Wrong account, misstated reports	Yes, but costly once the books are closed	HOTL below the threshold, HITL above it
New supplier or changed bank account number	Paying a fraudster	Almost never	Mandatory HITL, two approvers
Payment order	The money has gone	No	HITL for every order

The table shows two things. The control level can change within a single step, depending on transaction value, and that threshold must be set by the client’s controller, not by you. And the riskiest step is not where the AI is most likely to err.

Reading invoices is where the model makes mistakes most often, but errors there can be fixed. Changing a bank account number is a simple operation, but get it wrong once and the money cannot be recovered.

Each HITL point needs two more things, or the auditors will dismiss it. First, the reviewer must see enough evidence: the original invoice, the matching purchase order line, and the agent’s reason for its proposal.

Second, a log recording who approved, when, and what they saw. As the number of agents grows, CrossCountry uses its own CrossCoreAI platform to orchestrate, monitor and govern them. Whatever tool you use, you still need to work out in advance what will be monitored.

Five to seven people sign one control table

According to CrossCountry, AI governance requires coordination among 5-7 stakeholders. For an FDE, that number means the table above has to pass through several people with different concerns: finance wants a fast process, IT worries about system access, auditors need a trail.

What works is to show them the control table before the demo. The “Control level” column is the one they will argue over most, and it is better that they argue early. If the auditors want the matching step moved from HOTL to HITL, you change one row in the table, not rewrite the agent.

The role also requires being there in person. The posting lists domestic travel of 20%–40%, depending on the phase of the client engagement. Sitting next to an accountant processing invoices for an afternoon tells you more about real risk than any process document.

Three mistakes that get a design sent back

The most common mistake is scoring risk by technical difficulty rather than by business consequence. Engineers tend to put controls where the model is weak and overlook simple but irreversible operations, such as payments or changes to supplier master data.

The second is setting the materiality threshold yourself. That threshold belongs to the client’s internal control policy. Your job is to make it a configurable parameter, then ask the right person for the number.

The third is treating HITL as an “OK” button. If the reviewer sees only a one-line summary, they will approve everything by reflex, and the control exists only on paper. A good HITL point gives the reviewer enough information to say no.

How to put this skill on your CV

CrossCountry may hire for this role at Manager or Associate Director level. That makes it a senior role, and the hiring team wants to see judgement, not just code.

When you read FDE postings in finance, insurance or healthcare, look out for phrases such as “human-in-the-loop”, “governance” and “materiality”. When you see them, have a control design example ready to bring to the interview.

On your CV, do not just write “built an invoice processing agent”. Write how many steps the workflow had, how many control points, which steps moved from manual to HOTL, and who on the client side signed off. In the interview, bring a table like the one above and explain why you put HITL on the payment row and not on the invoice reading row.

In a finance department, an agent is trusted not because it never makes mistakes. It is trusted because everyone knows where an error will be stopped when it does.