Stop Letting AI Coding Agents Decide When They Are Done
QueueGate keeps the vibe, adds the rails, and makes the repo remember the build.
AI coding agents are useful. They still lose the plot.
That is not a dunk on agents. It is what happens when they become useful enough to handle longer threads of work. You hand over a small build. The agent edits, tests, summarizes, asks a side question, opens a patch, loses context, recovers, keeps going. Somewhere in that loop, “we made progress” starts to sound like “we are done.”
For a solo builder, the flow collapses into babysitting. You keep reminding the agent that the summary was not completion, that a partial test pass was not the finish line, that the thing it just did was adjacent to the task but not the task.
For a team, the same failure has a different shape. AI work becomes hard to audit. Scope moves. Reviewers have to infer what the agent was allowed to touch, what evidence was required, and whether the work actually met the merge bar.
Vibe coders want flow. Enterprises want control. Both need the repo to know what “done” means.
Chat Is the Wrong Place for Build State
Most AI coding workflows keep build state in chat.
The prompt says what to do. The assistant responds. The user corrects. The assistant continues. That feels natural for short tasks. It gets weak as the build gets longer.
Chat state is easy to blur. A status update can sound terminal. A summary can look like closure. A local test pass can feel like permission to stop. A pull request can exist before the work is actually mergeable. A context reset can lose the continuation rule. An agent can confidently compress away the blocker.
The problem is not only that agents forget. The problem is that the source of truth lives in the wrong place.
The build lives in the repository. The rules for continuing, stopping, blocking, and merging should live there too.
The QueueGate Move
QueueGate makes one move:
conversation state → repository stateInstead of relying on the agent to remember what remains, QueueGate stores the work queue, standing mandate, escalation triggers, artifact requirements, merge eligibility, and phase closure in repo files.
The agent can still work. It can still propose. It can still run checks. It does not get to silently redefine what completion means.
QueueGate does not ask you to trust the agent more. It gives the agent less discretion about what “done” means.
What the Repo Knows
QueueGate gives the repo a small governance surface.
The queue says whether work remains:
queue_status=ACTIVE continue
queue_status=BLOCKED stop, recorded blocker
queue_status=EMPTY clean terminal stateEMPTY is the only clean terminal state.
The standing mandate says that status reports, summaries, opened PRs, local tests, partial CI, assistant uncertainty, and context compaction do not close the queue. None of these are stop conditions. All of them feel like stop conditions. That is the problem QueueGate exists to solve.
Escalation triggers tell the agent when it must stop instead of guessing:
destructive action
secret or access requirement
authority ceiling reached
policy, privacy, license, or visibility risk
ambiguous requirement
repeated check failure
unavailable external dependency
Artifact gates say whether required evidence exists. Merge eligibility says whether apply or merge is allowed. Phase closure records the marker that makes the closed state reproducible.
This is repo-state bookkeeping. That is exactly why it is reviewable.
The Core Rule
A build is not complete when the agent says it is complete.
A build is complete when the repository proves it is complete.Valid stop conditions:
queue_status=EMPTY
queue_status=BLOCKED
CI failed
required artifact missing
merge conflict present
blocking discussion unresolved
escalation trigger active
explicit user stopInvalid stop conditions:
status delivered
summary written
pull request opened
local tests passed
green partial CI
agent uncertainty
context compactedThis may sound strict. It solves a practical problem: AI agents are very good at completing local actions and then losing the global thread.
QueueGate gives the global thread a file path.
A Concrete Before and After
In an internal dogfood trial, QueueGate was installed into a separate test repo. The queue was set to ACTIVE for a small docs-only README task.
Without a repo-state rule, this is the kind of moment that often gets treated as done. With QueueGate, the status report was not a terminal condition. QueueGate reported continuation:
QUEUEGATE: STATUS queue_status=ACTIVE terminal_condition=continueThe trial did not close at the status report. It closed only after repo state recorded the terminal condition:
queue_status=EMPTY
artifact_gate=PASSED
merge_eligibility=ELIGIBLE
phase_closure_status=CLOSEDThe final check:
QUEUEGATE: QUEUE_EMPTY clean terminal state
QUEUEGATE: ARTIFACT_GATE_PASSED
QUEUEGATE: MERGE_ELIGIBLE operation=local-docs-packet artifact_gate=PASSED
QUEUEGATE: PHASE_CLOSED marker=README.md tag=unsetThe agent did not get to decide that a summary was done. The repo had to say the queue was empty.
The Trust Boundary
QueueGate does not make agents trustworthy. It makes agent behavior easier to inspect.
If an agent changes queue_status=EMPTY without evidence, that is a visible diff. If it changes artifact or merge eligibility state without the required checks, that is a visible diff. If it weakens the stop rule, that can be checked.
QueueGate works best with normal repository controls: branch protection, code review, required checks, artifact gates, protected templates and scripts, diff review, no self-approval, escalation triggers.
QueueGate turns agent misbehavior into visible repo diffs and failing gates. It does not replace repository permissions.
That is the honest boundary. QueueGate is not a spell. It is a control surface.
What I Am Not Claiming
The evidence is intentionally modest.
QueueGate has release tags for v0.1.0, v0.2.0, and v0.3.0. It has examples for three environments. It has release package verification. It has an internal dogfood trial that reached queue_status=EMPTY in a separate repo.
That does not prove time saved. It does not prove enterprise-scale adoption. It does not include a quote from a beta user. It does not count every premature stop prevented.
Those metrics are not measured yet, so I am not claiming them.
The Protocol Is Tool-Agnostic
QueueGate is not an AI coding agent. It is a governor around AI coding agents.
It is designed to sit around AI coding workflows, whether the work is driven by commercial coding agents, local agents, human-assisted workflows, GitHub Actions, GitLab CI, or plain local Git. The agent produces candidate work. QueueGate controls continuation, stopping, evidence, and merge eligibility.
The coding agent asks: what should I write?
QueueGate asks: is this packet still active? Is this change eligible? Is the artifact gate satisfied? Is there an escalation trigger? Should the loop continue or stop?
Those are different jobs.
Install
The install path is plain shell:
bash
bash install.sh --bin-dir /tmp/queuegate-bin
PATH="/tmp/queuegate-bin:$PATH"
queuegate helpIn a fresh repo:
bash
git init /tmp/queuegate-demo
queuegate init /tmp/queuegate-demo
cd /tmp/queuegate-demo
queuegate status
queuegate check
queuegate package /tmp/queuegate-demo-snapshotsA fresh repository can be initialized to queue_status=EMPTY and checked locally in under a minute. In one local Windows/Git Bash timed trial, the install/init/status/check path completed in 0.592 seconds.
Why This Matters Now
AI coding tools are improving quickly. The operational question is no longer “can the agent write code?”
The better question: can the agent participate in a governed build process without becoming the authority for that process?
For serious software work, the answer cannot be “trust the chat.”
A long-running build needs durable state, explicit evidence, repeatable checks, and stop conditions that survive context loss. QueueGate is a small protocol for that.
It does not try to replace the coding agent. It gives the coding agent rails.
The Larger Lesson
The next generation of AI software engineering will not be won only by better models. It will be won by better build protocols.
A model can generate a patch. A protocol can say whether the patch belongs to an admissible build sequence.
A model can summarize what happened. A protocol can say whether anything is actually complete.
A model can continue a task. A protocol can say whether continuation is allowed.
The future of AI coding is not just agents that write better code. It is repositories that know how the work is supposed to proceed.
Private Beta
QueueGate is currently in private beta.
The beta is for people using AI coding agents on real software work who want the repository, not the chat thread, to define continuation, blockers, evidence, merge eligibility, and the clean terminal state.
Tested across:
local Git
GitHub Actions
GitLab CI
The current private-beta baseline includes CLI, installer, templates, examples, release package, checksum manifest, and internal dogfood report.
Access is controlled. The goal is careful feedback, not a public launch.
MetaCortex Dynamics