AI agent workflows for Web form filling & back-office data entry

Build spec

2 agents — 1 economy line extractor (once per line, via the Loop node) + 1 premium arbiter (only on flagged lines). The form-filling itself is a Tool (MCP) node against a browser-automation server, not an agent capability. · Pattern: Loop (per line) → economy extract → Code validates arithmetic → Condition escalates only flagged rows → premium arbiter → MCP browser fills the draft → human submits

System prompt (paste-ready)

You extract ONE invoice line into strict JSON: {code, description, qty (number), unitPrice (number), lineTotal (number), taxCode, confidence (0-1), issue|null}. Use ONLY this line and the field map from Knowledge. Never infer a missing tax code from what is typical — leave it null and set a low confidence. Never round, never re-compute a total to make it agree, and never carry a value down from the line above. If the line is a credit, a discount or a header row rather than a chargeable item, say so in `issue` and do not force it into the item schema. You prepare a draft only: you never submit anything, and you never enter a password, card number or government ID into any field.

Agent roles & model tiers

• Line extractor (per line) — Economy tier — 400 lines means 400 invocations; this single tier choice dominates the cost of the entire job

  One line → schema-valid JSON against the Knowledge field map. Nulls plus low confidence instead of plausible guesses. No arithmetic reconciliation, no value carried over from the previous line.

• Ambiguity arbiter (flagged lines only) — Premium tier — affordable precisely because it sees the handful of unclear rows rather than the full invoice

  Resolve one flagged line using the full invoice context and the coding rules. If it remains genuinely unclear, return NEEDS_HUMAN with the specific question — an honest escalation is cheaper than a wrong line in a submitted invoice.

Guardrails

• No agent ever types a password, card number, bank detail or government ID into a form. The portal login is performed by the human approver, or by a secrets-managed integration under your own account — credentials are never placed in a prompt, a field map, or an agent's reach
• Every submission goes through the Approval node. The browser-automation MCP is scoped to fill fields only; the irreversible submit control is clicked by a person looking at a field-by-field diff against the source invoice
• This portal is your own customer relationship, accessed under access you legitimately hold and within its Terms of Service — automation is used where the portal permits it, and where it does not, the workflow stops at the prepared draft for manual keying
• Rate-limited and honestly identified: the browser session paces its interactions, backs off on errors, and does not retry in a tight loop against a live portal
• No bot-detection bypass and CAPTCHAs are NEVER solved — a challenge hands the session to the human approver, who completes it themselves; the workflow waits rather than working around it
• No personal data harvesting: only the invoice fields the portal requires are processed, nothing about individuals is retained beyond the record, and the extracted payload is not reused for any other purpose
• Arithmetic is computed in the Code node, never accepted from a model, and the invoice total must reconcile before the draft can reach the Approval node at all
• Idempotent per invoice id — a resent email or a retried run never produces a second draft, and the submitted reference is written back once
• The SpEL user-defined tools are data-transform expressions over the tool's JSON input — no method calls, no constructors, no bean/type references, no loops in the grammar — so an AP lead encoding their own tolerance band writes a formula, not code, and it cannot become an execution risk

Cost strategy

This is the volume case that makes cost tiering obvious: 400 lines on a premium model is an absurd bill for what is fundamentally field-lifting off a structured document. Economy tier on the per-line extractor, deterministic arithmetic in the Code node (free), and the premium model reserved for the dozen rows the tolerance and confidence flags actually raise. Cap the extractor's output tokens — the per-line schema is tiny — and set a per-invoice budget so a scanned document that OCRs into noise fails loudly instead of burning through 400 expensive calls.

Output & delivery

The Loop extracts every line with the economy model → the Code node reconciles totals and the SpEL flags fire → the Condition node sends only flagged rows to the premium arbiter → a Tool (MCP) node drives the browser-automation server to fill the portal form and stops before submit → the human approver checks the field-by-field diff and clicks submit themselves → an Output node writes the reference, approver and timestamp back to the AP system and notifies on Email or Slack.

Build spec

2 agents — 1 economy mapper, invoked once per target system by the Parallel node, + 1 premium escalation reviewer that runs only when a required field could not be mapped. Normalisation is a Code node, validation is Knowledge plus Condition, and the writes are http_request or a browser-automation MCP tool call — none of that is an agent. · Pattern: Code normalise → Parallel per target → economy mapper per target → Condition holds unmappable records → single Approval → API or MCP-browser writes

System prompt (paste-ready)

Map ONE canonical customer record into ONE target system's payload, using only that system's field map and allowed values from Knowledge. Return {payload, unmapped[] (required target fields you could NOT fill with certainty), notes}. Never invent a value to satisfy a required field, never pick an allowed value because it looks close, and never reformat a value in a way the field map does not specify — normalisation already happened upstream. You prepare a payload only: you do not write it, you do not submit it, and you never enter a password, card number or government ID into any field.

Agent roles & model tiers

• Target mapper (once per target system) — Economy tier — mapping a normalised record onto a documented field map is mechanical; volume here is per-record × per-system, so cheap matters

  One canonical record + one field map → one target payload plus an explicit unmapped[] list. No invented values, no near-enough enum matches, no re-normalising.

• Escalation reviewer (only when unmapped[] is non-empty) — Premium tier — invoked only for the genuinely ambiguous record, e.g. a legal entity type with no clean equivalent in the target's enum

  Given the canonical record and the target's allowed values, propose the correct mapping with a one-line justification, or return NEEDS_HUMAN. Never widen an enum or invent a category.

Guardrails

• No agent ever types a password, card number, bank detail or government ID into a form. Each target system is reached with access you legitimately hold — a documented API using secrets-managed credentials, or a session a human opened — and credentials never appear in a prompt or a field map
• Every submission goes through the Approval node. The browser-automation MCP is scoped to fill fields; the irreversible submit or save is a human action taken against a side-by-side diff of all three prepared records
• These are your own systems, used within their Terms of Service and under legitimate access; where a vendor's terms prohibit UI automation, the API path is used or the record is prepared for manual entry
• Rate-limited and honestly identified against every target — batched syncs pace their writes and back off on errors rather than retrying in a loop
• No bot-detection bypass and CAPTCHAs are NEVER solved — a challenge on a target's UI hands the session to the human approver rather than being worked around
• Minimum necessary personal data: only the fields each target actually requires are mapped into it, the canonical payload is not retained beyond the run, and no profile is assembled across systems
• No invented values — an unfillable required field puts the whole target on hold at the Condition node instead of being satisfied with a plausible placeholder
• Idempotent per source record id and version, so a replayed Webhook updates rather than duplicating, and a partial failure is reported as an open item rather than leaving a silent gap
• The SpEL user-defined tools are data-transform expressions over the tool's JSON input — no method calls, no constructors, no bean/type refs, no loops in the grammar — so an ops lead writing their own completeness or field-shape rule produces a value, never behaviour

Cost strategy

Per-record cost is (number of targets) × economy mapper, with the premium tier reserved for the record that genuinely does not map — an unusual entity type, a country the target's enum does not carry. At three targets per record and a steady onboarding flow, putting a premium model on the mapping step multiplies the bill for work that is deterministic lookup against a documented field map. The Parallel node cuts wall-clock without changing per-target cost, and the Code-node normalisation is free — doing it there rather than asking a model to normalise is itself a cost decision.

Output & delivery

A Code node canonicalises the incoming record → the Parallel node prepares all three target payloads with the economy mapper → the Condition node holds any target with unmapped required fields → one Approval shows all three side by side against the canonical source → on approval, `http_request` writes to API-backed targets while a Tool (MCP) node drives the browser-automation server for UI-only ones, stopping short of submit for the human → an Output node reports the three target ids and any rejection to Slack.

Build spec

2 agents — 1 economy per-page extractor (via the Loop node) + 1 premium re-reader (only on fields below the confidence floor). Form filling is a Tool (MCP) node against a browser-automation server, not an agent capability. · Pattern: Loop (per page) → economy extract with per-field confidence → Knowledge validation → Condition splits on the team's SpEL threshold → premium re-read of doubtful fields only → MCP browser fills confident fields → human completes and submits

System prompt (paste-ready)

Extract ONE page of a scanned form into strict JSON: one entry per field as {field, value|null, confidence (0-1), issue|null}, using only the field spec from Knowledge. If a value is unclear, smudged, ambiguously ticked or handwritten in a way you cannot read with certainty, set value=null with a low confidence and describe the problem — a blank flagged field is CORRECT and a plausible guess is a defect. Never normalise a value the spec does not define, never complete a partially-visible number, and never infer a field from another field. Do NOT extract or transcribe passwords, full card numbers, or government ID numbers into the draft payload: mark those fields HUMAN_ENTRY_REQUIRED so a person enters them directly. You prepare a draft only and never submit.

Agent roles & model tiers

• Page extractor (per page) — Economy tier — the per-page volume step; on a daily intake backlog this tier choice is the difference between viable and absurd

  One page → per-field JSON with honest per-field confidence. Null plus a reason beats a guess. Sensitive identifiers are marked HUMAN_ENTRY_REQUIRED, never transcribed.

• Doubtful-field re-reader — Premium tier — runs on a few fields per form, not every field of every page, which is exactly what makes premium affordable here

  Re-read only the flagged fields with full page context. Return a value only at high confidence; otherwise return NEEDS_HUMAN with the specific difficulty. Never resolve ambiguity by choosing the more common option.

Guardrails

• No agent ever types — or even transcribes into the draft — a password, card number, bank detail or government ID. Those fields are marked HUMAN_ENTRY_REQUIRED and entered by the operator directly, or supplied by a secrets-managed integration; they never pass through a prompt
• Every submission goes through the Approval node. The browser-automation MCP fills fields only; the irreversible submit is clicked by the operator with the scan open beside the draft
• Access is legitimate and within Terms of Service: this is your own internal portal and your own applicants' forms, entered under access you hold. Where UI automation is not permitted, the flow stops at the structured draft for manual keying
• Rate-limited, paced and honestly identified against the portal; failures back off instead of retrying in a tight loop
• No bot-detection bypass and CAPTCHAs are NEVER solved — a challenge is handed to the operator, who completes it in their own session
• Personal data is handled on a minimum-necessary basis: fields are used for this application only, the scan and payload are retained under your existing retention policy, and nothing is compiled into a profile or reused for another purpose
• Low-confidence fields are left BLANK and highlighted, never auto-filled — the flow's core rule is that a missing field is safe and a confidently-wrong field is not
• Idempotent per document id, so a re-sent scan updates the existing draft instead of creating a duplicate application
• The SpEL user-defined tools are data-transform expressions over the tool's JSON input, with no method calls, constructors, bean/type references or loops in the grammar — the ops lead's own confidence floor is a formula that computes a value and can never become executable behaviour

Cost strategy

Pages are the volume unit, so the per-page extractor sits on the economy tier and everything else follows from that. The premium model is scoped to the fields that failed the confidence floor — typically a few per form — which means the expensive tier scales with document difficulty rather than with intake volume. Cap output tokens per page (the field schema is fixed) and set a per-document budget so a badly-scanned batch fails visibly rather than quietly re-reading every field at premium tier.

Output & delivery

The Loop extracts each page with the economy model → Knowledge validates against the form spec → the Condition node applies the team's SpEL confidence floor → the premium re-reader takes only the doubtful fields → a Tool (MCP) node drives the browser-automation server to fill the confident fields and leave flagged ones blank → the operator completes the highlighted fields, enters any sensitive identifiers themselves, and submits at the Approval node → an Output node acknowledges to the applicant with the reference while a Tool (MCP) node files the record with the scan.

Build spec

2 agents — 1 draft-assembly agent (once per period) + 1 premium anomaly reviewer that runs only on a flagged item. Neither ever computes a filing figure — all arithmetic is a Code node. The reconciliation gate, the form filling and the filing approval are workflow nodes and MCP tool calls. · Pattern: Code computes → Knowledge grounds the current form spec → agent assembles the draft and working papers → hard reconciliation gate → MCP browser fills the portal draft → authorised signatory files

System prompt (paste-ready)

You assemble a statutory return DRAFT from figures that have ALREADY been computed. You must never calculate, adjust, round or reconcile a figure yourself — use the supplied values exactly, and if a required value is absent, report it as missing rather than deriving it. Map figures onto the return's schedules using ONLY the current form specification from Knowledge, write a plain-language working-paper note per schedule, and list every assumption relied upon. Flag any figure that looks inconsistent with the prior period rather than adjusting it. You never file, never enter credentials or a signing token, and never present the draft as submitted. Output {schedules[], workingNotes[], assumptions[], missing[], anomalies[]}.

Agent roles & model tiers

• Draft assembler — Standard tier — one careful pass per period over pre-computed figures; the reasoning is in the mapping and the narrative, not in the arithmetic

  Map computed figures onto the current schedules, write working notes, list assumptions, flag prior-period inconsistencies. Never compute, never adjust, never file.

• Anomaly reviewer (only when the gate or the agent flags something) — Premium tier — invoked only for the genuinely ambiguous case, such as a movement with no obvious ledger explanation

  Given the flagged item, the ledger extract and the prior period, explain the most likely cause and what evidence would confirm it. Never propose a figure change — the outcome is a question for the preparer, not an adjustment.

Guardrails

• No agent ever types a password, digital-signature token, card number or government ID. The authorised signatory logs into the portal themselves in their own session; where credentials are needed for a read-only ledger pull, they come from a secrets-managed integration and never enter a prompt
• Every submission goes through the Approval node — and here the submit is a legal act, so it is performed by the named authorised person against the figure-by-figure tie-back, never by the workflow. The browser-automation MCP fills the draft and stops
• Legitimate access and Terms of Service: this is your own filing under your own credentials, and where the portal's terms do not permit automated interaction the workflow delivers the reconciled draft for manual keying instead
• Rate-limited, paced and honestly identified; no tight retry loops against a government or regulator portal, ever
• No bot-detection bypass and CAPTCHAs are NEVER solved — a challenge is completed by the signatory in their own session, which is also the correct control for a filing
• No personal data harvesting: only the return's required fields are processed, retained under your statutory retention policy, and never reused for another purpose
• No model-computed figures. Every number on the return comes from the Code node, the reconciliation gate must pass before a human is shown a draft, and a flagged anomaly is raised as a question rather than adjusted away
• Idempotent per period and return type — a re-run regenerates the draft rather than creating a second filing, and the archived pack records the approver and timestamp for audit
• The SpEL user-defined tools are data-transform expressions over the tool's JSON input — no method calls, no constructors, no bean/type references, no loops in the grammar — so a controller setting their own tolerance or materiality band writes a formula that computes a value and cannot become an execution risk

Cost strategy

Volume is low here — one return per period — so cost discipline is about not paying for the wrong thing rather than about per-row tiering: the arithmetic sits in a free Code node instead of a model, which is both cheaper and the only defensible way to produce a filing figure. One standard-tier assembly pass per period is sufficient, and the premium tier appears only when a flagged anomaly genuinely needs reasoning. Contrast with the per-row recipes in this pack: there the economy tier is the lever; here the lever is refusing to spend model tokens on work that is deterministic.

Output & delivery

A Code node computes every figure from the ledger extract → Knowledge supplies the in-force form spec → the agent assembles schedules, working notes and assumptions → the reconciliation gate blocks anything that does not tie back within tolerance → a Tool (MCP) node drives the browser-automation server to fill the portal draft without logging in or submitting → the authorised signatory reviews the tie-back, enters their own credentials and files → an Output node archives the working papers, draft, approver and timestamp as the audit pack and emails the acknowledgement.