Roles and strategies

A workflow agent separates what it does from which AI model does it, so you can change models without redrawing anything. You set this on the agent’s Execution tab: a role is a job in the agent (for example “writes the first draft” or “checks the answer”), and each role is filled by a model. A strategy is the pattern the work follows, such as “a cheap model drafts, a checker reviews, the main model steps in only if the check fails”.

Come here when activating a workflow agent fails with Not ready: … Configure the strategy and roles on the Execution tab. Open the agent and pick Execution, the third tab after Overview and Runs; the not-ready banner’s Configure execution button goes straight there. (Autonomous agents pick their models on their edit page instead; see work mode.)

The tab holds three cards:

• Roles: which model fills each job in this agent.
• Strategy: the pattern of the work. A strategy never names a model; roles do that.
• Orchestrator: optional, lets a small model pick the strategy for each request.

What the error means

Each role has a key, like principal (the main model) or verifier (the checker). A strategy lists the slots it needs and fills them from your roles by matching each role’s key to the slot name. Activation refuses when a slot has no role, or a role has no model it can actually call.

The check is skipped entirely for autonomous agents, which choose models a different way, so this error only appears on workflow agents.

Add a role

On the Roles card, click Add role. An inline form on the Execution tab asks for two things:

• Key: lowercase letters, digits and underscores, starting with a letter. This is what strategies match slots by, and what nodes reference, so renaming it later breaks those references.
• Name (optional): a human label. Left blank, it falls back to the key.

The form suggests keys for you. When a strategy is already selected, its unbound slots are offered first under Slots your strategies need; otherwise you get the common ones: principal, drafter, verifier, explorer, summariser, orchestrator, panelist_one, panelist_two, panelist_three, judge.

A new role is created routed, with the cheapest model that fits. Adding, rebinding and removing roles is admin or owner only; members can see the tab and read what it resolves to.

Pinned or routed

Every role carries one badge saying how it is filled, not whether it is.

• Routed: almyty picks the model per run from your catalog, and shows the reason it chose. Use Let routing choose to switch a role to this.
• Pinned: one named model, every time. A pinned role never consults routing at all, which is what makes roles usable on an install where routing is off. Use Pin a model.

When any role is routed, Show what each role resolves to now asks for the current answer without running the agent. That is the quickest way to tell whether a not-ready message is about the role or about your model catalog.

The built-in strategies

Each card shows a coarse cost and latency band derived from how many model calls the shape makes, the slots it needs (amber when you have no role with that key), any optional slot as judge (optional), and its step count. Picking one saves immediately. Picking none leaves the agent running its own pipeline as drawn.

The Panel’s judge

The judge reads the three answers and writes the one they agree on. It is optional, and filled in this order:

1. a role with the key judge,
2. otherwise your principal role,
3. otherwise your organization’s default routing policy.

With none of the three, picking Panel is refused with Panel needs a judge to write one answer from what the panelists said. Add a judge role (a principal role also works), or set a default routing policy for your organization. Removing the judge later shows up in the agent’s readiness check as Judge on "consensus" needs a provider or routing policy.

What the run answers with

Whatever surface calls the agent (Try it, the OpenAI-compatible API, a gateway), it gets the answer a person expects rather than every step’s output:

The check, the candidates and the brief are still on the run, step by step.

Your organization can also publish its own strategies, which appear in the same list and override a built-in of the same key.

When a role cannot be filled

Role "x" could not be filled comes with a reason, and each reason has a different fix:

A model only counts as available when it is selectable: active, callable, and its provider’s key check has passed. See Models for what that means.

Orchestrator

Turning the orchestrator on hands strategy choice to a small model, per request. You give it a role to run as (orchestrator by default), a timeout in milliseconds, a fallback strategy for when it does not answer in time, and optionally the list of strategies it is allowed to pick from.

Readiness checks the fallback strategy, not whatever the orchestrator might choose at runtime, so the fallback’s slots have to be bound before you can activate.

Ejecting to a graph

Eject to an editable graph compiles the selected strategy into ordinary pipeline nodes and writes them onto the agent, after which the strategy is cleared and you edit the graph directly in the visual builder. It refuses when the agent already has a pipeline, so ejecting never overwrites a graph somebody drew by hand. The compiled nodes still carry role keys rather than models, so routing keeps filling each role at run time.

Changing model later

This is what the split is for. A strategy names slots, a node names a role, and only the role names a model. Moving an agent to a different model is a rebinding on the Roles card, not an edit to the graph or to the strategy, and every run records which model each role resolved to and why.