Docs

Module reference

One page per module: what it does, when to use it, what it receives and sends, and which settings you can change.

See a worked example first: one round of the research loop

Capabilities

The building blocks of a workflow. Each one is an agent with one job, listed in the order a workflow usually runs them.

Interpret resultsTurns earlier training results into evidence and diagnoses for the next proposal.
Literature reviewSearches published papers for findings that address the current bottlenecks.
Propose modelProposes the next model architecture to try, as a structured plan.
ImplementWrites the proposed model as runnable PyTorch plugin code with its tests.
ValidateChecks the generated model code (loading, tests, gradient flow, code review) before training.
Train & tuneTrains the validated model and tunes its hyperparameters, reporting scored results.

Adaptors

Small fixed steps between modules that choose or split results. They follow fixed rules; no language model is involved.

Aggregators

Adaptors that combine several results into one input.

Collect reviewsVia your coding agentGathers several literature reviews into one input for a single proposal.

Coming soonAggregators that use a language model (for example ranking by a rubric, a debate settled by a judge, or a judge merging several results) are planned and not yet available.

Workflow settings

Settings that belong to the whole workflow, not to one module.

Loops and routesRepeat a workflow round after round, stop it early on a rule, or run a branch only when a condition holds.

Connector types

The console marks every socket with a colour, a shape and a name for the kind of data it carries. A wire joins an output and an input of the same type. Filled sockets are outputs or required inputs; hollow ones are optional.

Connector	What it carries
`Run summaries`	Condensed summaries of one or more finished training runs.
`Results analysis`	A reading of run results with per-model scores and the best and worst models.
`Search evidence`	Evidence from earlier analysis that a literature search looks for papers about.
`Paper findings`	Findings from published papers, with the retrieved papers behind them.
`Design brief`	Everything needed to design the next model.
`Model plan`	A complete model specification, ready to implement and train.
`Coding brief`	A model plan with run context, ready to be turned into code.
`Model code`	Paths of the written model source files.
`Review brief`	Model code with its context, ready to be checked before training.
`Code verdict`	A verdict on whether the model code is safe to train.
`Training job`	A validated model with its training settings, ready to be trained and tuned.
`Training report`	The full report of a completed training and tuning run.
`Training settings`	Training launch and startup controls that you provide in a settings file.
`Storage folder`	Where records and outputs are written; you provide it.
`Data folder`	The path of the folder that holds the task's data.
`Language model provider`	Which language model service is called, such as openai or anthropic.
`Language model name`	An exact model name at the chosen service; when omitted, the service's default model is used.
`Expert advice`	Advice written by a person for a module to consider.
`Expert notes`	Context items from people or analysis modules that inform a model design.
`Parameter rules`	Limits on which model and training parameters may change and how.
`Run constraints`	A statement of the known run restrictions and who declared them.
`Task reference`	A pointer to the run's task declaration, never a second copy of it.