Skip to content

People retain authority

Published: at 09:00 AM

If a system can’t pause and hand a decision to a human with full context, it isn’t finished.

I’ve said a version of that for a while. It’s also on the Superprocess homepage, word for word: People retain authority. This year it stopped being a slogan for me and turned into specific design decisions, in very different products, often because something went wrong first.

Here are the five places it shows up.

1. Authority lives in the system, not the prompt

MakerLord is an assistant for people building electronics. Most AI assistants will cheerfully tell you to wire an LED straight to 5 V. In MakerLord the model proposes and explains, and deterministic rules decide. Gates like “open the power gate” or “generate firmware” are enforced by the engine, not by asking the model nicely.

The line from its README I like best:

There is no dismiss_finding tool. You cannot call what was never defined.

You can’t prompt your way out of a safety finding because the capability doesn’t exist. That’s the difference between authority and politeness. A system prompt that says “always ask before doing X” is a request. A tool that was never defined is a fact.

2. An approval is a decision, not a notification

At Superprocess, routine work runs inside policy limits, and material or uncertain exceptions pause for a named approver with the case attached. Autonomy grows in steps: assist, then recommend, then act within limits.

The hard part is not adding the pause. It’s what the person sees when it pauses. I wrote about this last month in What should an approval gate show the reviewer?. An approval request that says “please review” and attaches an invoice doesn’t reduce anyone’s work. It sends them off to rebuild the case themselves. A good gate shows why the process stopped, the evidence, the policy result and the proposed action, so the reviewer can actually decide.

Waiting has to be cheap too. A process that pauses for a person might wait for days. If waiting is expensive or fragile, people start removing the gates. That’s why durable execution matters so much to this; I wrote about it in What a durable process does while nothing happens.

In the lab, SuperPipeline treats approval gates as first-class, not bolted on: agents move cards through stages, and some stages wait for a person. The plan is for those approvals to reach me in SuperMessage, in the same rooms where I talk to the agents, rather than in yet another inbox.

3. Limit what an agent can reach, not just what it can do

On 3 and 4 October my agents needed somewhere to publish their work. The board stores references, not content, and the runtime only shows a workspace while it’s running. So they did what a resourceful assistant does: they published gists under my personal GitHub account. Two of them were public.

Nobody approved that, because nobody had to. The agent had a tool that could publish, so it published. I made the gists secret and removed gh from the agent host. Then I started SuperLibrary, a place where agents’ work is stored with its provenance, so that “publish this” has a safe answer.

The lesson: approvals only cover actions you thought to gate. The rest of authority is reach. If an agent can touch something, assume it eventually will.

4. Nobody should hold the credential

A week later the same question came up with credentials. I wanted an agent to post to X for a marketing project, and that raised the question of where a write-scoped token for my account should live. The honest answer was: not with the agent.

SuperToolkit shipped its first release yesterday. The agent asks for an effect by name; a broker holds the secret and applies it on the way out. Its invariant:

The agent never holds, reads, or receives a credential.

It also has a limitations page with a heading I’m quite proud of: The one failure mode that cannot be fixed. A client that ignores proxy configuration goes around the broker and fails silently. I’d rather write that down than pretend the boundary is perfect.

5. The record of judgment can’t be rewritten

The last piece is memory. When a person or a rubric judges an agent’s work, that judgment has to stay what it was. In SuperWitness verdicts are append-only: database triggers refuse to update or delete them. You can add a new verdict. You can’t quietly edit the old one.

Authority you can’t audit afterwards isn’t authority. It’s a story you tell about what probably happened.

What it costs

This isn’t free. Every gate is friction, every broker is a hop, every append-only table is data you keep forever. Some days the agents would clearly be faster without me.

But the work I care about most is work where a mistake costs real money or real trust: an invoice, a production machine, a circuit with a battery in it. There, “the agent was probably right” isn’t good enough. Autonomy should grow, and it should grow inside limits a person set and can see.

That’s the rule. Everything else is implementation.


Previous Post
How I got here
Next Post
The agent platform I kept rebuilding