What does a scoping meeting for a freight billing agent pilot produce?

A platform team at a freight forwarder is building an agent that applies carrier and customer payments in a freight billing system. Their lead engineer, the finance operations manager and a billing analyst meet MirrorFirm to scope a pilot.

They bring three things: the agent's tool list (`search_open_items`, `propose_allocation`, `open_exception`), a list of failures from internal testing, and a statement that production data cannot leave their environment. The failures are a combined remittance covering invoices in two currencies, payments referencing a shipment number instead of an invoice number, and short-pays caused by agreed rebates.

The pilot request is written as: one environment with freight customers and carrier payables, a task pack focused on those three failure types, held-out tasks kept apart from any training use, and graders that report per-dimension scores. The group also records what they will inspect on arrival: key resolution, allocation sums, ambiguity in expected outcomes, and the disclosure risk review.

The finance operations manager adds a requirement that policy text be editable, so staff can replace generated rules with their own wording and rerun. That goes into the pilot request as a change to the environment, not as a promise about delivery.

**What it teaches:** a pilot request works best when it names tools, failure types, held-out boundaries and review steps. The result is a narrow, testable scope rather than a broad wish for realistic data.