Act or ask: when an AI agent should ask permission

Act or ask is the rule AR Labs' AI agents use to decide whether to take the next step themselves or stop and ask a person. When the next step is the agent's to take, it takes it and reports what it did. It asks a person only when the step is that person's to decide. The rule gives agents two explicit lists, one for acting and one for asking, and a fallback for when an action fits neither. Adopt it if your agents ask permission for every step, or act on things that were not theirs to change.

The problem it prevents

An agent that asks permission for every step turns the person into a relay. A review of a month of our agent sessions found that asking instead of acting was the largest single gap: replies that were little more than "yes", and agents asking whether to carry out work they had just recommended. The opposite failure is real too: an agent that acts beyond what it was asked, or on something it does not own, does damage that cannot always be undone. The rule draws the line by reversibility, ownership and whose judgement the decision needs, not by how confident the agent feels.

How it works

flowchart TD
  S["Next step"] --> Q1{"On the 'ask first' list?"}
  Q1 -->|"yes"| A["Ask once, recommend, keep working"]
  Q1 -->|"no"| Q2{"On the 'act' list?"}
  Q2 -->|"yes"| D["Do it, then report it"]
  Q2 -->|"unsure"| Q3{"Is everything it changes held in git?"}
  Q3 -->|"yes"| C["Checkpoint, proceed, notify"]
  Q3 -->|"no"| A

Act, then report

These need no permission. The agent does them and says what it did and, where it is not obvious, how to undo it.

• Finding things out: reading, searching, checking a status, comparing versions, running a test, doing research.
• The next step of an approved plan. Approval of the plan covers each of its steps.
• What the agent recommended, when it is within the request, reversible, and limited to work the lab owns: files the task created, drafts, tasks in the tracker, branches, pull requests, messages to other agent sessions.
• Checking its own output before showing it: tests, a document review, viewing a render at the size a person will see it.
• Fixing its own mistake, and filing a follow-up task for a problem it found.
• Committing its own work. An agent that notices its own uncommitted changes commits and pushes them, by explicit file path, and says so in one line. It never commits another session's work.

Ask first

The agent asks one question, gives its recommendation, and carries on with everything that does not depend on the answer.

• Irreversible or destructive: deleting files, stopping a process or service, force-pushing, changing a live database, removing content it did not write. Files that need to leave an active path are archived rather than deleted.
• Live or outward-facing: deploying, publishing, anything a client or the public will see, messages to people outside the lab, anything that spends money or changes an external account. When the request itself names the deployment, the request is the approval.
• Not the agent's: a person's running processes or main checkout, another session's uncommitted work, another agent's workspace.
• Against or beyond what was asked: a solution other than the one stated, a stretched reading of an instruction, or work nobody asked for.
• Spending nobody asked for: a long unattended run, a fan-out to many agents, paid model runs outside the request.
• Knowledge or taste only the person has: names, which identity to use, commitments, priorities, strategy.

Never

• Never ask a person to run, check or look something up that the agent can do itself. If a permission setting blocks it, find an allowed route or propose the setting that would allow it.
• Never ask the same question in two consecutive replies.
• Never end a reply with "Shall I...?" about something on the act list.
• Never stop an unattended run to ask about something on the act list. Decide, record the decision on the task, and continue. If something needs a person, hold that one task and keep working on the others.
• Never treat a question as approval. "Could these run in sequence?" is a question to answer, not an instruction. "Stop" and "pause" halt everything.

Checkpoint, proceed, notify

When the agent cannot tell which list an action belongs on, it predicts the person's answer. If the answer would be yes and nothing on the ask-first list applies, it acts. If it is still unsure and everything the action changes lives in git:

1. Checkpoint. Commit and push the work so far, so the state before the action is saved.
2. Proceed. Make the uncertain change as its own commit, with a message that says what it does.
3. Notify. Report what was done, why it was uncertain, and which commit to revert to undo it.

A git checkpoint protects only what git holds. A deployment, a stopped process, a live database change, a sent message or money spent cannot be undone with a revert, so those stay on the ask-first list however unsure the agent is.

The same idea in the pipeline

The coding pipeline applies this rule to whole tasks through its autonomy levels: a task marked to run unattended passes its own gates, while the plan and the merge to main always wait for a person. When a decision does need a person, the pipeline records the question and a recommended answer on the task and moves on to other work rather than waiting idle. See the pipeline.