How it works

Resilience & modes

The point of the design is what happens when things go wrong — so resilience is built into both the routing and the workflow.

Halo's resilience mostly lives in gateway configuration, not in agent code. Failover and routing are enforced at the gateway; the workflow just reacts to it.

The three operating modes

ModeBehaviour
NormalBest model, full read + write (approval-gated) tools, multi-step investigation.
DegradedWhen the primary model or a tool keeps failing, Halo falls back to a faster/cheaper model and a read-only toolset — and keeps going.
BlackoutWhen it is no longer safe to act, Halo stops writes, preserves state, and produces a clean handoff to a human.

Model fallback

Halo defines virtual models on the gateway, priority-routed to AWS Bedrock targets.halo-vm-normal is the primary Claude with a fallback target behind it;halo-vm-degraded is the faster/cheaper model used under stress.

On a rate-limit, timeout, or 5xx, the gateway fails over to the next target automatically — with no retry or failover logic in the agent itself. This is what lets Halo degrade instead of die.

The mode ladder

The mode ladder is driven by failures:

  • Repeated rate-limits / timeouts / 5xx from the gateway step the agent down normal → degraded.
  • Continued failure escalates degraded → blackout, where all writes stop and the incident is handed off.

In degraded mode Halo is restricted to the read-only MCP server, so write capability is not even on the table when the agent is operating under stress. See Guardrails & safety.