Consentful Automation
An experiment in designing automation that asks permission at the right grain: autonomy the user invited, scoped, and can renegotiate.
Consentful automation is automation the user invited. The system's authority was granted at a specific grain, is visible at all times, and can be renegotiated without ceremony. I'm prototyping what that consent surface looks like, because I've watched automation fail the same way over and over: not by being wrong, but by being surprising.
An action can be technically correct and still feel like a violation. The dispatcher whose board reshuffled itself isn't asking "was that optimal?" They're asking "who told you that you could do that?" No accuracy metric fixes that question. Only design does — and receipts for the call.
The toggle is the wrong grain
Most products treat consent as a switch. Turn on the smart feature, and the system infers the rest forever. But nobody's appetite for automation is constant. It moves with workload, with confidence in the system, and above all with consequence. The same dispatcher who happily lets software sequence routine jobs on a calm Tuesday wants her hands on every decision the morning a storm floods half the city with emergency calls, because that's the morning her judgment is the product.
A binary toggle can't express any of that. It forces a choice between "trust completely" and "do everything myself," and people resolve the false choice by turning the feature off. A consent model with two settings can't survive real work.
The prototype treats the automation's mandate as a visible, adjustable contract with three tiers: what the system may prepare (drafts, suggestions, staged changes; zero risk, always allowed), what it may execute with a confirmation, and what it may do silently on your behalf. Every capability lives at exactly one tier, and the user can move it per capability, not per feature. Watch a morning run below — then grab a chip mid-stream and watch whatever is already in motion follow the new grain, not just the next event.
Two properties turned out to matter more than I expected. First, the contract has to be inspectable in one glance: "what can this thing currently do without me?" should never require archaeology through a settings tree. If the user can't reconstruct the system's authority from memory, the system has more authority than they granted, by definition. Second, narrowing must be free. The moment pulling permission back feels like punishing the product, or triggers a re-onboarding, people stop adjusting and start resenting. Consent that's expensive to withdraw isn't consent.
Earning quiet
The end state isn't maximal automation. It's earned quiet. Early on, the system should be almost annoyingly legible, announcing intent, showing scope, and confirming small things. That verbosity is not friction to optimize away; it's how the user builds a mental model of the shape of the system's decisions. Once they can predict what it will do, confirmations become redundant, and they promote capabilities up the tiers. The system gets quieter because trust accrued.
This mirrors how humans delegate. You don't hand a new hire your calendar and your signature on day one. You watch them prepare, then approve their work, then stop checking. Autonomy is granted in grains, in response to demonstrated judgment, and it's always revocable. Software agents are the first automation general enough to deserve that same protocol, and interfaces, as far as I can tell, haven't built it yet. That gap is the experiment — especially for operators who own the outcome.