Team adoption
This page describes the roles, set-up effort, and workflow fit for a manager-led pilot. It describes implemented product paths only. Commercial terms are separate.
Who does what
| Role | Usually | Effort | Responsibilities |
|---|---|---|---|
| Pilot owner | Engineering, AI, or product manager | About one hour per week | Chooses the workflow, records release decisions, and owns the approval brief. |
| Integrator | One engineer on the agent team | One to two days during set-up, then under an hour per candidate | Connects the agent command, creates the challenge cases and rubric, and runs candidates. |
| Technical reviewer | Security or platform engineer | One review session | Reads the execution and trace documentation and confirms data restrictions before any private data is used. |
Effort figures are planning estimates for one workflow with an existing agent command. They are not measured customer data.
Set-up
- The integrator connects the agent command to one challenge. Read run your agent and where your agent runs.
- The integrator defines fixed cases and a rubric so every version is scored the same way. Read challenges.
- The technical reviewer reads trace capture and trust information before any private data is used.
- The pilot owner creates an organization and invites the team. Read the workspace documentation.
How it fits an existing review workflow
Keep your current release process. Versalist adds one artifact to it: a comparable release review between the version you run today and the candidate.
- Set up. One challenge runs end to end for the chosen workflow and a baseline episode completes.
- Compare. Each candidate version runs against the same challenge and gets a release review with a recorded ship, hold, or needs-work decision.
- Decide. The manager exports the pilot metrics and an approval brief for the budget decision.
A release review compares two completed episodes with the same challenge, skill bundle, rubric, cases, and model contract. The reviewer records ship, hold, or needs work. The decision history is append-only.
Reviews can be shared with the active organization or through a seven-day link. Release reviews are a server-controlled feature and may be disabled in your environment.
What the pilot measures
- Every candidate version in the pilot receives a comparable release review. Review count equals candidate count in the pilot metrics. Source: product.
- Every release review ends in a recorded decision. Decided reviews equal total reviews in the pilot metrics. Source: product.
- Score regressions are visible before a ship decision. Reviews with a lower candidate percentage are listed in the pilot metrics with their decision. Source: product.
- Time from candidate completion to decision meets the requester target. Median hours to first decision in the pilot metrics, compared with the target the requester states. Source: requester.
- Review effort per release stays at or below the requester baseline. Requester records hours per review before and during the pilot. The product does not measure this. Source: requester.
The product measures review counts, decisions, decision latency, and score regressions. It does not measure review hours, time saved, or rework avoided. The pilot owner records those.
Getting budget approval
Use the pilot approval brief to assemble the problem, assumptions, cost, evidence, risks, and recommendation into one exportable document. Assumptions stay labeled as assumptions.
Pilot duration, seats, run capacity, and price are not yet published. Request them through the demo form. Request a demo and choose team rollout and pilot scoping.