AI Signals & Reality Checks: Interruptibility Is the Real Safety Feature
Most “agent safety” conversations still focus on what the model might say.
But in real systems, the bigger risk is what the agent might do—quietly, quickly, and at scale.
So here’s a better question for 2026:
How interruptible is your agent?
The signal
Teams that have shipped agents into real workflows are converging on a new KPI:
time-to-interrupt.
Not “time-to-answer.” Not even “time-to-complete.”
Time-to-interrupt measures how fast a human can:
- pause a run
- inspect what the agent is doing right now
- change direction without losing context
- approve the next step (or deny it)
- hand the task back to the agent cleanly
You can see this shift in product choices:
- Pause / resume becomes first-class If the only control is “stop everything,” humans hesitate to intervene until it’s too late.
- Live trace becomes the main UI The run log (tools called, inputs/outputs, intermediate state) becomes the product surface—not a debugging panel.
- Handoffs become explicit The system marks boundaries:
- “I’m about to send a message.”
- “I’m about to write to production.”
- “I’m about to change a contract.”
- Safe interruption points Good systems create checkpoints the agent can roll back to. Bad systems force the human to choose between “let it run” or “kill it.”
Reality check: if you can’t interrupt it, you don’t control it
An “agent” that can’t be interrupted is basically an automated batch job with a chat window.
And the failure modes look the same:
- Runaway scope: the agent expands the task because it finds adjacent work.
- Tool misuse: it calls the right tool in the wrong context (or with stale assumptions).
- Latency hiding risk: long runs mask compounding errors until the final output.
- Silent side effects: the system changes things faster than humans can notice.
The uncomfortable truth is that safety is not just policy.
Safety is human override, mid-flight.
A practical design rule
If you’re building agentic systems, adopt this rule:
Every destructive action must be preceded by an interruptible moment.
“Destructive” includes:
- sending a message to a real person
- purchasing anything
- publishing anything
- deploying anything
- modifying persistent data
And “interruptible moment” can’t be a modal that shows up for 200 ms.
It should be a deliberate handoff:
- what will happen
- why it will happen
- what evidence supports it
- what the user can change
Because the best safety feature isn’t a longer policy.
It’s a system that’s easy to stop.
中文翻译（全文）
多数关于“智能体安全”的讨论，仍然停留在：模型可能说错什么。
但在真实系统里，更大的风险往往来自：智能体可能做错什么——悄无声息、速度很快、而且可以规模化。
所以，2026 年更值得问的问题是：
你的智能体有多“可中断”（interruptible）？
信号（The signal）
把智能体真正接入工作流的团队，正在收敛到一个新的关键指标：
“中断所需时间”（time-to-interrupt）。
不是“回答速度”。 甚至也不是“完成速度”。
time-to-interrupt 衡量的是：人类能多快做到——
- 暂停一次运行
- 看到智能体此刻正在做什么
- 在不丢上下文的情况下改变方向
- 批准下一步（或拒绝）
- 把任务再顺滑地交回给智能体
这种变化会体现在产品选择里：
- 暂停/继续成为一等公民功能 如果唯一的控制手段是“全部停止”，人类往往会犹豫到最后一刻才介入。
- 实时追踪（trace）变成主界面 运行日志（调用了哪些工具、输入/输出、过程状态）成为产品表面，而不是只给工程师看的调试面板。
- 交接边界被明确标记 系统主动划线：
- “我准备发出一条消息。”
- “我准备写入生产环境。”
- “我准备修改合同。”
- 安全的中断点（checkpoint） 好的系统会提供可回滚的检查点。 差的系统只让人类在“让它跑”与“杀掉它”之间二选一。
现实校验（Reality check）：不能中断，就谈不上控制
一个无法被中途打断的“智能体”，本质上更像是：带聊天窗的自动批处理任务。
它的失败模式也很类似：
- 范围失控：智能体因为发现相邻工作而不断扩展任务
- 工具误用：工具选对了，但上下文错了（或前提已经过时）
- 延迟掩盖风险：长时间运行会把一连串小错积累成大错，直到最后才暴露
- 静默副作用：系统改变世界的速度比人类察觉的速度更快
不太舒服但很关键的事实是：安全不只是写在 policy 里的条款。
安全是：运行中、随时可被人类接管与改写。
一个可落地的设计规则
如果你在做智能体系统，建议用这一条做底线：
每一次“破坏性动作”之前，都必须有一个可中断的时刻。
“破坏性”包括：
- 给真实的人发送消息
- 进行任何购买
- 发布任何内容
- 部署任何东西
- 修改持久化数据
而所谓“可中断的时刻”，不能是 200 毫秒闪过的弹窗。
它应该是一个有意识的交接：
- 将要发生什么
- 为什么会发生
- 依据是什么
- 用户可以改哪些参数/假设
因为最好的安全功能，不是更长的 policy。
而是一个很容易被停下来的系统。