# Kanban developer-agent fallback

The board supports an explicit, ordered implementation fallback chain:

```json
"AgentFallbackChains": [
  {
    "PreferredAgentId": "DeveloperAgent",
    "FallbackAgentIds": ["DeveloperAgent2"]
  }
]
```

Routing changes only while the preferred developer has an active provider
cooldown. Backups must be enabled, idle, have a saved Developer preset, and have
no active cooldown of their own. Lists are not traversed recursively. Unknown
agents, duplicate entries, self references and other roles cannot create a loop.
Without a configured eligible backup, the existing cooldown behavior remains.

The card's `AssignedAgent` remains its preferred agent. The actual worker is
recorded in `Dispatch.AgentId` for implementation and in the memory attempt's
`Agent` field. The fallback receives the existing checkpoint, execution history,
previous output and continuation message. Every normal dependency, lease,
ownership, permission and review check remains in force. Changing workers does
not grant new artifact authority or clear any provider cooldown.

Planning and review retain their existing role routing. If every configured
developer is cooling down, the scheduler waits for cooldown expiry. There are
no speculative provider calls solely to probe fallback availability.

Agent Activity reports the switch when dispatch has been persisted. Board
configuration must be changed through the live scheduler's revision-safe save
path, or by an operator while no Editor owns the board; do not overwrite a live
board JSON file externally.

This is agent-instance failover, distinct from provider fallback within one
agent. Two configurations using the same provider account can still share
account-wide limits; an alternate model is not guaranteed to be available.
