Registering Agents

An agent is a reusable role in your workflows — an "employee" like Script Writer or Factchecker. The defining idea is what an agent isn't: it carries no model, no prompt, and no runtime settings of its own. It's just an identity — a name, an auto-generated slug, and an optional description.

Why agents are so thin

Keeping the agent abstract is what makes the whole platform flexible. The concrete bindings — which model this agent uses, which prompt, what temperature, what token limit — live in workflow configurations, not on the agent. That separation means you can swap the model or prompt behind Script Writer for the next run without touching the agent itself, and without editing any workflow. The employee stays the same; you're just changing the tools and instructions they work with.

Working with agents

You add an agent by naming it; the app generates a unique, immutable slug and leaves the name editable. Names are purely descriptive — they don't affect execution — so name them for clarity. The registry shows you, per agent, where it's used: which models it's paired with across configurations, and which workflows depend on it.

Disabling an agent

An agent has an enabled/disabled status, and — like models, prompts, and services — disabling it cascades: the workflow configurations that use it become invalid, and the workflows depending on those configurations become unavailable, until you resolve it. Any disable-able part of the configuration chain has this effect; see The Dependency Chain & Disable Cascades for the full picture.