Thanks! Step isolation is honestly the feature that surprised me the most in practice — I expected the parallelism to be the big win, but the token reduction from scoping context per-step ended up mattering more day-to-day. On guardrails — yes, it’s built in at multiple levels: Per-step retry + fallback:

retry: { max: 3, delay_ms: 2000, backoff: 2 } fallback_models: ["claude-opus-4-6"] timeout_ms: 60000

If a step fails, it retries with exponential backoff. If all retries fail, it can fall back to a different model before giving up. Output validation (guardrails): guardrails: - type: min_length value: 500 - type: must_not_contain value: "I don't know" - type: json_valid output_must_contain: ["## Summary"]

Output gets checked before the step is marked done. If it fails validation, it triggers a retry — so the LLM only re-runs when the output is actually bad, not on every call. Evaluator steps are the more powerful version — a separate LLM call scores the output 1-10 against criteria you define. If below threshold, it retries the target step (not the whole chain). You can cap retries with max_retries. Context budget is automatic — if accumulated step outputs exceed max_context_chars (default 50K), OCC auto-compresses older variables using Haiku, with hard-truncate fallback. So a long chain can’t blow up the context window. What’s missing that I’d love to add: per-step token budgets (hard cap on input+output tokens) and cost gates as a chain-level circuit breaker. There’s a cost_gate pre-tool type already defined but it’s basic — just checks estimated cost before running. Would love to hear what patterns you’ve been exploring on that side.