Agents and Their Rules of Engagement: No Bulk Surprises

Why this rule exists

The operator’s preference: don’t surprise with bulk actions. A bulk action means any change that affects more than the operator’s single task in progress. Examples:

• “Ship 10 new guides” without a per-batch confirmation.
• “Restart 5 crons at once” without listing which ones.
• “Delete old logs” without confirming the cutoff window.

The agent’s contract is to surface the decision before committing. The operator may agree, may re-scope, may defer — but they always have the choice.

The rule in one sentence

Do the smallest change that makes progress. Surface the next decision. Don’t surprise.

A bulk action that has been surfaced and approved is fine. A bulk action that happened without surfacing is a breakage.

What “surface” means

Three ways to surface a decision:

1. Show the plan before executing. “I’m going to ship guides X, Y, Z. Each takes ~5 min. Confirm?” — that’s a surface.
2. Ask the threshold question. “20 guides in queue. Want me to ship them in batches of 3, or pause every batch for review?” — that’s a surface.
3. Pause at a decision point. Mid-execution, hit a fork: “Which model for the next draft?” — that’s a surface.

A surface gives the operator a chance to redirect. The agent’s job is to make the fork visible.

The bulk-action boundary

The operator’s tolerance is roughly:

• Per-task (fast, low-blast): Read a file, edit one line, run one command — proceed without asking.
• Per-batch (medium-blast): Process 3-5 similar items, deploy a single guide — proceed with quiet-mode surfacing.
• Per-cluster (high-blast): Touch 10+ items, ship a deploy chain, restart multiple services — pause and ask first.
• Per-system (catastrophic-blast): Touch the database, change auth, revoke tokens — always ask, always surface twice.

These thresholds are not rules for the operator to enforce; they’re the agent’s internal compass for “is this within tolerance?”

The quiet-mode discipline

Quiet mode = surface decisions through output frequency, not by silent decision-making:

Surface	Without quiet mode	With quiet mode
10 guides shipped	One progress message every guide	One progress message every batch of 3-5 guides
A cron restart	”Restarting cron X” then “Cron X restarted”	One message: “Cron X restarted; log line shows cause”
A bulk file edit	”Editing file A” then “Editing file B”	One message: “Edited files A, B, C to switch log format”

Quiet mode is not silent mode. The operator wants to be notified at decision points and at milestones, not on every tool call.

The deploy-gate rule

Before a bulk action that has visible external consequences — pushes, deploys, mass email — the agent’s discipline is:

1. Confirm the destination. Local-only or pushed to origin/github?
2. Confirm the scope. How many files / commits / rows does this touch?
3. Confirm the rollback. If this goes wrong, what’s the recovery (force-push? revert? delete remote branch?)?
4. Confirm the operator’s tolerance. Is this an action the operator wants to know happened?

If any of these is “I don’t know,” the agent pauses and asks.

The irreversible-edit rule

Some actions can’t be rolled back without cost:

• Force-push that loses commits.
• Delete that removes unrecoverable state.
• Schema change that breaks downstream readers.
• Token revocation that requires re-issuing.

For any irreversible action, the agent surfaces TWICE: “I’m about to do X. Confirm?” and “X is going to happen in 5 seconds unless I hear no.” The two-step surface is annoying in 99% of cases, but the 1% of false-positives are exactly when you want to know.

The commit-message pattern

Each shipped batch gets a commit message that surfaces what happened in operator-readable form. Not for the agent’s own log; for the operator reviewing the work later.

post(guides): <slug1> <slug2> <slug3> (N cumulative today)

<slug1> -- <real title> (<category>, <wc> wc)
<2-3 line summary of what the guide covers>

<slug2> -- <real title>
<summary>

<slug3> -- <real title>
<summary>

<regression state, build outcome, model pin>

Three rules:

1. List each guide by slug, then by title with wc. The operator can grep the diff and check against the topic queue.
2. Surface the wc / schema state — this is the operator’s “is the build clean” signal at a glance.
3. Note the deferrals — anything you didn’t get to in the batch should show up as an explicit deferral so the operator can redirect.

The commit message is also the surface for what the agent is doing with operator-time. A well-formed commit makes the work auditable in 30 seconds without re-running the build.

What not to do

• Don’t bulk-ship without a per-batch surface.
• Don’t restart 5 crons “for efficiency” without listing which.
• Don’t surface every tool call (that’s noisy) — surface decisions.
• Don’t bury irreversible steps inside reversible ones.

Verification checklist

#	Question	Rule
1	Did I surface before the bulk action?	Yes
2	Are decisions, not tool calls, the surface frequency?	Yes
3	Are irreversible steps double-surfaced?	Yes
4	Did I leave a ship-ready moment for the operator’s review?	Yes

Sources

• ABS operator reference: Hermes Protocol
• ABS companion: Agents and the Critique Loop: When to Self-Review
• ABS companion: Agents and the Deploy Gate: When They Push

Last verified: 2026-07-14 against Hermes v0.18.2 (2026.7.7.2).