What does a narrow pilot for client engagement onboarding look like?

An environment lead at an agent-evaluation team wants to test client onboarding for a professional services firm. A partner approves engagement ENG-0412 for a new advisory client. The finance operations role then has to set up the client, the engagement and the billing arrangements.

The lead asks for a pilot with a narrow scope: one domain, a small batch of tasks, and the three outcomes that matter most, which are clean completion, pending on a missing document, and referral for a conflict check.

The sample request lists what to include: client records, engagement letters with status, a conflict register with a few near-matches, rate card entries, and the finance queue as the acting role. It asks for the seed state as JSONL, expected end states per task, and a rule file.

On receiving the sample, the lead loads it into their simulator and runs three checks. Every reference resolves. A scripted baseline passes the clean tasks and fails the shortcut variants. A reviewer reads the conflict register entries and judges whether the near-matches would cause a real mistake.

One finding: the conflict check task for ENG-0412, TASK-3391, has no due date, so the grader cannot tell whether activating the engagement early is wrong. The lead sends that back as a change request for the next iteration.

**What it teaches:**

- A small, specific pilot exposes schema gaps cheaply. - Review the sample in your own harness, not by reading alone. - Feed gaps back as concrete change requests.