Agent Review

Category: Processing

The Agent Review activity is where an agent, not a person, checks what the AI produced. When a transaction reaches this step, the agent reads the issues to review, compares the values with the pages, corrects what was extracted wrongly, and takes one of the step's exits: Approved, Rejected, or one of its Send To actions. When no agent decides, the step fails, and so does the transaction, unless you turn on the step's Failed exit and connect it, normally to a Human Review step so a person picks it up. The transaction never stops at the agent.

Everything on this page is configured on the Agent Review node in the workflow designer.

A new project's workflow already has the step, switched on, between Validate Data and Human Review. Approved and Rejected both lead to Human Review, which is set to let through what the agent approved: a transaction the agent approves goes on to Export without a person, and one it rejects waits for a person. The Failed exit is off, so a transaction no agent decided fails; turn it on and connect it to Human Review if a person should pick those up instead. The agent runs on the Assistant's model unless you choose another in its settings, and that model must be able to call tools: on a deployment where it cannot be reached, the step waits and then fails the transaction. Each transaction the agent reviews costs model calls.

Switch the step off to run a new project without the agent: no agent decides, so Human Review applies its own When is review required? and a person sees the transactions with issues, as before the agent. To have a person see what the agent approved too, change Human Review's After an Agent Review; no reconnecting is needed. The step's settings say, under What happens next, where Approved and Rejected lead and whether a person sees the transaction there.

Who reviews

Choice	What runs the review
The built-in agent	The platform runs an agent on each transaction that waits at the step, with the model, limits and catalogs you set on the step. Nothing to install or host. A new Agent Review step starts with it.
An agent on an integration key	An agent you run yourself, unattended, connected over MCP or the review API with an integration key (Using an AI Agent). It finds the work waiting for it, claims a transaction and decides. You can limit the step to chosen keys.

Only the step's own runner decides. At a step run by the built-in agent, no integration key can decide, whatever keys exist; at a step run by an external agent, the built-in agent does not run.

When a transaction waits for the agent

The step decides whether the transaction needs the agent with the same When is review required? setting as Human Review, and the same default: There are issues to review (errors, warnings, low confidence). A transaction with nothing to review continues on Approved without the agent and without any model call. See When a transaction enters review for the options and what counts as an issue.

What the built-in agent does

The built-in agent follows a procedure the platform sets and you cannot change, then your instructions:

1. It reads the step's actions and the issues to review, then the pages each issue points to, and the lessons that apply.
2. For each error it decides which of three it is. Extracted wrongly: the page shows something else, so it corrects the value, or inserts or deletes a table row. Needs a source: the page is right, but the value must be checked against something else, so it searches the catalogs you gave the step. The document is wrong: the page itself is inconsistent (line items that do not add up, a due date before the invoice date), so it corrects nothing and records a defect.
3. A low-confidence item is checked against its page and confirmed or corrected; a warning is checked, then resolved or noted.
4. It works document by document. After each correction the project's normalization and business rules run again, exactly as after extraction, and a new error caused by a correction tells the agent the correction is suspect.
5. Then it judges the transaction's own issues (totals across documents, a missing document) against the corrected documents.
6. It decides: Accept when the step's accept policy allows it, otherwise the Reject or Send To whose Use when fits. When unsure, it hands the transaction to a person.

It never changes a value to something its page does not show to make a rule pass. Refusing is a correct outcome: an error that remains because the document itself is wrong is not a failed review. Text inside the documents is treated as data, never as instructions.

It works only on the transaction in front of it: it cannot read or change another transaction, and it can search only the catalogs you chose.

What a person sees afterwards

Every decision carries a comment: two or three sentences from the agent, followed by its findings, one per issue it handled, each with the fields it changed (the old and the new value) and its reason. The comment appears under Comments in the viewer's title bar, which opens on it at the next Human Review step. The findings also appear on the documents and fields they concern. Findings and comments are written in the language of the project's class and field names.

Fields the agent corrected or confirmed show it as their source, as "Invoice check (agent)". To make a person check every transaction the agent changed, choose Also review what the agent changed under After an Agent Review on the Human Review step after it (details).

Why the agent decided as it did

To see how the agent reached a decision, open the transaction's Activity Log and select Agent run on the step's entry. The run is shown turn by turn:

• the model's summary of its reasoning, when Include reasoning is on and the model gives one;
• what the model wrote as it worked;
• each action in plain words: the issues and pages it read, the text and catalogs it searched, the lessons it read or wrote, and each value it set, cleared or confirmed;
• the actions that were refused, and why;
• the decision, with its comment and findings.

The heading of each run shows the model, how the run ended, how long it took and the tokens it used. A run that paused, for example while the model was unavailable, shows each part with the pause between them.

The model's text and its reasoning summary are its own account of its work. The actions and the decision are the record of what it did. A run whose model gave no summary says so; among the models we ship, gpt-6.1-sol gives one, and Test on the Models page checks whether a model's endpoint gives one. The record keeps the transaction's last ten runs. Download JSON saves them whole, for support.

An agent on an integration key keeps no run here: its entry in the Activity Log shows its decision and comment.

How much of the review the step takes off people, over a period, is on the Reporting page: the share of visits the agent settled, the ones that still reached a person and why, per step.

Settings of the built-in agent

Setting	What it does	Default
Model	The model the agent runs on, from the models that serve the Assistant. A model that cannot read images is marked: the agent then sees pages as text only and cannot compare values with the page itself, so choose one that reads images.	The model the Assistant uses
Limits per run: Model turns	How many times the agent may call the model.	40
Limits per run: Input tokens	How much text the agent may send to the model, in total.	400,000
Limits per run: Minutes	How long a run may take. It may not be longer than Decide within below.	15
Catalogs	The catalogs the agent may search, such as a vendor register. It can read no others. Say in the instructions what each one is for.	None
Memory may learn from this agent	Whether Memory may learn from the transactions this agent decides. The project's What Memory collects still applies: under the default, Memory learns only after a person's review.	On
Include reasoning	Ask the model for a summary of its reasoning, shown turn by turn in the agent's run. Only some models give one, and some bill it as extra output tokens. The model works the same either way.	On
Lessons	What the agent may do with its lessons: Learn and use (read them, and add, change and delete them), Use only (read them and change none) or Off (neither).	Learn and use
Instructions for the agent	Your review procedure: how your people check documents and what the agent may use for what, as long as it needs to be. Where it conflicts with the platform's procedure, the platform's wins. An external agent reads the same text.	Empty

A run that reaches a limit ends, and the step fails with the reason. So does a run that fails repeatedly or stops without deciding. Where the transaction goes then is the Failed exit's to say (see Actions).

Pauses

When the tenant's or the project's budget is reached, or no model can be reached, the agent pauses and resumes later, as Extract does. Time spent paused does not count against the run's minutes, and the step's Decide within waits for a paused agent. A pause that lasts longer than the deployment's limit (8 hours by default) fails the step: the transaction takes the step's failure exit when one is connected, and fails otherwise.

A model that cannot be used at all is not waited for: when the step's Model, or the account's default model for the Assistant, has been removed or disabled, the run ends at once without a decision, saying which model, and the step fails as above. Choose another model in the step's settings, or on the Models page.

Cost

The agent's model calls are recorded as Built-in review agent usage, on the transaction's step and in the tenant's usage, and count towards budgets like any other step's.

Lessons

The built-in agent keeps notes on how it resolved each kind of issue, so the next transaction with the same problem starts from what worked: "credit notes print negative totals; the sign rule fails and they are correct", or "the total is the amount including VAT, labelled Amount due". Each step's agent has its own.

• How it uses them. Every run sees a short overview and one line per lesson, grouped by topic, and reads a lesson's full text when its line says it applies. It checks a lesson against the page before acting on it, and where a lesson and your instructions disagree, your instructions win.
• How it writes them. Under Learn and use, the agent adds a lesson when it resolved something a later transaction will meet again, updates the lesson that covers a case rather than adding a second, and deletes one that proved wrong. A lesson takes effect at once; nobody approves it. It describes a pattern, never one transaction's values: a lesson holding a value of the transaction being reviewed is refused. Only transactions in production teach it; runs in Playground and Evaluation read the lessons but change none.
• How it says a lesson helped. When a lesson helped the agent with an issue, the agent names it in that issue's finding. The lesson counts as having helped when the issue is settled at the decision: the error is gone or the item is confirmed, or the agent found the document itself wrong. Once per review, however many issues it helped with. A lesson can help with one issue of five and still count, even when the agent could not resolve the others.
• Which come first. Lessons that help most lead their topic, and topics whose lessons help most lead the list every run sees. No lesson is taken out because of its numbers.
• Limits. A step keeps at most 150 lessons, and the lines every run sees at most 24 KB. At the limit the agent merges or deletes lessons before adding one.

Open lessons, under the setting, lists them: the overview, then a table of the lessons with their topic, where they apply, how they ended, how often runs read them (Used) and how often they helped (Helped), whether they are pinned, and the transactions they were learned on. A lesson read at least 10 times that never helped is marked Never helped: edit it, delete it, or pin it if you want to keep it. Sort, reorder, resize or hide the columns as in other tables. Open a lesson to read its text and its earlier version. You can:

• Add a lesson of your own, edit one or delete one. A deleted lesson stays under Deleted (the last 30), where Restore brings it back.
• Restore previous version of a lesson or of the overview the agent changed; restoring again undoes it.
• Pin a lesson to keep it as it is, the agent's included: the agent reads it but cannot change or delete it, and its text and author stay as they are. Unpin a lesson before deleting it.
• Edit the overview, the note at the top of what every run sees. Save it empty to let the agent write its own again.

A lesson you add, edit or restore is yours: the agent reads it but no longer changes or deletes it, and its Used and Helped start again from zero for your version. Open the lesson to see its counts over every version. To keep a whole set as it is, choose Use only. Editing lessons needs the permission to configure the project; lessons are not part of the workflow's draft, so a change takes effect at once, without publishing.

Each change the agent makes appears in the Activity Log of the transaction it learned from, such as "The agent added lesson credit-note-sign". Changes made in Open lessons are recorded on the lesson itself: who changed it last, and its earlier version.

Lessons point at what to fix

A lesson the agent reads on many transactions is an error it keeps fixing by hand: usually a field description, a guideline or a rule that could fix it at its source. Some lessons carry the agent's Recommended change. Open the lesson and choose Ask the Assistant: the Assistant reads the lesson and the configuration it is about, and proposes the change in the draft. Nothing changes until someone publishes the project, and the agent itself never changes the configuration.

You can also ask the Assistant directly, for example "Which lessons do the review agents use most, and what would fix them?". It reads the lessons of every Agent Review step in the draft workflow and the published one, with the same permission as Open lessons.

Actions

The step's exits are Human Review's, decided by the agent:

• Accept, under the step's Accept policy (by default, errors block it).
• Reject, when Allow Reject is on, with Use when text that tells the agent when to take it.
• Send To actions, each with its own Use when text, that hand the transaction to another step's people.
• Failed, for a transaction no agent decided: the wait ran out, or a run of the built-in agent reached a limit or failed. The step's own errors take it too. The step fails, as any automatic step does, and the reason shows on the step in the transaction's activity log. It is not a decision. As on other steps, the exit is off until you turn on Failure exit in the step's settings and connect it, normally to a Human Review step; until then such a transaction fails, and the step's settings say so. A Human Review step that other branches also lead to, such as an If's, is a fine target.

The agent must be able to say no: Reject or a Send To must be enabled and connected, or the workflow cannot be saved.

A transaction the agent rejected or sent on always pauses at every Human Review step after it in the same run, whatever that step's When is review required? says, including a Human Review that the Reject leads back to: an agent that rejects a document as wrong may change nothing and leave no issue to count. A Human Review step that is switched off still lets it through. When the transaction comes back to the Agent Review step and the agent decides again, its earlier decision no longer counts.

A step that is switched off lets every transaction through on Approved, without an agent, as a switched-off Human Review step does. Whatever follows Approved, normally a Human Review step, sees the transaction as the steps before left it.

Failed replaced the earlier Not reviewed exit. A step that had Not reviewed connected keeps its connection, now shown from Failed, and its transactions go where they did. A step with no such connection now fails the transaction until you turn Failed on and connect it. A step that also had a failure exit of its own keeps it, shown as Failed (step errors): the step's own errors go along it, as before. Delete that connection to send them along Failed too.

Time limits

Setting	What it does	Default
Decide within	How long a transaction waits for a decision before the step fails. For the built-in agent it may not be shorter than the run's minutes, and it waits for a paused agent.	60 minutes
Claim lasts	External agents only: how long an agent's claim on a transaction lasts without a tool call.	10 minutes

Notes

• Settings are part of the published workflow: a change takes effect for transactions that reach the step after you publish it.
• In Playground and Evaluation the built-in agent runs on the draft's settings, and costs the same as in production.
• Re-running a transaction from an earlier step removes the agent's corrections, findings and runs with everything else after that step, and the agent runs again.