<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Safety Controls on Andreas Nissen</title><link>https://andreasnissen.dev/tags/safety-controls/</link><description>Recent content in Safety Controls on Andreas Nissen</description><generator>Hugo</generator><language>en-us</language><copyright>© Andreas Nissen</copyright><atom:link href="https://andreasnissen.dev/tags/safety-controls/index.xml" rel="self" type="application/rss+xml"/><item><title>Safe Model Failover Learning Lab</title><link>https://andreasnissen.dev/projects/safe-model-failover-learning-lab/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://andreasnissen.dev/projects/safe-model-failover-learning-lab/</guid><description>&lt;h2 id="the-problem"&gt;The problem&lt;/h2&gt;&#10;&lt;p&gt;Model outages are not one failure mode. A 429 can signal quota or rate-limit pressure, while a 503 can signal temporary service or regional capacity. Immediate retries can amplify an outage, and an improvised fallback can silently change safety behavior, output shape, data residency, or tool access.&lt;/p&gt;&#10;&lt;p&gt;For tool-using agents, retrying is more consequential still. A tool may already have changed state before the model call failed. Replaying that work without an idempotency key or execution ledger can duplicate an email, transaction, or other side effect.&lt;/p&gt;</description></item></channel></rss>