SyntrumDocs

Agent autonomy

This page goes deeper on the second plane — an agent's independence — and shows exactly how a supervision mode becomes the stream of approvals you see in your inbox. If you haven't met the modes yet, start with Supervision & modes.

The core principle: reads flow, writes gate#

Autonomy only ever concerns writes — actions that change something in the outside world (send an email, update a record, create an event, delete a file). Reads are never gated:

Reads always flow; supervision gates writes. An agent can always observe — that's how it runs the Observe → Understand → Decide → Act → Report loop. Supervision decides what happens at Act: does the write run on its own, wait for you, or get refused?

So an agent on the strictest possible setting is still fully useful: it reads, understands, decides, and drafts. It just doesn't complete a write without you.

How each mode gates writes#

Mode Reads Writes
Inherit Flow Whatever the workspace floor says
Strict Flow Every write → approval
Balanced Flow The workspace's sensitive-action rules apply as-is
Autonomous Flow Runs, except where the workspace requires approval or blocks; blocks always hold

The workspace floor those modes lean on is the Safety page — six sensitive categories, each set to allow, approval, or block.

How an approval gets generated#

When an agent reaches the Act step and wants to make a change, the runtime resolves the cascade for that exact action (Workspace floor → Agent mode → Tool pin, strictest wins, block is a floor) and does one of three things:

  1. Allow → the action executes immediately.
  2. Approval → the runtime parks the task and creates an approval card. The agent doesn't wait idle on everything else — it moves on to other work and returns to this task once you decide.
  3. Block → the action is refused and logged; the agent adapts or routes around it.

The parked action shows up in two places: the agent's Live and Tasks tabs ("Needs Your Decision" / "Waiting for Approval") and your workspace-wide Approvals queue. Each card carries the consequence ("After approval: …"), a risk level, the agent's confidence, and how long it's been waiting.

Because approvals park rather than block the whole agent, raising an agent's oversight (say, moving it to Strict) makes it ask more without making it stall. It keeps reading, planning, and drafting while your decisions queue up.

"Why did my agent ask?" — provenance#

Every gated decision records which level and rule produced it. That provenance is surfaced so you never have to guess:

  • On an approval card, a quiet caption explains the cause — e.g. "Held because Gmail on this agent is pinned to Require approval."
  • In the Test an action simulator, the result names the deciding level — workspace, agent, or tool — plus the underlying reasons.
  • In the Audit log, each decision is stored with its full provenance and who set the rule.

This makes autonomy tunable by evidence rather than trial and error:

  • Agent asking too often? The provenance tells you whether it's the workspace floor, the agent's mode, or a specific tool pin — loosen that one level.
  • Agent acting too freely? Tighten the level you want to constrain — pin the agent to Strict, or set the risky tool to Asks first.

Autonomy while a human is in control#

When you Take Over an agent from its workspace, the calculus changes: gated actions execute as your decision and are audited as taken by you. Releasing control returns the agent to its configured mode. Take-over is the escape hatch for when you'd rather drive directly than approve step by step.

Pinned autonomy stops following the workspace#

Remember that an agent on Inherit moves with the workspace floor, but a pinned mode holds fast. If you've raised one agent to Autonomous and later tighten the workspace, that pinned agent won't tighten with everyone else until you Reset to workspace default. Pins are deliberate — see Pinned vs. Inherited.

Resolving approvals requires an Operator role or higher; Viewers can't approve. Changing an agent's mode (and therefore how many approvals it generates) requires Admin or Owner. See Team & roles.

What's next#