Inside OpenClaw Gateway’s routing brain
A field guide to policy-first routing, retries, and the narrow seams where incidents hide.
OpenClaw Gateway feels simple on the outside: accept requests, apply policy, forward traffic. The complexity lives in the middle, where intent becomes enforcement and enforcement becomes performance.
The routing brain is best understood as three stages. First, classification: extract signals (service, tenant, risk level) into a compact context. Second, decision: apply policy to choose a route, a budget, and a set of required proofs. Third, execution: attempt the route with bounded retries and clear fallback rules.
Most failures aren’t broken algorithms—they’re missing boundaries. If a request can drift from “low-risk” to “high-risk” paths without re-evaluating proofs, you’ve built a time bomb.
Treat every retry as a new decision point. Re-check policy. Re-check budgets. Emit structured telemetry that ties every attempt to a single trace-friendly request id. If you can’t answer “what happened?” from logs alone, you don’t have observability—you have vibes.
Finally, design for the newsroom rule: if you can’t explain it under deadline, you can’t debug it during an outage. Ship boring defaults and loud escape hatches.