When to Hand Your Agent the Next Instruction: Waiting, Interrupting, and Queuing, Measured

Queued instructions go stale

A queued instruction runs after the current work finishes. Obvious. The catch is that I have no idea what the world looks like at "after."

A concrete case. I queued: "make retryCount in src/lib/queue.ts read from config." When I queued it, that file and that variable existed exactly as described.

Three minutes later, the in-flight work had finished splitting queue.ts apart. retryCount now lived in src/lib/queue/policy.ts. The agent dutifully looked for queue.ts, didn't find it, created a fresh queue.ts, and put retryCount in it. A perfect duplicate definition.

The agent did nothing wrong. I handed a three-minutes-ago world to a three-minutes-from-now agent.

Going back through all 90 queued instructions: 37 of them (41%) executed against a HEAD that had moved since queuing. 20 of those actually broke, which accounts for almost all of the 22%.

So the weak point of queuing isn't the agent's comprehension. It's that the instruction carries no statement of its own assumptions. Between people, "that file we were just looking at" resolves fine. To an agent three minutes downstream, it doesn't resolve at all.

Stamp the assumptions onto the instruction

The fix was almost disappointingly small. Before queuing, write the current repo state into the instruction body.

#!/usr/bin/env bash
# queue-note.sh — attach "what I assumed when I queued this" to an instruction
# usage: ./queue-note.sh "make retryCount read from config"
set -euo pipefail
 
INSTRUCTION="${1:?pass the instruction text as an argument}"
 
BRANCH="$(git rev-parse --abbrev-ref HEAD)"
HEAD_SHA="$(git rev-parse --short HEAD)"
DIRTY_COUNT="$(git status --porcelain | wc -l | tr -d ' ')"
STAMP="$(date -u '+%Y-%m-%d %H:%M:%S')"
 
cat <<EOF
${INSTRUCTION}
 
--- assumption stamp (queued at ${STAMP} UTC) ---
branch: ${BRANCH}
HEAD: ${HEAD_SHA}
uncommitted changes: ${DIRTY_COUNT}
 
Before you start, compare the current HEAD against ${HEAD_SHA}.
If it has moved, this instruction was written against a stale world.
Do not execute it as written. Ask once, in this shape:
"Assumptions changed (${HEAD_SHA} -> current SHA). <summary of what moved>.
 I think you meant <inferred intent> — should I proceed?"
---
EOF

Paste the output into the queue. Under twenty lines, and it moved more than I expected.

After the stamp (July 14–16, n=44)

The staleness itself barely budged. Of course it didn't — a shell script doesn't stop the world from moving.

What changed is that the agent stopped guessing quietly. A quarter of the time it came back and asked. Answering a one-line question is far cheaper than discovering a duplicate definition two commits later and unpicking it.

The 9% that remains is the kind of drift a stamp can't see: the file didn't change, but what it meant did. I don't have a mechanical answer for that one yet.

Three conditions that call for Send Now

Once queuing works, the temptation is to queue everything. Some instructions must not be queued. Three days in, three conditions stand out.

1. When stopping the current work is the whole point. "That approach is wrong, stop" is meaningless in a queue — by the time it runs, the thing you wanted stopped has finished. Send Now.

2. When the current run is visibly broken. Output has gone off the rails, or it's looping. Waiting only buys more waste. I used Send Now 11 times in three days; 7 of them were this.

3. When the instruction doesn't depend on how the current work turns out. "Update the CHANGELOG when you're done" is safe to queue. "Test the thing you just fixed" is not — the thing just fixed is exactly what's still moving.

The third one is the real trap, because it looks safe. Every "that," "the one you just," and "earlier" in your instruction is a pronoun that cannot resolve without a stamp.

So here's the test I use now. Before queuing, hunt through your own sentence for pronouns and rewrite them as proper names. If you can, queue it. If you can't, that instruction belongs to the work in flight — wait.

When versions don't line up

v2.3.0 ships in stages. It can take days to reach a given machine, and while writing this I still had environments sitting on v2.2.1.

Since queuing changes the procedure, I branch on it inside my automation.

#!/usr/bin/env bash
# antigravity-version-probe.sh — detect the local version, branch on capability
set -euo pipefail
 
# Read the version string via CLI; empty where it can't be read
RAW="$(antigravity --version 2>/dev/null || true)"
VER="$(printf '%s' "$RAW" | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1)"
 
if [ -z "$VER" ]; then
  echo "version-unknown: treating queuing as unsupported" >&2
  echo "QUEUE_SUPPORTED=0"
  exit 0
fi
 
# Is it >= 2.3.0? Let sort -V decide; don't hand-roll version comparison
LOWEST="$(printf '2.3.0\n%s\n' "$VER" | sort -V | head -1)"
if [ "$LOWEST" = "2.3.0" ]; then
  echo "QUEUE_SUPPORTED=1  (detected ${VER})"
else
  echo "QUEUE_SUPPORTED=0  (detected ${VER} — use Send Now / sequential sends)"
fi

sort -V does the comparison because I once compared 2.10.0 against 2.9.0 as strings and got it backwards. Version comparison is not worth writing yourself.

When detection fails, I fall back to "unsupported." Assuming a queue that isn't there makes instructions vanish. Assuming no queue on a machine that has one only costs a little speed. Fall toward the side that doesn't break — the same principle I lean on everywhere else in this setup.

Back to the two minutes

Three days of data is thin, but this is where my workflow landed.

Thought arrives. Try rewriting its pronouns as proper names. If that works, run it through queue-note.sh and stack it. If it doesn't, the instruction is entangled with work in flight — wait. Send Now only to stop something.

Since routing every thought through that fork, the restlessness of those two minutes has faded. Back when it was wait-or-interrupt, waiting felt like self-denial. Now waiting has a reason, and so does queuing.

Shipping apps alone, a single redo pushes tomorrow's plan sideways — the App Store release you meant to cut this week slides to next. So a twenty-line script that takes rework from 22% to 9% isn't really a speed story to me. It's a tomorrow story.

If you want to try this, start by counting. For one week, count how many times you interrupt a working agent. Near zero, and queuing buys you nothing. Past ten, and it's worth keeping queue-note.sh around and stamping what you stack.

I'm early in this myself — 90 and 44 aren't enough to call it settled. I'd like to re-measure with the same yardstick in a month and report back on where these numbers land. Thank you for reading.