Skip to main content

The Dependency & Disable-Cascade Model

The configuration control plane — models, agents, prompts, services, and the sets that bundle them into workflows — is a dependency graph. The platform keeps that graph consistent through one mechanism: when a dependency is disabled, everything downstream is invalidated automatically. This article is that mechanism as a design property.

The cascade chains​

Disablement propagates along fixed chains, and it applies to every disable-able node in the graph — models, agents, prompts (via their families), and services alike:

  • model → agent assignment → workflow configuration → workflow
  • agent → agent assignment → workflow configuration → workflow
  • prompt family → prompt → prompt version → agent assignment → workflow configuration → workflow
  • service → service assignment → service config set → workflow

Disable any node and each dependent above it is invalidated, up to the workflow, which becomes unavailable. There is no privileged element here — the general rule is that any disable-able part of the chain invalidates the rest.

Validity is derived, not stored​

The important design choice is that downstream validity is computed from upstream state, not maintained as a separate flag that could drift. A workflow configuration is valid because its agents, models, and prompts are enabled — ask again after disabling one, and it's invalid, with nothing to update by hand. Re-enable the dependency and validity returns on its own. This makes the cascade self-healing and impossible to leave in a lying state: the graph's health is always a live function of its parts.

Why it exists​

The purpose is integrity: the platform must never dispatch a workflow that would run against a disabled model or a missing prompt. Rather than catch that at execution time — an expensive, late failure — the cascade catches it at configuration time by simply removing the workflow from the set of runnable things. The operator sees this as a workflow "going unavailable"; architecturally it's the control plane refusing to enter an invalid state. It's also why the core's getAvailableWorkflows service can answer "what can run here?" purely from derived state, with no per-workflow bookkeeping.

Disablement vs. deletion​

Deletion is a separate concern from disablement. Disabling a service cascades to invalidate; deleting one strips it from configurations (which may cause a later run to fail) but doesn't disable anything — a deliberate distinction. The cascade is specifically about the enabled/disabled state that governs runnability.