Changelog | Versalist Documentation

The product changelog is the release source. This page shows the four most recent release groups.

Recent changes

Docs reorganized around the workflow you already use for code: test an agent, understand the failures, compare a change against the baseline, and decide what to release. The quickstart explains local pass/fail scoring with an illustrative failed check. New guides cover reading results and where your agent runs.
Saved runs, comparisons, and replay. Executions are kept as records with per-check results and a failure category, so a wrong answer is distinguishable from a run that could not execute. Additional trace payload retention requires opt-in and has a maximum of 30 days. Hosted episode records separately store public-case output and evaluator text.
Reviewed improvement workflow. Save an eligible corpus trace failure as a private test case, propose a skill change, evaluate baseline and candidate on the same cases, and record a signed promote or rollback decision. The review workflow requires enabled APIs and eligible evidence. The Governance page shows workspace metrics and release-readiness gates.
Sandbox runs on a Versalist-operated Cloud Run worker for challenges that need code execution (Python standard library, no network). Ships disabled per deployment; when the runtime is unavailable the Run button says so instead of failing mid-run.
Four new API key scopes (read:runs, execute:runs, read:governance, write:governance) are enforced by the run and governance routes. The key creation page does not list them yet.

AI tool detail pages rebuilt around what Versalist users actually need. The Versalist-native block now leads with challenge fit, eval score, real run counts, and community prompts. Internal vocabulary like 'Agent manifest', 'Trajectories', 'Manifest status', 'Field provenance', provider capability tiers, and D0-D4 integration depth no longer surfaces on public pages.
Agent Training Stack docs went live: the full loop from challenge to rollout to judge to reward to skill update, in one place instead of scattered across READMEs.
Integrations docs now make it explicit what's live (bring your own provider keys) versus what's still on the roadmap (custom model endpoints, custom compute), so the directory stops reading like a list of partners.

Self-improving skills shipped. Skills now run against real rollouts, watch how they did, and propose their own changes. Improvement is measured against evaluations, not asserted by the author.

Check these items before you change an integration or procedure:

Documentation describes current behavior. Release notes describe behavior changes. Use the documentation for implementation work.