An invoice agent might extract details, match a purchase order, and prepare a draft entry. Before building it, decide which actions it can perform, which need approval, and which it cannot access. Those decisions shape its tools, permissions, and tests.
Map the invoice workflow
Consider a team receiving invoices by email. Staff read each document, find the purchase order, check the amount, resolve discrepancies, and enter the result into a finance system. The proposed agent needs a defined role in that process.
Map each step to its inputs, permitted actions, and accountable person. A model could extract fields from an unfamiliar document. Conventional code could check totals and compare identifiers. A finance specialist could resolve a disputed charge. Use the component that suits each decision.
The first implementation might prepare drafts only. It could flag a mismatch without deciding whether the supplier is right, and it would have no payment access. That is a useful scope with an observable result: whether staff can review and complete invoices more accurately or with less effort.
Give each tool a specific job
A database connection exposes many actions unrelated to invoice handling. A tool such as match_invoice_to_purchase_order can instead accept two identifiers and return the relevant differences. A separate tool can create a draft with validated fields.
Enforce permissions in the tool service and runtime. A prompt telling the agent to create drafts does not prevent payment if its credentials also permit payment. Restrict access to the records and operations needed for the workflow, including reads: supplier and banking information still needs protection.
For each action that changes another system, define retry behaviour. If draft creation times out, the agent needs a stable request reference so the service can identify an existing draft before creating another. Return errors that distinguish a rejected request from an unknown outcome.
Design the review path
Reviewers need the source invoice, proposed entry, matching evidence, and unresolved differences. A confident explanation from the model is insufficient evidence for approval.
Specify which cases always require review. These might include an unknown supplier, a changed bank account, or an amount outside an agreed limit. Enforce those rules independently of the model, and give the reviewer a correction and rejection path.
The design also needs a response when the queue stops moving. Assign an operator who can pause processing, investigate repeated failures, and return work to the manual process. Include a way to correct or remove drafts already created.
Record enough to investigate a mistake
For each run, retain the relevant input references, model and configuration versions, tool calls, approval decisions, and final result. Apply appropriate access and retention controls to this record.
An operator should be able to trace a wrong amount back to extraction, matching, a tool response, or a later edit. Private model reasoning is not required. Observable actions and their supporting evidence are the useful record.
Turn confirmed failures into evaluation cases. A repeated mismatch may require a tool change or better document handling, rather than another instruction in the prompt.
Expand only after testing the next scope
Start by comparing proposed entries with staff decisions without allowing automatic writes. This still requires approved data handling and enough review capacity. Measure field accuracy, missed discrepancies, correction effort, and time spent completing each invoice.
A later release might create drafts automatically for a limited class of exact matches. Test that scope separately, including duplicate requests, unavailable systems, and misleading instructions inside documents. Approval for draft creation does not extend to posting entries or making payments.
A useful design package contains the workflow map, tool permissions, approval rules, evaluation cases, and operating procedure. Together, these let the client team assess the proposed scope before granting the agent access.