Skip to main content

The Dependency Chain & Disable Cascades

Everything you configure in Circus is wired together. A workflow doesn't stand alone — it leans on a chain of pieces beneath it, and if you disable one of them, everything above it becomes invalid and the workflow stops being runnable until you resolve it. This is deliberate: it's what stops Circus from ever dispatching a workflow that's secretly broken.

The chain​

Two chains run through your configuration, and both end at the workflow.

The agent side. A workflow runs a workflow configuration set, which assigns agents to models and prompts. Every one of those pieces can be disabled, and disabling any of them breaks the assignment above it:

  • model → agent assignment → workflow configuration → workflow
  • agent → agent assignment → workflow configuration → workflow
  • prompt → agent assignment → workflow configuration → workflow

Disable a model, an agent, or a prompt, and every agent assignment that depends on it is disabled; every configuration containing one of those assignments becomes invalid; and every workflow using one of those configurations becomes unavailable.

The service side. Workflows that call external services lean on a service configuration set:

  • service → service assignment → service config set → workflow

Disable a service and the cascade flows the same way, down to the workflow.

The general rule is the point: every disable-able piece in the chain invalidates everything above it. Whether it's a model, an agent, a prompt, or a service, taking one out of service ripples upward until the workflow at the top can no longer run.

What you'll actually see​

You won't get a cryptic error — you'll notice a workflow has simply gone missing from the launcher on an entity's manage page, or that a configuration is flagged invalid. That's the cascade doing its job. Rather than let you launch a run that would fail — or silently use a disabled model — Circus removes the workflow from the list of available actions until its whole chain is healthy again.

How to resolve it​

Follow the chain back to the disabled piece and either re-enable it or swap it out:

  • Re-enable the model, agent, prompt, or service you disabled, and the affected workflows return to availability automatically.
  • Swap it — if you disabled something on purpose, edit the affected configuration so its assignment points at a different, enabled agent, model, prompt, or service. Once the configuration is valid again, its workflows come back.

Because validity is derived from the state of everything upstream, you never have to manually re-mark a workflow as available. Fix the dependency and the chain heals itself.