Loop guardrails are the least glamorous item on that list and the one I would ship first, because an agent that retries a failing step is not an error condition anywhere in the stack - it is a successful request repeated until someone notices the bill. Failures that look like normal traffic are the ones no monitoring catches by default. On failover, the caveat worth being explicit about is that swapping providers mid-run is not transparent: output shape, refusal behaviour and tool-call formatting all shift, so a run that fails over can complete and produce something downstream cannot parse. Zero-drop at the transport layer is necessary but the contract still has to hold, which usually means validating the response against a schema on both paths rather than trusting either.
Completely agree on both fronts.
On loop guardrails, that silent green 200 OK failure mode is exactly what burns budgets before anyone notices an issue.Your point on failover contract integrity is critical. Surviving at the transport layer means nothing if downstream Pydantic or Zod parsers choke on subtle tool-call formatting shifts or refusal semantics between providers. We currently normalize shapes between Anthropic and OpenAI, but active bi-directional schema validation before handing off the failover response is an essential guarantee.Taking this directly into our backlog for the next release.
Shape normalization is useful, but refusal should remain an explicit outcome rather than being normalized into an empty success object. A provider can return syntactically valid data that means it declined the task, and downstream code needs to distinguish that from a successful extraction with genuinely absent fields.
For the backlog item, I would use fixtures covering success, refusal, truncated output, and missing required fields on each provider path. Require the adapter to return a clear outcome type before schema-valid data is passed onward. That makes contract integrity observable even when the HTTP request itself succeeded.
Ahmet Özel
AI Engineer. Computer Vision, RAG and LLM agents.
Loop guardrails are the least glamorous item on that list and the one I would ship first, because an agent that retries a failing step is not an error condition anywhere in the stack - it is a successful request repeated until someone notices the bill. Failures that look like normal traffic are the ones no monitoring catches by default. On failover, the caveat worth being explicit about is that swapping providers mid-run is not transparent: output shape, refusal behaviour and tool-call formatting all shift, so a run that fails over can complete and produce something downstream cannot parse. Zero-drop at the transport layer is necessary but the contract still has to hold, which usually means validating the response against a schema on both paths rather than trusting either.