continue_run
Drive a verification run to completion by submitting battery answers and evaluation responses as phases require.
Instructions
Drive a verification run to completion — the ONE tool to loop after start_verification. Verigent drives the test; you just do what each response's next_action says and call continue_run again. Phases it walks you through: it returns the battery tasks (answer them in chunks of ~10 as each is ready, rather than waiting to collect them all), then the multi-turn evaluation scenarios (respond to each in character — this is where memory, governance-under-pressure and sycophancy-resistance are measured), then done: true. Grading happens server-side IN THE BACKGROUND per chunk and completes on its own within a few minutes (a backstop drives it whether or not you poll) — you do NOT need to loop or set timers waiting for it. Note: the FIRST call starts the battery, so it's best to share the live tracker link from start_verification with your operator first, so they can watch grading progress there. The first (battery) response returns tasks grouped one content block per dimension rather than one giant block (K-43a) — read every block, not just the first. Supply { answers } after a 'battery' phase (a partial chunk is fine — call again with more as they're ready; idempotent per task_id) and { eval_responses } after each 'eval' phase — when a phase returns several scenarios at once, send every ready response together in the same eval_responses array in one call, since they're graded concurrently server-side and there's no need for one call per scenario. Once your answers and all scenarios are in, the run finishes on its own — call continue_run just ONCE more after a few minutes to confirm completion, rather than polling repeatedly. Each call's combined answers/eval_responses payload is capped around 32 KB (32768 bytes) (K-43a) — a call over that limit gets back a 413 naming the exact cap; split into smaller chunks and resend only what didn't go through, never the same oversized payload unmodified. run_token is optional: omit it and this tool falls back to the run_token this server saved locally when start_verification last ran (/.verigent/state.json) — so a cold session can call continue_run directly with no other setup. If nothing was saved, pass run_token explicitly or call resume_run.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| answers | No | Battery answers — supply after the 'battery' phase, one entry per task_id | |
| run_token | No | Run token from start_verification. Optional — omitted, falls back to the run_token this server saved locally at start_verification. | |
| eval_responses | No | Multi-turn evaluation responses — supply after an 'eval' phase, one entry per scenario_id. Send every ready response together in a single array call; they're graded concurrently server-side, so there's no need to call once per scenario. |