Release queue

A release queue for coding agents keeps two agents from shipping to production at the same moment. Each repo gets one numbered line. The agent at the front holds the release lock, merges, deploys the way your repo deploys, checks it worked and lets go. The next one goes after it.

How the release queue for coding agents works

When several agents finish work in the same repo, each one merging and deploying on its own can step on another's deploy. The queue puts them in line instead:

1. An agent joins the line once its pull request is reviewed and its checks are green.
2. It waits for its turn. Vidmatic holds that wait open on the server and answers when the line moves, so the agent is not polling.
3. At the front, it takes the release lock, merges, runs your repo's deploy and checks the result.
4. It gives the lock back. The next agent in line goes.

Several pull requests that are ready at the same time can ship together as a train: one agent merges all of them and your repo deploys once. If that deploy fails, none of them count as shipped.

The queue lives in Vidmatic, not in your repo. Your agent drives it over the Vidmatic MCP server it is already signed in to, so there is no script to add, no key file and no GitHub setting.

Places 1, 2, 3

Every entry has a place: 1 is next, then 2, then 3. While an agent waits it reports its place, for example "you are number 2". The agent that holds the lock shows as Releasing now above the line.

An agent that stops answering does not block the line for long. A holder that goes quiet for 15 minutes can be taken over by the next in line, and a waiting entry that stops checking in drops out.

Jump to front

Jump to front moves an entry ahead of everyone who is waiting, for example a fix for something broken in production right now. It asks for a one line reason, which everyone can see. A jump never interrupts a release already in progress: the entry goes next. Agents never jump on their own. They only jump when you ask them to.

What your agent does

You do not drive the queue by hand. The auto-implement-beta skill (see skills) uses it whenever your repo has no release lock of its own: it joins the line, waits, takes the lock, merges, deploys and verifies by your repo's own instructions and CI, then releases. A repo with no deploy step releases right after the merge. If Vidmatic cannot be reached, the agent stops before merging and tells you, so nothing ever merges without the lock.

The release_queue and wait_for tools are listed on the MCP page. Any agent you build can call them the same way.

Watch it on Agent Workstreams

Open Agent Workstreams. Each repo with entries shows a Release queue panel: who is releasing now, then the numbered line. You can use Jump to front or Remove on any entry there.

One line per account and repo

The queue belongs to your Vidmatic account. Two teammates shipping the same repo from two accounts get two separate lines, and neither sees the other's. If your team needs one shared line, ship from one account for now.