What An AI Agent Should Always Ask You First

An agent that works in your own files, apps and browser will sooner or later reach a button that matters: pay, sign up, agree, delete for good. Asking you about everything teaches it to hedge. Asking about nothing hands it your card. What we settled on is a short rule for what always asks, and a plain answer to who gives the yes: you, on the device you are at, with that device's own check.

Why not have the agent ask about everything?

Because asking is not free. When we wrote down the agent loop, one failure we fixed was an agent handing back what it could have decided. A rule that holds every step for a yes makes that failure the default.

So most of what an agent does in yarnnn is governed by settings you already hold, not by its own caution. Each chat has a mode: Auto runs what you connected and records it, Ask first holds every change for your yes, Plan changes nothing until you accept a plan. Each tool of a connection is on, ask first, or off. An agent does everything those settings allow, and stops only where only you can act — a sign-in, an act only you can approve, a decision it cannot reasonably make for you.

Most of it can also be undone. An edited file is versioned; a deleted one goes to Trash — the workspace's, or your Mac's — and comes back with Restore. Those wait for nothing beyond the mode.

So what always asks?

An act always asks when it does one of three things:

• It commits you to someone else — paying, creating an account, accepting terms, deleting an account.
• It changes the machine itself — installing or removing a program.
• It cannot be brought back — deleting something for good.

These ask in every mode, Auto included, and in a job running on its own while you sleep. That has a cost we accepted: a job that reaches a purchase at 3 a.m. stops at the question, shows as Needs you, and the purchase waits for the morning. A time-bound one can be lost.

It started as a list. For a while we called them the four — paying, signing up, accepting terms, closing an account. Then installing and removing a program joined, then deleting for good, and a count kept inviting the question of what came next. A rule answers it. A new kind of act, or of machine, adds a row to a table, never logic.

Not on it, on purpose: sending and posting. Those ask the way you set them — a mail tool on Ask first asks every time. The rule covers what commits you or cannot be taken back, not everything that leaves the room.

Who decides that an act is one of them?

Code that sees the act, never the model.

The agent is not handed a paragraph of rules to interpret. It asks for an act and is told done, waiting or refused. Installing a program and deleting for good are typed acts, known for certain. A connection's tool is read by its own name: one that subscribes, creates an order or starts a trial asks; one that only lists or reads does not. Before the agent presses a control on a page or in a Mac app, its label is read against the same word list.

That has a limit we would rather state than hide. Knowing an act from its words cannot be complete. A button with no label, or an unusual word, is not caught; it runs as any press does, and History marks it. So the settings say whenever yarnnn can tell an act is one of them, not every time. Where a name cannot tell — a service's delete might keep a trash of its own — it asks anyway.

Why is an Allow button not enough?

Because the agent has hands.

An agent that works in your browser and your apps presses buttons in your session. A plain Allow pressed in a session proves nothing about who pressed it — and the agent's own hands can reach a session. So these acts are not answered with a button. They are approved with the device's own check of you: Touch ID or the Mac's password, Face ID or a fingerprint on a phone, a browser's passkey (Touch ID, Windows Hello). Nobody presses a finger from a distance.

What you approve is exact. When the act is held, what would be done is frozen and hashed. Your device words its check from that frozen act, and a key that lives on the device signs it. The server checks the signature against the act it froze, and the act runs with exactly those inputs, once. A page that lies to your device about the act gets a signature over its lie, which the server refuses. A yes is spent whatever comes of it; it is never used again.

Then it is on the record, like every change in the workspace: Approved with Touch ID on your device, by name.

Why does each device approve for itself?

Because the first version depended on which key you had set up, not on where you were.

A card could say both Approve on your iPhone and Approve with your passkey. On our own pass on a Mac, an approval sent us to a browser to look for a passkey while the Mac under our hand waited. It should simply have asked for Touch ID.

The rule now is one line: every device stands alone — a fresh sign-in, then that device's own check. No device approves another.

• A card shows one action, named by the device's own check: Approve with Touch ID, with Face ID, with your passkey. The first time, that press sets the device up.
• Setting a device up starts with a fresh sign-in — your password or your provider's, in the last ten minutes. Never an emailed code or a magic link: agents read mail.
• A phone is told only when no device in front of you can answer. At a Mac that approves, your phone stays quiet.
• Every device added is mailed to you and shown on your other devices, and any device can be removed from any other.

That design gave something up. An earlier rule had a new device approved from one you already held; we withdrew it. Now whoever holds your sign-in can add a device of their own. The mail and the notice tell you, and removing the device cleans up; neither prevents it. That is how most platforms treat a passkey. A check proves someone is at a device. Only the sign-in says whose it is.

Doesn't that mean pressing Touch ID twenty times?

It would, without bounds. There are three.

Asking is bounded. One approval waits at a time. After a No, that kind of act at that place is not asked again in the conversation until you write there. At most six are asked an hour.

An errand can be approved ahead. Before the work, the agent asks once for its limits — what, on which site, at most how much — and you sign them. A press that fits goes through once, within the hour, in that conversation; one that does not is asked at the press. Code says what fits, never the model. Deleting an account is never approved ahead.

A list can be approved in one check. Two to twenty deletes for good, installs or removals, one kind to a list, each item shown by name. Each act takes its own item once, within the hour, in that conversation; anything not on the list is asked as ever.

One more figure sits beside these: what a request may cost before your agent stops to ask — $1, $3, $10, or Don't ask, with $3 as the default. It always stops when the workspace's usage runs out.

Where is all of this set?

In Customize › Approvals, beside Connections — because what your agents ask you first is part of how they work for you, not a property of your account.

Asks you first is one row per act. Five have a switch, and turning one off needs the same approval; off, that act runs as the chat's mode says. Installing and removing a program say Always. Devices that approve is one row per device, each with its Remove.

What does an approval mean, then?

Three things are enough to hold in mind: the mode, how much this chat asks; what always asks, the rule above; and what you have allowed, your connections, folders and sites.

Inside that, an approval is narrow on purpose: one act, one list or one errand's limits, read in full; signed on the device in your hand by its own check; run exactly as shown; kept in the record under your name. Everything else the agent decides, does and tells you about — which is the point of handing it the work.

The limits, plainly, beyond the two above. The Windows app approves with the browser's passkey until Windows Hello is built into it. And parts of this are newer than the stores: phones approve once the phone apps' next releases reach them, and the browser's half — a press held on a page, an errand approved ahead — comes with a Chrome extension update that is in review as we write.

---

The record each approval lands in is described in Every Change, Signed By Whoever Made It.