An invoice operations agent with controlled tools

This worked application uses explicit planning assumptions to demonstrate FIELD. Quantities below are inputs, calculated implications or proposed targets; they are not reported customer results. The engagement decision remains conditional on the evidence described.

Planning basis and engagement boundary

F — Frame the outcome

Prove net value for a bounded invoice-correction workflow across the stated tenant load, while the customer retains billing authority.

Value measure: Net effort/cost per verified correction and sustained eligible use.

I — Investigate the workflow

Measure current discrepancy handling, approval effort and permitted data access; confirm billing idempotency/status semantics before enabling writes.

First evidence task: Crash after a billing commit while retaining the original approval and operation identity.

E — Engineer the solution

Use the existing MCP/harness design with exact proposals, operation ledger and receipt verification; connect token/CPU/event sizing to the pilot scope.

The implementation assessment below makes the authority, workload, resource and failure assumptions concrete. Its numbers are calculations from the stated scenario, not a vendor performance guarantee.

Implementation plan

Start with one measurable workflow: identify an invoice discrepancy and propose a correction referencing authoritative records. Define eligible invoice states, maximum amount, required human roles and an independent reconciliation rule with the customer. Read-only investigation and write execution have different acceptance criteria. Existing identity, billing and ticket systems remain the sources of truth.

Use authenticated ingress, a relational run/operation store, a durable work queue, object storage and bounded workers. MCP adapters expose approved document/ticket/billing operations. Retain authorization at the resource-owning services; the effective tenant comes from authenticated context. The context builder selects permitted evidence and records source/version. The model proposes a typed correction; deterministic checks validate invoice ownership, state, currency, arithmetic and authority. The UI presents the exact delta and source evidence when review is required. Approval binds the delta, recipient/target, resource version and expiry.

Before a write, claim its stable operation key. Send a downstream deduplication key if the billing API supports one, persist the receipt and read back the corrected invoice. Mark task success only after the postcondition holds. If the API lacks a safe duplicate/lookup contract, keep the first pilot in draft mode or route ambiguous writes to an operator. This is an explicit workflow limitation, not a missing retry setting.

Resources, latency and availability

Thirty tool calls/s with 400 ms mean wait yield twelve mean in-flight calls. At 3 ms local CPU/call, the tool-path subtotal is 0.09 core; measure the rest of the application before choosing capacity. At 2,000 input/300 output tokens per model call, the model budget is 30,000 input and 4,500 output tokens/s. Model quota/inference capacity may dominate. Two 4-vCPU/8-GiB runtime replicas are a plausible initial load-test shape; a durable database and connection limits are separate requirements.

At 12 events/task and 2 KB/event, raw events grow 10.368 GB/day. Put documents and long outputs in object storage, with authorized references in events. Hours of approval waiting should consume persisted records rather than worker threads, open database transactions or reserved GPU slots.

Allocate a critical-path latency budget for admission, queue, retrieval, model rounds, tool writes and verification; then measure the full distribution. Do not add p95s to manufacture an end-to-end p95. Define degraded behavior when documents or billing are unavailable: a verified partial investigation is acceptable; an invented correction is not.

Failure and evaluation

Kill a worker after billing commits but before the local receipt is stored. Recovery queries/deduplicates the operation rather than recreating it. A stale invoice version forces re-evaluation and potentially a new approval. A malicious document must not change authority. A tenant burst must not exhaust all workers or the shared billing quota.

Evaluate extraction, arithmetic, unauthorized-action rejection, duplicate prevention, false completion, latency and cost per verified correction. Establish a labeled pilot set, human baseline, support owner and rollback/disable path. Record achieved measurements only after actual tests.

If the scope changes: The customer requires all data in its own network and disallows external model APIs. Replace model access with an approved in-network serving path; size weights/KV/compute and operations separately. Do not assume local model quality or hardware capacity matches the API baseline.

Simpler alternative: Begin with a deterministic reconciliation workflow and a model only for extracting ambiguous documents. Full autonomous planning is justified only if measured task coverage improves enough to offset added risk and latency.

L — Launch with evidence

Pilot a limited correction class and measure verified outcomes, review burden and false success. A lost billing response must reconcile before any retry.

Critical decision condition: Unknown billing outcomes or changed proposals cannot be treated as approved successful writes.

Attach raw artifacts, the tested configuration, population, denominator, date and limitations to the release record. Missing or stale evidence holds the dependent decision. A favorable value forecast cannot offset a failed critical condition.

D — Develop ownership and reuse

Billing and support owners accept exception handling; customer operators recover a run and own costs. Reuse the operation contract after a second workflow.

Candidate reusable asset: MCP operation ledger and verification contract.

Commercial decision and next commitment

Accountable decision owner: Customer billing owner with service release owner.

The initial commitment is the bounded journey above, with the stated exclusions. Confirm access, customer staffing and acceptance ownership during discovery; price and schedule unresolved dependencies explicitly. A new source, tenant class, language, action or operating envelope requires an impact review rather than silent scope growth.

Approve only the next exposure level supported by the evidence. The next useful investment is: crash after a billing commit while retaining the original approval and operation identity.

A deeper FIELD walkthrough

F — Contract the business result

Use the base economic case: 20,000 eligible invoices/month, 60% adoption, eight baseline minutes, two assisted-interaction minutes, two review minutes and 10% fallback requiring eight additional minutes. The finance owner values 50% of freed capacity at SGD 60/hour. With SGD 0.30 variable cost, SGD 6,000 fixed monthly cost and SGD 24,000 build investment allocated over 12 months, the planning case yields 640 freed hours and SGD 7,600/month after build allocation. No financial benefit authorizes an unapproved correction.

I — Resolve authority and source truth

Observe 12 tasks covering routine discrepancies, incomplete supporting records, disputed amounts, duplicate requests and timeouts. Distinguish an invoice correction from a payment. Identify the final ledger, who can approve which fields, how an approval expires and how the customer detects that an external write committed. Get a permitted test tenant and representative records before promising production writes.

E — Build one complete controlled path

Intake creates a tenant-scoped durable task. Retrieval tools return source facts with versions. The model proposes a typed correction. Deterministic validation checks policy and preconditions. An authorized human approves the exact action revision. The gateway rechecks authority, records a stable operation key and calls the source application. The task is complete only when a business receipt confirms the final state. A timeout after send enters reconciliation rather than a blind retry. Bank-detail changes and payment execution remain excluded.

A proposed six-week delivery splits into two weeks for discovery and the read-only slice, two for approval/effect handling and recovery, one for held-out evaluation and one for the assisted pilot and operator exercise. It depends on customer access and approval owners being available on agreed dates. Price discovery separately if those dependencies remain unresolved. The build-investment figure in the value case is an assumption for this scenario, not a fixed commercial quote.

L — Require evidence at each boundary

Create 240 acceptance tasks: 80 normal corrections, 40 missing/conflicting records, 40 permission/approval failures, 40 duplicate/ambiguous-write cases, and 40 restart/cancellation cases. Every critical denied action must produce no external effect. Every duplicate operation must reconcile to at most one intended effect. Propose p95 intake acknowledgement within 500 ms and p95 routine completion within 30 seconds, excluding separately measured human waiting. A customer operator must recover a staged failed task within a proposed 30-minute RTO.

The release packet contains source snapshots, action and approval revisions, task traces, authoritative receipts, load configuration, metrics and known limitations. Expired credentials, revoked approvers, altered arguments and an application restart are tested deliberately. Synthetic transaction fixtures establish behavior in a controlled environment; a permitted pilot establishes workflow usefulness. Neither automatically proves rare-event safety at full scale.

D — Hand over the operating decisions

Finance owns policy, exception adjudication and benefit realization. The customer service owner owns alarms, budgets, restore and reconciliation. The delivery team owns defects during the contracted support window and maintains the reusable adapter boundary. A second ERP must pass its own effect/reconciliation contract before becoming a supported connector.

Decision under these assumptions

Approve a capped read-only and assisted pilot once access and source semantics are verified; hold autonomous writes until critical evidence passes. If average review exceeds 3.27 minutes at the other base inputs, the allocated value case becomes negative. If a source cannot support idempotency or reliable reconciliation, preserve a human commit step. FIELD makes both decisions explicit rather than treating a functioning agent demonstration as delivery acceptance.

Method and references

Apply the FIELD method, economic model and evidence rules. Methodological and technical influences are listed in the source register. The protocol assessment follows the agent control chapter; pin and verify the actual protocol/runtime combination before implementation.