Start with staff-reviewed draft preparation. Consider autonomous submission only for a separately authorised, narrowly defined purchasing process with enforceable limits, current commercial checks and reliable outcome verification. The deciding question is whether the workflow can prove what was approved, prevent a changed order from slipping through and resolve uncertain submissions without creating duplicates. A successful drafting pilot alone does not answer those questions.
Locate the purchasing commitment before choosing scope
Walk through the actual portal with the procurement owner. Identify what saving, continuing, approving and submitting each does. Check whether an order is sent to the supplier, enters an internal approval queue or remains an editable draft. Record the observed behaviour alongside the owner’s interpretation of the commitment boundary; button labels are insufficient evidence.
Distinguish three scopes: preparing a draft, submitting an individually approved order, and submitting under standing purchasing authority. The second still includes a human purchasing decision. The third requires an agreed rule covering eligible purchases and exceptions. Decide explicitly which scope is being evaluated before judging an agent demonstration.
If the portal has no genuine unsubmitted draft, prepare a separate review worksheet instead. If the effect of submission or cancellation is unclear, the procurement owner should obtain the relevant commercial or specialist interpretation. A browser demonstration cannot establish contractual consequences or a person’s purchasing authority.
Prepare a draft that a buyer can actually review
Use an approved requirement brief with product identity, quantity, purchasing unit, destination and required delivery details. Preserve its version and approval reference. Separate confirmed requirements from suggestions: a message saying “perhaps order extra” should appear as an unresolved question rather than an additional line.
The review pack should compare requested and observed values line by line. Include supplier identity, product code, pack size, quantity, currency, displayed charges, delivery destination and the current draft reference. Inspect the complete cart, including rows already present. Mark unavailable information as missing; do not turn an empty delivery field into a guessed address.
OpenAI documents schema-constrained output through Structured Outputs. A proposed implementation could use that capability to organise the review pack consistently; the structure itself does not verify the catalogue match or commercial facts. Compare populated fields with their supporting evidence. Source: OpenAI Structured Outputs
Bind the decision to current prices and terms
Review the full purchasing proposition, including quantities, pack sizes, delivery charges and relevant terms. A matching product description is insufficient if the purchasing unit differs. Show the buyer the original requirement, the current portal value and the practical consequence of each discrepancy, such as ordering more stock than requested.
Tie approval to a specific draft version and its reviewed values. A general “go ahead” message should not authorise later substitutions or changed destinations. As a proposed initial rule, any commercial change returns the draft to review. A business can later define narrower tolerances, but those limits must come from its purchasing policy.
Re-read the relevant values immediately before submission. If the portal changes them between review and commitment, establish whether the implementation can detect and block that change. Where it cannot, keep final submission with staff who can inspect the live screen. A saved screenshot does not freeze the supplier’s offer.
Compare reviewed submission with autonomous submission
OpenAI’s function-calling documentation distinguishes a model’s request to use a function from the application executing that function. This supports a design in which the application checks purchasing authority before allowing an action. It does not establish that an arbitrary browser portal offers a controllable submission boundary. Source: OpenAI function calling
n8n documents human review for selected agent tools: the workflow pauses, presents the proposed tool input and executes or cancels according to the reviewer’s decision. That can support an individually reviewed submission design. The implementation must still show the actual order details and route the decision to an authorised buyer. Source: n8n human review for AI tools
For autonomous submission, write a purchasing envelope: permitted suppliers and products, quantity rules, spending limits, destinations, commercial tolerances and exclusions. These are proposed controls, not native procurement features established by the documentation. Identify who grants that authority and how it can be withdrawn. Check current product, account, plan and region eligibility before deployment.
Evaluate the envelope against difficult examples, not just routine success. Can the workflow block an excluded item, detect a changed total, refuse an expired approval and identify an existing order? Record failures and their handling. Broader scope is defensible only where these conditions are enforceable in the actual workflow; otherwise retain reviewed submission or draft-only preparation.
Reusable staged procurement-automation scope
Copy the following template for one portal and purchasing process. Enter a person or accountable role in every owner field. Record an explicit “not applicable” where appropriate, rather than leaving gaps that another team member must interpret. The proposed starting scope keeps submission with staff.
Staged procurement-automation scope
Workflow/portal/account: ______ | Procurement owner: ______
Scope selected: draft only / individually reviewed submission / standing-authority submission
Approved requirement brief/version: ______ | Authority reference and limits: ______
Current draft reference/version: ______ | Reviewed values captured at: ______
| Stage and proposed action | Stage owner | Observed evidence/reference | Decision or approval reference | Unresolved status/next handoff |
|---|---|---|---|---|
| Requirements: organise approved items, quantities, units and destination | ______ | Brief/version: ______ | Requirement approval: ______ | Missing facts and receiving owner: ______ |
| Supplier inspection: read product identity and current commercial details | ______ | Catalogue/quote reference and capture time: ______ | Supplier/item acceptance: ______ | Unavailable or ambiguous values and receiving owner: ______ |
| Draft preparation: populate only a verified unsubmitted draft | ______ | Draft reference/version and complete line comparison: ______ | Preparation permission: ______ | Extra rows or mismatches and receiving owner: ______ |
| Discrepancy review: present changed prices, units, items, destination or terms | ______ | Before/after values and supporting references: ______ | Revised brief approval or rejection: ______ | Outstanding decision and receiving owner: ______ |
| Pre-commit check: compare live values with the authorised draft | ______ | Current draft/version, totals, terms and duplicate check: ______ | Exact-order approval or standing-authority rule: ______ | Failed check and receiving owner: ______ |
| Submission: authorised staff submit in the initial scope | ______ | Attempt time and available submission reference: ______ | Buyer decision tied to draft/version: ______ | Uncertain attempt and reconciliation owner: ______ |
| Verification: inspect authoritative order state and reconcile uncertainty | ______ | Order/status reference, observed values and check time: ______ | Accepted/rejected/pending determination: ______ | Next check, due time and receiving owner: ______ |
Reconciliation closure: original attempt/reference ______; final observed state/evidence ______; duplicate check ______; owner ______; closure decision/time ______.
Later expansion decision: permitted submission envelope ______; enforced controls and test evidence ______; authority owner/reference ______; exceptions retaining human submission ______.
Worked cases: ordinary, missing, ambiguous and duplicate
All quantities and amounts in these examples are hypothetical. An office requests ten packs of a specified stationery item. The approved brief and portal agree on product code, pack size, destination and a displayed total of R1,200. The agent prepares the draft and records the comparison. The buyer reviews that exact version, submits it and checks the resulting order reference.
In a missing-information case, the same brief lacks a delivery destination. The agent prepares only what the permitted workflow allows and marks the destination unresolved. The named requester supplies the correct address; the buyer reviews the updated draft. Selecting the account’s default address without confirmation would conceal a missing purchasing decision.
In an ambiguous case, the catalogue contains similarly named packs with different unit counts, while the requester claims verbal approval. The agent records both candidate codes and the missing authority reference. The procurement owner resolves the product and confirms acceptable approval evidence. Neither a plausible match nor the requester’s confidence closes those questions.
In a duplicate case, the cart already contains the ten packs from an earlier attempt. The agent compares existing rows before adding anything. Staff determine whether to reuse that draft or correct it. If a submitted order might already exist, reconciliation moves to the order history; deleting a cart row cannot resolve an uncertain supplier commitment.
Assign and close uncertain submission outcomes
A timeout after submission creates an unresolved attempt, not permission to click again. Record the attempted draft version, time, observed response and available reference. Assign a reconciliation owner who checks the authoritative portal record or follows the supplier’s accepted enquiry route. Keep further submission for that requirement held while the outcome remains uncertain.
Define closure evidence before live use. An accepted outcome needs a matching order record and relevant details. A rejected outcome needs evidence that the attempt did not create an order. Pending remains open with a next check and responsible person. Where evidence conflicts, the procurement owner decides the next investigation rather than the agent selecting the most convenient interpretation.
Handoffs should identify the receiving owner, outstanding question and next check time. Close the record only when the outcome and duplicate check are documented. If another submission is authorised, link it to the original unresolved attempt and the reconciliation decision. This makes the second action explainable without treating the first attempt as though it never happened.
FAQ about browser-agent purchase orders
Does approving a draft authorise the agent to submit it?
Only if the approval explicitly includes that action under the accepted process. Otherwise the draft remains ready for staff submission. Record the authorised actor, exact draft version and any conditions attached to the decision.
Can routine orders use standing authority instead of individual approval?
Potentially, within a separately approved purchasing envelope whose rules the implementation can enforce. Keep exceptions with staff. Evidence from preparing routine drafts does not demonstrate that submission limits or uncertain-outcome handling work.
Who takes over when the portal gives no clear submission result?
The named reconciliation owner takes over, preserves the attempt evidence and checks actual order state. The purchasing owner decides any further commitment once uncertainty is resolved. An agent’s summary alone should not close the case.
If your business needs help choosing this scope, explore Custom AI agents within our AI automation services. The custom-agent workflow guide, agents versus automation comparison and custom AI agent glossary explain the wider options. To discuss your purchasing boundary and handoffs, get in touch.