6. Use or reject the result

Take the selected reviewer back to new work, with an explicit rollback.

The outcome is a usable agent and a defensible decision—not a higher-looking reward. If the exam does not support promotion, keep the baseline. If it does, preserve the baseline profile and model identity before using the candidate.

Apply it to a new review

Use the distinct ticket-routing adaptation from lesson 3, or an authorized real change with adequate context. This work must not be an example you repeatedly tuned against. Inspect the policy and privacy declaration before publishing it as a task.

Upload the new task, then run one trial with the selected profile:

synth task upload ./my-ticket-case/tasks/tickets-regression \
  --name my-ticket-review --json
synth run start --task <new-task-ref> --actor @my-course/profiles/learner-small.json \
  --plan '{"trials_per_task":1}' --idempotency-key my-new-ticket-review-01 --json

This example deliberately retains the baseline. Substitute checkpoint.json only if your promotion decision supports it. There is no automatic production rollout. A task invocation is one supported ordinary workflow: complete new work and inspect its actual output, not just publish a profile.

For a local interactive review, Synth with Claude Code supports a model or compatible checkpoint selector. That is a different entry point: it does not automatically load every setting from a managed agent profile. Do not claim an interactive session uses the same harness recipe unless you supplied and verified those settings.

Retain and roll back deliberately

Keep learner-small.json, the selected candidate file, the task/assessment manifest and the comparison evidence. To return to the baseline, select learner-small.json on the next new run. Do not overwrite its model with a moving “latest” alias. Cancelling one candidate run does not roll back other sessions or deployments.

Read the new review against the ticket policy. Does it explain an actual operational consequence? Is its input valid? Did it invent additional issues? Retain the review, even if the answer is disappointing. A score alone is not a handoff to a customer.

The recorded retained-baseline invocation completed one new ticket review in about 76 seconds from admission to terminal state. It correctly explained that changing the capacity condition from and to or allowed inactive or cross-organization teams when spare capacity existed. Its input used an inactive team, different organizations and available capacity: policy deny, changed code allow. The executable score was 1. The original Qwen3.6 profile—not the trained checkpoint—was used; no deployment was performed. The full review is in the reference record below.

What the course establishes

The reference evidence records the selected identity, new-work result, model-update/checkpoint proof and promotion verdict. This teaches a complete measured loop on an original small codebase. It does not establish customer savings, autonomous safe deployment, a generally strong reviewer or an improvement on unseen repositories.

For your team, the next step is to replace the teaching policies with cleared examples of the work you genuinely need done, qualify their assessment with someone who knows that work, and repeat the same disciplined comparison. Keep task creation, judging and the decision as real responsibilities—not promises of automatic synthesis.

Finish with cleanup and retained evidence.