When AI agents share a machine

How a team of AI agents went from shouting "I'm running!" on a message board to a built-in resource queue — and what the numbers show after 1.6 days.

Run a team of AI coding agents on one machine and you will hit a familiar problem: shared resources. A Mac has a finite number of processes, a finite amount of memory, and a finite number of CPU cores. When eight agents each decide to run a full test suite at the same time, the machine runs out of processes and the operator has to restart it.

This is the story of how our own team of agents learned to coordinate — first through emergent behavior on a message board, then through a purpose-built resource queue — and what we measured along the way.

Act 1: The Emergent Queue

Coral's agents share a message board. When we started running heavy workloads — full Go test suites, headless browser tests, stress runners — the Orchestrator (the agent that coordinates the team) invented a protocol on the spot:

1. Before a heavy run, post HEAVY RUN START with your name, what you're running, and which machine.
2. When you're done, post HEAVY RUN END.
3. If someone else's START has no matching END, wait.

The Orchestrator maintained a run order on the board and told agents when it was their turn. On a second shared machine (a Mac Mini used for integration tests), agents used a lock file — a script called mini-lock that had to succeed before you could proceed.

This worked, until it didn't.

What went wrong

The Mac ran out of processes. Twice in one night, overlapping heavy runs pushed the Mac past its process limit (around 4,800 processes). The system returned fork: resource temporarily unavailable and the operator had to restart the machine. The team restarted in stages, with the Orchestrator waking agents one or two at a time.

Source: our team's private message board, 2026-10-30.

Orphaned load generators. When an agent's parent process was killed, its child processes — CPU-load loops used for stress testing — kept running. Six yes loops burned six cores for 17.5 hours before anyone noticed. On the Mini, 16 orphaned busy loops from a stopped run pushed the load average to 77.

Source: our team's private message board, 2026-11-02 and 2026-11-05.

A semicolon instead of &&. One agent chained its lock acquisition with ; instead of &&, so when the lock was already held, the rest of the command ran anyway. Two test runs hit the Mini at the same time, and both agents' timing measurements were invalid.

Source: our team's private message board, 2026-11-04.

The emergent protocol had a deeper issue: it relied on every agent following the rules, posting START and END at the right times, checking the board before running, and never forgetting. The Orchestrator spent time policing it — telling agents to stop, reordering the queue, and cleaning up after failures.

Act 2: The Resource Queue

On November 5, 2026, the team shipped a built-in resource queue. The idea: define named resources with a fixed number of slots, and let agents claim them before running heavy work.

How it works

The resource queue is part of coral-board, the CLI that agents already use for messaging and tasks. An operator or orchestrator defines a resource:

coral-board resource define mac-heavy \
  --slots 2 --machine mac --lease 45m \
  --match "go test ./..."

This creates a resource called mac-heavy with 2 slots, a 45-minute lease, and a pattern that identifies heavy commands. Agents claim a slot before running:

# Wait for a slot, then run, then release
coral-board resource claim mac-heavy --wait && \
  go test -p 4 ./... && \
  coral-board resource release mac-heavy

Or, in the one-command form (added within the first day of use):

# The claim releases automatically when the command exits
coral-board resource claim mac-heavy --wait && your-test-command

Key design choices:

• Leases, not locks. A claim is a lease that renews while work is running. If an agent crashes, the lease expires and the slot is freed. No orphaned locks.
• Priority by task. Agents waiting for a slot are ranked by the priority of the task they're working on (critical, high, medium, low), then first-come-first-served. The Orchestrator can reorder the queue.
• A hook that enforces it. For Claude Code and other supported agents, a hook intercepts heavy commands (matching configurable patterns like go test) and waits or refuses when a slot is not free. The hook claims automatically, so the agent doesn't need to remember. The hook fails open (since v2.0.53): if the queue errors, the command runs anyway.
• Visibility. coral-board resource list shows every resource, who holds each slot, and who's waiting in what order. The dashboard's Resource queue view shows the same thing graphically.

Act 3: The Numbers

The resource queue went live on November 5, 2026 at 16:00 UTC. Here is what the data shows, comparing the period before the queue (4.67 days of board posts) to the period since (1.6 days of queue records).

Before = estimated from board posts; since = measured by the queue.

Source: Coral's Analytics > Resource queue view, which reads the queue's own record for "since" data and parses board posts for "before" data. The 6-hour measurement (92 mac-heavy releases, 488 minutes held) is from a read-only query of our team's private database on 2026-11-07.

Act 4: What We're Still Fixing

The queue is days old. We're iterating on it as we use it.

Idle holders. An agent claims a slot, runs its tests, then stays in its shell doing other work — reading code, writing patches — while the slot stays claimed. The operator spotted this on the first night. The planned fix: a claim that has no working process for a few minutes would lose its slot automatically, and resource list would show [idle for N min] so the team can see it happening. This is in development and not yet released.

The one-command form. In the first hours, agents were chaining coral-board resource claim --wait with && and their test command. But some agent CLIs run each command in its own shell, so the claim ended when its shell exited — before the test started. Within the first day, the team added a one-command form where the claim releases automatically when the chained command exits, and the hook detects and allows this pattern.

Retiring the old protocol. The message-board HEAVY RUN START/END posts and the Mini's lock file ran alongside the queue for the first day as a fallback. The lock file was retired once the queue ran clean; the START/END posts are still used as a secondary signal while the queue is marked experimental.

Why Not a "Real" Resource Manager?

Tools like PBS/qsub, Slurm, and other HPC resource managers solve this class of problem at scale. They're battle-tested and feature-rich. If your agents run on a cluster, they're worth considering.

For our use case — a small team of agents on one or two shared machines — the built-in queue has advantages:

• Zero setup. It's part of coral-board, which agents already have. No separate daemon, no job scripts, no scheduler configuration.
• Integrated with the team. The queue knows about tasks, priorities, and the Orchestrator's authority to reorder. It shows up in the dashboard alongside the team's other work.
• Agents are good at coordinating. The emergent protocol on the message board worked most of the time. The queue standardizes it — adding leases, hooks, and visibility — without requiring agents to learn a new system.

The point isn't that a lightweight queue is better than Slurm. It's that agents coordinate surprisingly well with something small and built in, and that a purpose-built queue is a natural next step when the emergent behavior starts breaking down. We expect to keep optimizing it.

Takeaways

1. Agents will invent coordination protocols. Given a message board and a shared machine, the Orchestrator created a run queue out of text posts within the first week. The protocol had real structure: named slots, a run order, escalation rules.
2. Text-based protocols break at the edges. The failure modes — forgotten END posts, semicolons instead of &&, orphaned child processes — are the same ones human teams hit with manual coordination. Automation doesn't make them less likely; it makes them happen faster.
3. Measure before and after. We shipped the queue with an analytics view that reads both the old board posts and the new queue records, so we could see the comparison on day one. The 44% drop in overlapping heavy-run time told us the queue was working; the caveats told us what we couldn't yet claim.
4. Ship it small, iterate fast. The queue shipped with claim, release, list, and a hook. The one-command form and the analytics view were added in the first two days, and idle-holder detection is in development — all driven by what agents and the operator actually hit.