Workflow Configs & A/B Testing

A workflow configuration set is where the abstract pieces finally come together into something concrete and runnable. It's a named bundle of assignments, each one binding an agent to a specific model, a specific prompt, and its runtime settings (temperature and max tokens). A workflow then points at one configuration set to know exactly how its agents should behave.

Building a configuration

You create a set, give it a unique name, and add agent assignments to it. For each assignment you pick the agent, choose a model, choose an active prompt (grouped by prompt family), and set temperature (minimum 0) and max tokens (minimum 1). The forms offer only enabled agents, models, and prompts, so you can't accidentally build a binding on something that's turned off. An agent can appear in a given configuration only once, and the order of assignments doesn't matter.

Validity is derived, not set

A configuration is marked valid or invalid by the system, not by you — and validity comes entirely from the state of what it depends on. A set is valid when every agent in it is enabled, each assigned model is enabled, and each assigned prompt version (and its family) is enabled. Disable any of those upstream and the configuration goes invalid automatically. (An empty configuration, with no assignments yet, is perfectly valid.)

Why this exists: A/B testing without edits

The real payoff is experimentation. Because a workflow just references a configuration set, you can create alternative sets — the same agents wired to different models or different prompts — and point a workflow at one or another to compare quality, cost, and speed across runs. You're changing the configuration, never the workflow, so the comparison is clean: one variable moved, and the execution logs show you the effect.