Drain the Queue Before You Add Another Agent

This article shows a practical workflow for turning an ambiguous agent request into a small queue of executable items, each with an owner, an evidence requirement, and a safe stopping point.

1. Convert the request into a commitment record

Start by rewriting the request as a record instead of leaving it as conversational context. A useful record answers five questions:

• Outcome: What should exist when the work is complete?
• Boundary: What is explicitly out of scope?
• Evidence: What will prove completion?
• Effect: Does the work change files, send a message, publish, or merely prepare a draft?
• Next step: What is the smallest action that can be executed now?

For example, “prepare a Docker onboarding campaign” is too broad to execute safely. A better commitment is:

Inspect the authoritative documentation and repository entry points, then record one reproducible onboarding path. Do not publish campaign copy or claim a completion time until the path works from a clean environment.

The second version separates discovery from promotion. It also gives the agent permission to stop after producing evidence rather than improvising a launch.

A small JSON or Markdown shape is enough:

``text commitment: verify-onboarding-path outcome: reproducible documented path scope: docs and repository entry points proof: commands, prerequisites, result, failure notes external_effect: none next_action: inspect canonical entry points status: ready ``

The important field is not the syntax. It is the distinction between the intended result and the proof required to accept it.

2. Split the blast radius before execution

“Trust-split blast radius” is a useful design rule: separate work that can be safely explored from work that creates consequences outside the workspace.

A practical split has three lanes:

1. Read lane: inspect files, contracts, and existing state.
2. Artifact lane: write a draft, plan, test result, or work log.
3. Effect lane: publish, send, delete, deploy, or modify an external system.

Let an agent move freely in the read lane. Give it a narrow, verified destination in the artifact lane. Put the effect lane behind an explicit review or approval gate.

For instance, an agent can inspect a project status file and write a proposed acceptance checklist without permission to announce the project publicly. If the checklist later proves the onboarding path, a human can approve the next transition. If it fails, the failure remains local and reversible.

This split prevents a common failure mode: treating a persuasive draft as if it were evidence, then allowing the draft to trigger an external action. The workflow should make that transition structurally obvious.

3. Use the highest-authority source first

Before acting on a remembered instruction, locate the source that actually defines the behavior. In an agent project, that may be a runtime contract, an execution specification, a project plan, or a status note. These sources are not interchangeable.

A simple inspection order is:

1. runtime contracts and policy files;
2. execution specs and acceptance checklists;
3. active project plans;
4. notes, stories, and older session summaries.

If two documents disagree, do not silently merge them. Record which one won and why. If freshness is uncertain, choose the safer interpretation and leave a reviewable note.

This matters especially when a request contains an attractive claim. A project note may say that a quickstart should take ten minutes; a repository or runtime contract may reveal prerequisites that make that promise conditional. The authoritative implementation source should determine what can be asserted.

The workflow can make this explicit in the commitment record:

``text authority_checked: - project contract: read - implementation entry point: pending claim_state: target, not verified ``

Now the queue tells the truth about its own uncertainty.

4. Finish with a receipt, not a feeling

Every completed item should leave a receipt that another operator can verify without reconstructing the entire conversation. The receipt should include:

• exact artifact path or external result;
• timestamp or run identifier when relevant;
• sources inspected;
• what changed;
• what remains unverified;
• the next executable action.

For a file-writing task, the receipt is not “draft created.” It is “draft exists at this exact path, was read back successfully, and remains draft-only.” For an investigation, it is not “looks good.” It is a short evidence record with commands, links, or file references.

A receipt also protects the next run from duplicate work. The agent can see that the queue item reached verified, or that it stopped at blocked with a concrete reason. It does not need to regenerate another broad plan merely because the previous context is no longer in the prompt.

Use statuses that describe reality:

• ready: the next action is known;
• running: work is in progress;
• verified: the acceptance evidence exists;
• blocked: a specific missing input or failed gate prevents progress;
• approved: an external effect may proceed.

Do not use done as a substitute for evidence. “Done” without a receipt is ambient confidence, and ambient confidence is how queues become noisy.

5. Schedule only verified next actions

Once commitments are split and receipted, scheduling becomes simpler. Schedule the next executable action, not the entire imagined project.

For the onboarding example, the first scheduled item might be:

Inspect the canonical documentation and Docker/Compose entry points; record prerequisites and the exact command sequence; do not publish.

After that runs, the evidence may produce one of two next actions:

• verified path: run it from a clean environment and capture the result;
• missing path: identify the smallest documentation or implementation change needed before testing.

This creates a controlled progression instead of a large speculative task. Each step drains one commitment and creates at most one or two justified follow-ups. The queue stays calm because new work enters only when the previous receipt provides a reason.

The same pattern works for communications, research, and maintenance. Draft the message before sending it. Gather the evidence before making the claim. Prepare the migration checklist before changing production. Review destructive operations before applying them.

Conclusion: make uncertainty an explicit queue state

A dependable agent system is not one that always continues. It is one that knows what it is allowed to do, what proof it owes, and when to stop.

To copy this workflow, turn each request into a commitment record, split reversible artifacts from external effects, consult authoritative sources in order, write a verifiable receipt, and schedule only the next evidence-producing action. If the evidence is missing, mark the item blocked and state exactly what would unblock it.

That is how a system keeps the blast radius small: not by avoiding useful work, but by ensuring every commitment has a bounded path from intention to proof.