Product

Auto Mode: How an Agent Decides What It May Do Alone

Auto Mode checks every agent write against what you asked for before it runs, and every write ends in one of four outcomes. Here's how Manual, Auto, Tool Permissions and runbook effects fit together, and why every uncertain path ends with a person.

Cover Image for Auto Mode: How an Agent Decides What It May Do Alone

Auto Mode: How an Agent Decides What It May Do Alone

An investigation finishes at 02:40. The cause is clear, the fix is a one-line change, and the agent is ready to open the merge request. The fix is probably right. What's open is whether anyone needs to be awake for it.

Ask for a person's approval on everything and you've rebuilt the pager with extra steps. Approve nothing and you've handed production to software that has never been on call. Neither is an answer a senior engineer would sign off on.

Frontier Investigation Agents find the why, and engineers approve the fix. Auto Mode is how a team decides which fixes need that approval, call by call, without approving every keystroke.

Why the usual approaches break

Approve everything. Every write pauses for a click. People stop reading the cards and click through. The control turns into a ritual, and the ritual is the risk.

Allowlist by tool. Mark a tool safe and every call to it runs. But a tool isn't safe or unsafe. Creating a GitLab issue and deleting a project can sit behind the same connection. An allowlist can't see intent.

Trust the prompt. Tell the agent to be careful and hope. A system prompt is advice. It doesn't stop a call.

What's missing is a decision per call: does this write match what the person asked for, and what happens if it's wrong?

What Auto Mode is

Auto Mode is one setting per workspace: Manual or Auto. New workspaces start in Auto. The choice applies to every conversation in the workspace, including automations and subagents, and it takes effect immediately.

In Auto, every catalogued write (a tool call CloudThinker recognizes as changing something) is checked by an AI safety classifier before it runs. Catalogued reads skip the classifier. Investigation stays fast, and the check sits where the risk is.

In Manual, you approve writes yourself, tool by tool, through Tool Permissions.

01Manual

You set each tool

  • Always allowThe tool runs without a pause
  • Needs approvalOne inline approval per call, reads included
  • Never allowThe tool is unavailable to the agent

Tool Permissions decide

02Auto

Each write is checked

  • Catalogued readsSkip the classifier
  • Catalogued writesGet a decision before they run
  • Unclassifiable toolsTreated as writes

The default for new workspaces

One setting per workspace. It covers chats, automations and subagents.

Four outcomes per write

Each catalogued write in Auto gets one of four decisions, and the chat labels the action with the result.

01Allowed

Runs

The chat records that Auto Mode allowed it.

02Needs approval

Pauses one call

A person chooses Proceed or Cancel on that tool call.

03Escalated

Stops and alerts

High-severity alert; only the same user can approve one exact retry.

04Denied

Never runs

Blocked by policy. No chat approval overrides it.

The four decisions a catalogued write can receive in Auto.

Allowed. The write runs, and the chat records "Auto Mode allowed this" beside it.

Needs your approval. The agent pauses for one inline approval on that tool call. You review the operation and choose Proceed or Cancel. The rest of the conversation isn't held.

Escalated. The agent stops the action and raises a high-severity alert. Only the same authenticated user can approve one exact, unchanged retry, from a later explicit message in the same conversation, before the escalation expires. An escalation also latches new writes to the escalated path for the rest of that turn, so later writes in that turn can't slip past it.

Denied by policy. The write never runs, and no chat approval can override it.

How the classifier draws the line

Auto Mode allows external changes that match your requested goal and scope. Ask it to file and assign a GitLab issue, and it doesn't need you to spell out each API call.

Some things still wait for a person: actions outside the requested scope, actions with unclear effects, and secret reads. Authenticating to the intended provider with a connected credential doesn't count as disclosing a secret. Destructive actions escalate. Prohibited actions and secret disclosure stay blocked.

That's the difference from an allowlist. The same tool can get different decisions depending on what you asked for and what the call would do.

When the classifier isn't sure

Two edge cases decide whether a safety system is honest.

A tool CloudThinker can't classify is treated as a write. It goes to the classifier instead of slipping through as a read. For an MCP connection tool, its Needs approval setting is what marks it a write.

If the classifier can't finish its check, the write pauses. The chat marks it "Auto Mode could not finish its safety check", and a person decides. A failed check never becomes a silent allow.

01Request

A tool call

The agent wants to use a connection tool.

02Classify

Read or write

Known reads run. Anything unclassifiable counts as a write.

03Check

Goal and scope

The classifier weighs the write against what you asked for.

04Decide

One of four

If the check cannot finish, the write pauses for a person.

How a call is decided in an Auto workspace. When the check is unsure, a person decides.

Manual and Tool Permissions

Manual is for teams that want every connection tool under direct control. In Settings → Approval → Tool Permissions, each tool is set to Always allow, Needs approval or Never allow.

Manual can be stricter than Auto in one way: a read tool set to Needs approval pauses too. That's useful for a tool that reads sensitive data.

In Auto, the per-tool settings aren't evaluated. Each row shows a read-only badge instead: Classifier for a write, Allowed for a read.

Runbooks carry their own effects

Inside Resolve, remediation often comes from a runbook. Resolve extracts mutating commands from a runbook's code blocks, and each gets one of three effects: Allow, Require Approval or Deny.

A command with no matching effect defaults to Require Approval, so an unrecognized command from an external runbook waits for a person. Read-only investigation commands don't need an effect. Per-command controls are available for manually uploaded runbooks, and Execution history keeps the source and command context for every run.

The CLI follows the same rule

The Agent CLI uses the workspace mode too. You can check or switch it from the terminal:

/cloudthinker auto
/cloudthinker auto on
/cloudthinker auto off

Switching changes the whole workspace and needs the workspace-settings edit permission. There's no per-session override and no flag that bypasses approval from a laptop. Commands that run on the developer's own machine aren't gated by Auto Mode. Only cloud commands are.

The design decisions

One setting per workspace. Per-chat modes would let the strictness of production depend on which chat someone opened. A workspace is the boundary teams already reason about.

Decide per call, not per tool. Intent and scope live in the call, so that's where the decision belongs.

Fail toward a person. Unclassifiable tools count as writes. A classifier that can't finish pauses. Escalations latch for the turn.

Some lines don't move. Denied by policy can't be overridden in chat. Prohibited actions and secret disclosure stay blocked whatever the mode.

Connections stay the outer limit. No decision lets an agent do more than its connection's permissions allow. See The Agent Never Holds Your Keys.

Every decision is visible. The tool call and its outcome stay in the conversation. Agent actions also land in the organization's audit trail.

Honest limits

  • The classifier is an AI model. It judges goal and scope, and judgment can be wrong. That's why destructive actions escalate rather than run.
  • In Auto, a tool set to Never allow isn't held by that setting. It receives an Auto Mode decision like any other write. If a tool must stay unavailable regardless of context, use Manual.
  • Commands on a developer's own machine aren't gated. Auto Mode covers cloud commands.
  • An inline approval applies only to the call that requested it. Approving once doesn't approve the next one, except a CLI command a workspace owner or admin chooses to trust.

Try it

Open a chat, check the approval control beside the model picker, and try a scoped write:

"Open a GitLab issue for the checkout latency regression and assign it to the on-call."

"Draft a merge request that fixes the connection pool setting in the checkout service."

"Explain why that last action needed my approval."

Compare what runs alone and what stops.

Related reading

automodeapprovalsaisafetyguardrailshumanintheloopagenticopstoolpermissionscloudthinker