What does a scoped pilot for a claim lodgement agent look like?

An engineering lead at an insurer's technology team is building an agent for claim lodgement. They request a pilot covering one path: home contents claims lodged by portal, `CLM-` identifiers, three queues, and one completeness policy.

The scope sheet lists the tool actions the agent will use (`get_claim`, `search_policyholder`, `list_documents`, `set_status`, `assign_queue`, `send_request`), the exception classes wanted (duplicate lodgement, expired policy cover, missing proof of loss, conflicting loss date) and the output form: a task pack in JSONL plus a small environment with reset.

The first sample arrives as a small set of tasks. The lead runs the consistency checks, finds one claim whose document is attached to a policyholder who does not match, and confirms it was an intended defect with its expected outcome set to hold and escalate. They also read the sample for names and identifiers resembling real ones, and record the result.

The state change that matters is in the plan, not the data: the pilot proceeds only after the sample passes the lead's checks, and the licence question (internal evaluation versus training a model offered to customers) is settled before any larger release is requested.

The consequence is a narrow, inspectable start. If the sample had failed, the cost would be a revised specification rather than a large commitment built on a flawed set.

**What it teaches:** put the tool list, exception classes and licensed use in the scope sheet before asking for volume.