Sign in Subscribe
AI Signals and Reality Checks

AI Signals & Reality Checks: Autonomy Budgets Become SLOs

Kaizhi Tang

• 7 min read
Minimal abstract gauge representing an autonomy budget
AI Signals & Reality Checks — Feb 20, 2026

AI Signals & Reality Checks (Feb 20, 2026)

Signal

“Autonomy” is being priced and bounded like uptime: teams are building autonomy budgets and treating them as SLOs.

A year ago, “agent autonomy” was mostly a vibe: let it do more stuff.

Now that agents touch real systems (tickets, refunds, deployments, outreach, calendar moves, vendor orders), autonomy is getting the same treatment we already give to production reliability:

  • define what’s allowed,
  • measure how often it happens,
  • cap the blast radius,
  • and ratchet up only with evidence.

The emerging pattern looks like an SRE-style control loop:

  1. Autonomy tiers (capabilities)
    • Tier 0: draft-only
    • Tier 1: execute low-risk actions (create ticket, schedule meeting)
    • Tier 2: execute actions with money/time impact (issue credits, reorder inventory)
    • Tier 3: execute changes with systemic impact (config, deployments, policy updates)
  2. A budget (rate + scope)
    • “Up to 20 auto-actions/day per workspace”
    • “Max $200/day in credits”
    • “Max 3 external emails/day unless whitelisted”
    • “No more than 1 production change/hour”
  3. A target (SLO-like goal)
    • “≥ 99% of agent actions require no human correction”
    • “≤ 0.5% actions trigger rollback”
    • “Median time-to-human-override < 60s”
  4. A burn alert (autonomy burn rate)
    • if the agent burns budget faster than expected, autonomy is throttled automatically.

Call it whatever you want—guardrails, policy, governance—but the shape is familiar: autonomy becomes an operational envelope.

Reality check

Budgets won’t prevent incidents unless you also build rollback mechanics and accounting. Otherwise autonomy just creeps until you’re debugging a “helpful” runaway system.

Three failure modes show up when teams implement “autonomy budgets” as simple counters:

  1. No real rollback, only “oops.” If an agent can create a mess in five tools but the only response is “notify a human,” you haven’t bounded risk—you’ve just improved observability.

Budgeting works only when you can reverse at roughly the same speed you can act:

  • undo/compensate transactions,
  • revert config diffs,
  • cancel outbound sends,
  • restore previous document versions,
  • and quarantine downstream effects.
  1. No cost model, so the budget is fake. Teams set caps like “20 actions/day” without distinguishing:
  • one action that posts a Slack message,
  • vs one action that triggers an expensive workflow,
  • vs one action that changes a production setting.

If the budget doesn’t map to real cost and blast radius, it becomes theater.

A practical fix is to attach a risk-weight to each tool/action:

  • low: reversible, internal, no money
  • medium: external comms, user-visible changes
  • high: money, production, compliance

Then your budget is not “20 actions,” but “20 risk points.”

  1. No human override path that is actually usable. In live operations, humans don’t want a PDF policy document. They need:
  • a single “pause autonomy” switch,
  • a per-tool kill switch,
  • and a clear escalation path when the agent is stuck.

If override requires three approvals and a Jira ticket, the agent will keep acting while everyone waits.

Second-order effect

Autonomy SLOs will force a new product primitive: “safe-to-run” as a first-class status.

Once you have budgets + rollback + accounting, you can expose something much more useful than a vague trust badge.

A mature agent system will show a compact status like:

  • Safe-to-run: Tier 2 (credits + scheduling)
  • Budget remaining: 6/20 risk points (resets in 14h)
  • Rollback readiness: 4/5 tools reversible
  • Last incident: 12 days ago (cause: ambiguous customer record)

This does two things:

  • It lets users decide when to grant more autonomy without reading a manifesto.
  • It forces vendors to compete on operational discipline: reversibility, auditability, and time-to-override.

What to watch (next 24–72h)

  • Do agent platforms ship a standard “autonomy budget” object (tiers, points, burn rate) that works across tools?
  • Do we see risk-weighted budgets replacing raw action counts?
  • Do product teams start publishing “rollback coverage” the same way we publish uptime?

Source note

中文翻译（全文）

AI 信号与现实校验（2026 年 2 月 20 日）

今日信号

“自治（autonomy）”正在像可用性一样被定价与边界化：团队开始建立自治预算，并把它当作一种 SLO 来运营。

一年前，“agent 自治”更多是一种氛围：让它多做点事。

当 agent 真正接入业务系统（工单、退款、部署、外呼、改日历、供应商下单）之后，自治开始被用我们熟悉的生产运维方式管理：

  • 先定义哪些动作允许发生，
  • 再衡量发生频率与质量，
  • 限制爆炸半径（blast radius），
  • 只有在证据充分时才逐步放权。

现在越来越多团队在做的，其实是一套类似 SRE 的闭环：

1）自治分层（能力等级）

  • 0 级：只起草，不执行
  • 1 级：执行低风险动作（建工单、排会议）
  • 2 级：执行涉及金钱/时间影响的动作（发放补偿、补货）
  • 3 级：执行系统性影响动作（配置、部署、策略更新）

2）预算（频率 + 范围）

  • “每个工作区每天最多 20 次自动执行”
  • “每天最多发放 $200 的补偿/credit”
  • “每天最多 3 封外部邮件（除非白名单）”
  • “生产环境每小时最多 1 次变更”

3）目标（类似 SLO 的指标）

  • “≥ 99% 的 agent 动作不需要人工纠正”
  • “≤ 0.5% 的动作触发回滚（rollback）”
  • “人工接管的中位耗时 < 60 秒”

4）燃烧告警（自治预算燃烧率）

  • 一旦预算消耗速度异常，系统自动降级/限流自治能力。

你可以叫它护栏、策略、治理——但形状已经很清晰：自治变成一个可运营的“动作边界（operational envelope）”。

现实校验

仅有“计数型预算”并不能防事故；预算必须与回滚机制和成本核算绑定，否则自治会“悄悄爬坡”，直到变成一次“看起来很帮忙”的失控事件。

团队在落地自治预算时，常见三种失败模式：

1）没有真实回滚，只有“事后道歉”。 如果 agent 能在 5 个工具里制造连锁改动，但你的应对只是“通知人工”，那你并没有真正限制风险——你只是提高了可观测性。

预算要真正有效，必须做到：动作能多快执行，就能多快逆转/补偿，例如：

  • 撤销/补偿交易（compensating transactions）
  • 回滚配置 diff
  • 取消外发
  • 恢复文档前一版本
  • 隔离下游影响

2）没有成本模型，预算就会变成摆设。 很多团队会设定“每天最多 20 个动作”，却没有区分：

  • 发一条 Slack 消息的动作，
  • 触发一次昂贵工作流的动作，
  • 修改生产配置的动作。

如果预算不能映射到真实成本与爆炸半径，它就会变成“透明度表演”。

一个可行做法是给每个工具/动作附上风险权重（risk weight）：

  • 低：可逆、内部、无金钱
  • 中：外部沟通、用户可见改动
  • 高：金钱、生产环境、合规相关

于是预算就不是“20 个动作”，而是**“20 个风险点（risk points）”。**

3）没有真正可用的人工接管路径。 在真实运营里，人不需要一份 PDF 策略文档。 他们需要：

  • 一个“一键暂停自治”的总开关，
  • 每个高风险工具的 kill switch，
  • 以及 agent 卡住时的明确升级/处理流程。

如果接管需要三层审批和一张 Jira 工单，那么在大家等待的过程中，agent 仍然会继续行动。

二阶推演

自治 SLO 会逼出一个新的产品原语：把“可安全运行（safe-to-run）”变成一等状态。

当你同时具备预算 + 回滚 + 核算之后，就可以对外呈现比“信任徽章”更有用的东西。

一个成熟的 agent 系统，应该能展示类似这样的紧凑状态：

  • 可安全运行：2 级（补偿 + 排程）
  • 剩余预算： 6/20 风险点（14 小时后重置）
  • 回滚就绪度： 5 个工具里 4 个可逆
  • 最近一次事故： 12 天前（原因：客户记录歧义）

这会带来两个改变：

  • 用户可以在不读“宣言”的情况下，判断是否要进一步放权。
  • 供应商将不得不在“运维纪律”上竞争：可逆性、可审计性、人工接管时延。

未来 24–72 小时观察点

  • agent 平台是否会推出标准化的“自治预算对象”（等级、点数、燃烧率），并能跨工具使用？
  • 风险加权预算会不会逐步替代“纯动作计数”？
  • 产品团队会不会像公布 uptime 一样，开始公布“回滚覆盖率”？

参考