Auto Research

Optimize learning per unit of time. Start with one fast, revealing task, plan competing hypotheses, test them separately, combine verified winners, then expand coverage. The durable result is a parameter-effect map plus the best verified artifact. An experiment is a checkpoint, not a stopping point.

Workflow

1. Recover the research state. Read the objective, user feedback, project instructions, and existing research records. Reconcile the handoff with actual artifacts and running jobs; collect a pending attempt before launching another. Identify the best verified artifact (the incumbent), active task, regression set, hypothesis queue, and remaining budget. Reuse existing record locations.

2. Clarify success before experimenting. Recover any already agreed criteria; do not ask the user to repeat them. If the evaluator, metric, comparison baseline, or required improvement is unclear, ask focused questions and wait for answers before editing candidates or launching evaluations. Inspect existing artifacts and propose concrete options to make answering easier; do not silently choose what success means. Continue clarification until the answers define a checkable criterion, including evaluation scope, aggregation, and non-regression gates. Restate that criterion in the research contract.

   Distinguish passing correctness gates from achieving the optimization target. Specify whether the target is an absolute score, an absolute change, or a relative improvement against a named baseline. “Improve accuracy by 5%” is ambiguous: from 60%, five percentage points means 65%, while 5% relative means 63%. Clarify the units and direction; record the formula when needed. A baseline's value may be measured next, but its identity and the comparison rule must be settled first. Accept open-ended optimization only when that is the user's intent; do not invent a threshold or substitute any improvement for the requested improvement.

   Then define the smallest useful loop. Record mutable parameters and the fixed evaluator and select one cheap task that exposes the behavior being improved. Measure its turnaround and remove unnecessary setup, models, cases, and implementation work from the inner loop. Prefer an architectural spike when the uncertainty is architectural. Available benchmark tasks are a pool, not a requirement to run them all; choose validation coverage to support the intended claim and user's scope.

   Record the evaluation command, timeout, repair allowance, resource limits, promotion rule, and confirmation plan. Separate research spend from the cost or runtime being optimized. Done means the success criterion is resolved and the next trial is cheap to run with an unambiguous decision rule; do not build a large benchmark matrix before testing the first hypothesis.

3. Establish the active task's baseline. Run the unchanged artifact once, or reuse its compatible recorded result and traces. Verify the evaluator measures the intended outcome; use a known failing control if detection is unproven. Keep the baseline fixed for this task/model/harness; do not rerun it per variant. For noisy measurements, plan only the repeats needed to distinguish an effect, respecting any user instruction to reuse a single baseline and reporting that limitation. Save exact inputs, artifact identity, and raw output.

4. Plan a small hypothesis batch. Before editing, list distinct explanations of the current bottleneck and the parameters or strategies that could test them. Inspect actual failure traces and matched baseline behavior instead of guessing from aggregate scores. For each hypothesis, record:

   • Parameter/change and mechanism: why it might affect the outcome.
   • Predicted observation, falsifying result, and cheapest discriminating test.
   • Fixed comparison parent, expected trial cost, and dependencies or likely interactions with other hypotheses.

   Rank by information gained per unit of time. Test alternatives one by one against the same parent so their effects remain interpretable. Avoid exhaustive parameter grids. Keep the queue short and revise it after results; planning is part of every research cycle, not a one-time backlog or a reason to delay the first trial.

5. Test one hypothesis on the active task. Preserve the incumbent and isolate the candidate from unrelated work. Change one conceptual factor; if a coupled bundle is necessary, attribute the result to that bundle. Record the candidate identity and prediction before running. Use cheap checks first, then the focused task; do not run the broad suite for every variant. Save uniquely identified raw output and inspect relevant traces. Bound crashes and repairs; a repaired candidate gets a new identity. Missing results are unknown, not zero.

   Compare observation with prediction, including regressions and null results. Record keep, discard, inconclusive, or invalid and update the map. Restore the parent between alternatives; retain reproducible snapshots or patches and evidence outside rollback scope. Rejecting a candidate does not disprove its entire strategy: diagnose a promising partial win and plan a targeted follow-up when evidence supports one.

6. Combine and promote. Test compatible winners together against the strongest individual candidate. Do not assume gains add: check interactions, and remove one change at a time when attribution is unclear. A combination that loses to a simpler candidate does not become the incumbent.

   A focused win is provisional. Before promotion, check the candidate against previously solved tasks in the accumulated regression set, using their saved baselines and the declared tolerances. Reject or repair regressions rather than hiding them in an average. Confirm noisy wins with the planned evidence, including all planned attempts and costs. Bank the verified candidate and update the parameter-effect map with interactions and task-specific limits.

7. Expand only after progress. Once the active task meets its local criterion and prior tasks remain green, add one task or a small batch that probes a new failure mode or an uncertain effect in the map. Establish missing baselines only for those tasks. If a new task fails, make it the active task, return to hypothesis planning, and retain the old tasks as regression checks. Do not repeatedly run the expanded suite while debugging that one failure.

   This curriculum changes discovery coverage, not the overall success criteria. Reserve broader evaluation for coverage-expansion checkpoints and final confirmation. A single-task win cannot complete a broader objective.

8. Replan from what was learned. After a hypothesis batch, a new failure, or several non-improving trials, consolidate the map and choose the next most informative batch. Change the suspected mechanism or experiment design when the evidence contradicts it; do not endlessly retune one family or rerun the same tests. Revisit a rejected idea only with a changed premise. Continue without asking whether to proceed after each experiment.

Durable research record

Use the project's existing format; keep these views compact and linked to evidence:

• Contract: objective, fixed evaluation rules, budgets, current task and regression set, and final validation scope. Version protocol changes; do not mix incompatible scores or weaken the user's criteria to make a result pass.
• Hypothesis queue: the planned batch, priorities, dependencies, predictions, and tested/rejected/next status. Retire stale entries as the map improves.
• Parameter-effect map: one row per meaningful parameter or strategy: tested settings/range, observed effect on quality/cost/runtime, applicable task types, tradeoffs, interactions, confidence, evidence links, and remaining uncertainty. Distinguish measured effects from suspected mechanisms; include harmful and null effects. This synthesis is a primary deliverable, not just a leaderboard or chronological experiment log.
• Attempt ledger: hypothesis, parent/candidate identity, protocol version, task, command/configuration, metrics, gate results, resource use, verdict, and evidence paths. Capture model/prompt/data versions and seeds when relevant.
• Handoff: incumbent, active task, pending job/output location, remaining budget, and the next concrete test with its reason. Update after each verdict and before a turn boundary; never leave only “continue optimizing.”

Evidence discipline

• Optimize the actual outcome. A smaller output or faster microbenchmark is a diagnostic until end-to-end quality and cost gates pass. Reduce trial scope while preserving the behavior under study; never hardcode a task's answer.
• Keep comparisons matched. Freeze candidates within a cohort, avoid resource contention, and never select a favorable baseline or repeat after seeing scores.
• Keep development and confirmation separate. Repeatedly tuned cases are development evidence. Use untouched cases for generalization claims; keep hidden answers and evaluator-only inputs out of candidate work.
• Account for failed trials and retries in research spend. State objective cost inclusions/exclusions and reconcile incomplete bills before claiming savings. Infrastructure failures are neither wins nor measured candidate regressions.
• Disclose material findings immediately; workflow order never delays disclosure.

Stopping

Continue within the authorized session and limits until the target passes its required validation, the user stops the work, a budget is exhausted, or a genuine external blocker prevents useful progress. A plateau calls for replanning, not an invented claim of optimality. Preserve research state across continuations; this skill does not itself schedule future work.

At a stopping boundary, leave the incumbent recoverable and account for pending jobs. Deliver the parameter-effect map, baseline versus best verified results, coverage and limitations, budget consumed, stop reason, and exact next experiment if unfinished. Meeting a score does not replace recording what the experiments established; an unfinished run still leaves a useful map of what is known.