Lucy Liu
July 2026 · Directing AI

A Shared Queue for My AI Agents

Watercolor illustration of three origami paper cranes waiting in a row

I run three AI coding agents: Claude, Codex, and GLM. Each one is capable on its own. Together, unmanaged, they were a coordination problem wearing three trench coats.

Here is the failure that forced the system. Before any rules existed, I handed out work informally, a task mentioned here, a task pasted there. Two agents ended up working the same task at the same time, neither aware of the other. I got back two finished versions that conflicted with each other, and I spent the time I thought I had saved untangling which one to keep. The work was done twice and usable once, on a good day.

Any operator has seen this movie with people. Two employees quietly working the same problem is a management failure, whatever their talent. There was no single place where work lived, no way to see who owned what, and no definition of done that anyone had to meet. I had built a small team and given it no operating system.

So I built the operating system. All work between my agents now moves through one shared Notion database: the Agent Queue. It is a ticket system, deliberately boring, with a few rules that carry all the weight.

The rules that make it work

Every ticket carries its own context. Instructions and source links live on the ticket itself, so any agent that picks it up has what it needs without me re-explaining the task in a chat window. If I cannot write the ticket clearly enough for an agent to act on it, that is my signal the task is not actually defined yet.

An agent must claim a ticket before working it. The claim goes through a script, and the script refuses double-claims. If Codex claimed a ticket two minutes ago and Claude tries to take it, Claude gets refused and moves on. The conflicting-versions problem did not need better judgment from the agents. It needed a lock, and now there is one.

No receipt means not done. When an agent finishes, it files a receipt on the ticket: what it did, what changed, how it verified the result. An empty or vague receipt is a protocol violation, and I treat it as one. Without this rule, "done" quietly becomes "I produced output," which is a different and much cheaper claim. The receipt is the difference between work I can trust and work I have to redo the inspection on.

Ambiguity comes back to me, never gets guessed at. If a ticket is unclear, the agent posts a blocking question on the ticket, flips the status, and stops. I answer on the ticket and send it back. This is the rule I care about most, because a confident guess from an AI agent looks identical to a correct answer right up until it costs you something. I would rather answer five small questions than reverse one confidently wrong decision.

What this actually is

None of this is novel software. It is a shared queue, a claim lock, a definition of done, and an escalation path. Strip away the AI and it is how you would run any small team of contractors you cannot watch all day. That is the point. The management layer transfers; only the workers changed.

Since the queue went in, the duplicate-work problem stopped, and handoffs between agents stopped depending on my memory of what I told which tool. I can look at one database and see what is open, what is claimed, what is blocked on me, and what is done with proof attached.

If you are starting to use more than one AI tool for real work, here is what I would do this week: put the work in one place the tools share, make claiming explicit, and refuse to mark anything done without a written receipt that says how it was verified. You do not need my scripts to do this. You need the same thing every team needs, which is one source of truth and a definition of done that nobody, human or otherwise, gets to skip.

← All writingBook a call