誰來踩煞車？關於智能體治理的 5 篇文章，涵蓋預算、身份、停止權限與 Harness 設計

Once an agent can run for hours, deploy things and spend money, the interesting question stops being "is the model smart enough?" and becomes "who is allowed to stop it, and how?" I've been collecting posts from the Redreamality blog that treat that as an engineering problem rather than a vibe. Here are five that each attack a different piece of it.

1. Soft budgets send email, hard budgets send errors

The scenario is painfully familiar: an agent ships a small demo overnight, it wires up paid APIs and auto-scaling compute, and by morning there's a "you're near your budget" email sitting next to a much bigger bill. The post builds on Simon Willison's argument that usage-billed services should ship with hard caps on by default, so that the next billable request simply fails once the line is crossed. What I liked is the framing as a third cost ledger: not the agent's own tokens, and not wasteful loops inside a trajectory, but the downstream services an agent leaves running after the session ends. It also gives a useful test for any vendor console: don't ask whether there's a "Budget" page, ask what happens after the trigger. Worth reading in full: why services agents deploy need a kill switch, not a warning.

2. When the agent gets its own work email

Google's Gemini Enterprise announcement gave agents coworker status: a dedicated mailbox, calendar, Drive, a directory entry, and the ability to be @-mentioned in Chat or tagged in a Doc comment. Rather than retelling the keynote, this write-up pulls out three things a company has to settle before rolling that out: whose identity the agent acts under, whether you can trace who actually asked it to do something, and who can cap its spending. The author's point is that putting all three on an announcement page is not the same as specifying them, and the gaps show up later. There's a practical checklist at the end. See the identity, audit and spend-cap questions behind coworker agents.

3. Agents that finish the job and keep going anyway

This one covers a preprint that names a failure mode I recognized immediately: the hard goal is already met, but the loop keeps adding abstractions, extra checks and fixes for complexity it invented itself. The authors call it "LLM Parkinsonism", with a careful note that it's a description of trajectory shape, not a clinical claim, and propose Global Executive Control, which separates generating actions from deciding whether the project should continue. On their benchmark with a 40k-token ceiling, success stayed around 96.5% while mean token use dropped by about 36% compared with local control. The takeaway is structural: stop authority belongs outside the self-conditioned loop, not in a model that's merely better at saying "done". Read the breakdown of project-level stop authority for agents.

4. A harness you can install instead of hand-rolling

Most teams still treat the agent loop's control code as private glue: when to compress context, when a tool must wait for a human, how a session resumes. This post looks at Strands Harness, which ships that layer as an installable package with overridable defaults and an SDK underneath for lifecycle hooks, guardrails, sessions and evals. The author is appropriately skeptical about the vendor's roughly 28% token-cost claim and separates sourced numbers from marketing. The four questions it uses to judge any harness (context economics, structural versus prompt-based control, where audit evidence lives, and whether the prototype is the same object you deploy) are reusable well beyond this one product. Here's the analysis of Strands as a productized agent harness.

5. Don't collapse the harness objective into one number

The last piece covers an Adobe Research paper arguing that a harness is a design surface with several objectives at once: a version that is accurate but never refuses an unsafe request, or that burns ten times the tokens, still fails in production. Their method lets a coding agent rewrite full Python harnesses while seeing accuracy, behavioral safety and token cost together in a single search phase, and it beats an "accuracy first, then trim tokens" approach on both safety and cost. If you tune prompts or agent scaffolding against a single score, this is a good corrective. Details are in this summary of multi-objective harness search.

The common thread

All five land in the same place: the controls that matter, such as budgets, identity, stopping and safety, should live in structure the agent can't talk its way around, not in a polite instruction. If you only read one, pick whichever matches the last time something ran longer or cost more than you expected.