Overmind Optimiser

Start with list_projects and choose the intended accessible project. For an account connection, pass its project_id on every project tool and resource URI query; follow returned links. Project API keys retain their narrower access.

Find a measured improvement while preserving the experiment's own baseline and the user's selected task. Use the chosen MCP project and resolve all dataset and capability references from its returned records.

Choose the experiment

Distinguish prompt/code optimization from model comparison. Prefer the native optimize-capability prompt for the first, or compare-models for a selected model list. Check the current schema for optimize, model_comparison or hybrid mode; do not silently substitute one for another.

Use list_datasets, inspect_dataset and query_dataset to select a fitting eval cell. Call check_optimizer_readiness with that cell, capability, mode, eval set and requested models. Explain missing executioner, model, credit or quota prerequisites. Every iteration is graded with the rows of the experiment's first run, by default the capability's active eval set; confirm it holds the code's expectations and toml checks (eval_preload on the capability, refreshed by overmind sync) before starting. The dataset stays on the server; a local file must be landed before an experiment can use it.

Execute within the approved scope

After the mode, candidate scope and spend are authorized, start_optimizer creates the experiment. MCP schedules and reports it; a local executioner runs repository commands and candidates. Do not claim that a scheduled experiment has executed or that MCP can apply a repository diff.

Follow the returned next_action and exact command in the intended checkout. Use local overmind optimise ... --help for commands unavailable in the client. If the client cannot run local code, provide that handoff and continue read-only status inspection. Preserve existing repository changes.

The experiment scores its own baseline iteration. Do not create a separate baseline run and use it as the improvement gate. Candidate changes must solve the task rather than encode held-out answers. Stop at the returned completion or plateau checkpoint; do not extend the search budget without authorization.

Inspect and land

Use inspect_optimizer_result, overmind://optimizer-runs/{experiment} and get_job(kind=optimizer_experiment, id=...) for progress, coverage, failures, candidate scores and the winner. A terminal run may retain the incumbent. Describe partial coverage and incomplete evaluations before naming a winner.

Present the winning diff and its measured delta against the experiment's own baseline. Apply it locally only when landing that change is authorized; changing code, switching the live serving alias and selecting a benchmark are distinct actions. Report whether a change was merely proposed or actually applied.

Open optimiser/{experiment_id} under the project's Console base with the same projectId when a visual result is useful.