I Let AI Agents Act Without Asking. Here’s Where I Stop Them.

On August 10, I found a gap in the approval path for an App Store submission. The first repair is in the diff below. A release approval that had been scoped only to an app became scoped to an app, a plan, a version, and a build.

That diff is an intermediate artifact, not the whole current flow. The current path is stricter: a one-time Telegram challenge is consumed, an approval receipt is reserved for a fingerprint of the exact staged release, and the Board checks the plan, version, and build again before it starts the submit.

This is the boundary I need in a business run by agents. I want the work to move fast. I also want a yes from me to mean yes to one concrete thing, not a general permission that survives after the thing changes.

What can an AI agent do without asking?

I let an agent proceed when the work is reversible and stays inside my own system. It can pull evidence, write a draft, run tests, prepare a release plan, or stage a post for review. I can inspect that work, replace it, or throw it away before it reaches anyone.

That covers a lot. The agent does not wait for me to approve every small internal step. It leaves me a prepared decision instead of a pile of chores.

The first question I ask is: if this goes wrong, can I undo it without involving somebody outside my system? If I can, I usually let it run.

When can an external action still run automatically?

Reversible is not the only authority path. Some external work has standing authorization because it is bounded and has a clear operating policy.

For example, a routine App Store release can proceed through archive, signing, upload, attachment, and submission when the release gate classifies the change as low ambiguity. The gate escalates specific cases, including a first submission, a pricing or privacy change, a user-facing UI change, or an independent review concern. Store growth changes have their own cooldown and evidence rules before they apply.

I like this distinction because it prevents the system from treating every external action the same. “External” is too broad. A routine release with a known policy is different from a new price, a public marketing post, or an increase in ad spend.

This is why I call my dashboard the Board. It is the place where I see the evidence behind an exception, rather than a chat button that tells me almost nothing about what will happen next.

What was wrong with an app-only approval?

Nothing had been submitted incorrectly. The problem was found before that could happen.

An app-only approval authenticated a request in the context of one app. It did not carry enough identity to make a delayed approval safe after the release plan had changed. A build can be replaced after validation, a plan can be revised, or a release can move from one version to the next. The click supplies human intent. The system has to preserve what that intent was attached to.

The August 10 diff was the first useful repair because it made the missing identity visible:

app \0 submit \0 plan_id \0 version \0 build_id

The current flow makes the same rule durable. Before consuming an escalated approval, it compares the current staged release to the plan ID, version, and build ID that were shown in the challenge. If any field differs, it refuses with: staged release changed; request a fresh approval.

I reran the focused Board approval suite for this article on August 17: 30 tests passed. The important current regression is not that a button returns success. It covers the stale-artifact path: after an approval receipt is reserved, the submit path still fails cleanly if the staged release no longer matches, and the receipt is settled as failed rather than being left in an ambiguous state.

How do I make a human approval mean one thing?

I use two questions:

1. Can I reverse this without involving someone outside my system?
2. If I need a tap, can I bind it to the exact artifact, audience, amount, or change that will happen?

The first answer tells me whether an agent can move now. The second tells me whether an approval screen is real or just theater.

“Send the campaign” is too broad if the recipients or copy can change after I look. “Submit the app” is too broad if the build can change after I look. “Publish the blog post” is too broad if the staged draft can be replaced later.

The one-time approval is not a vote of confidence in the agent. It is a receipt for a specific action. The system should treat an old receipt as expired when the action it describes is no longer the action in front of it.

Why does this make autonomy more useful?

Useful autonomy means I wake up to prepared work and a few decisions that are actually mine. I am still in the loop where the consequence is public, costly, or outside the rules I have already set.

I learned this after launching Jobim and trying to operate content through Telegram. One bot per app and more bots for other work became hard to review and hard to steer as I released more apps. The issue was not that I needed more notifications. I needed the context, evidence, and decision to stay together.

The Board gives me that. The agent can do the boring, reversible work. A bounded policy can cover the routine work. And when something falls outside either category, I get one decision about one immutable thing.

That is the rule I would copy into another agent system:

Let agents move reversible work forward. Use standing authority only when its scope is explicit. For every exception, bind one approval to one immutable artifact, and make it expire when that artifact changes.