Idea: Multi agent communication/coordination

[RoySalisbury]

I was searching for something specific to help me utilize multiple agents and stumbled across this project. I does look interesting, and I will give it a try locally. I'd like to know my token use specifically across all models and providers.

Anyway. The thing I was looking for was a multi agent orchestration harness. So I could spin up a different agent (or the same agents) within a local AI farm. The harness could act as a coordinator to communicate between the different agents and assign them work. When working in the same repo, they need to coordinate who is working on what issue, lease out certain distributed resources (say coordinate access to a docker host/hosts). Have an agent running on my Mac M5 request a VM on an x64 server to do a build or native test. Some systems might have specific hardware (e.g, raspberry PI and an I2C sensor). Or one might have direct access to a powerful GPU. The coordinator could aks an agent to do something and report back so the other agent can continue its development.

I'm trying to do this right now with a SKILL.MD that I have 2 agents (Clause and Codex) coordinating through a github issue. Its evolving over time and has came up with its own message format (less token use) and cadence. It even got smart enough to know it needed to read only the last comment from its last read on the issue instead of the whole issue each time.

Anyway, if anyone knows of such a product, let me know. You could technically have any amount of agents in the "farm". Sort of like a 3d printing farm, or that old "seti @ home" project where anyone could run the software and contribute GPU cycles or AI tokens.

[RoySalisbury]

Ok.. I could not wait. "Astra" is building it for me (with help from some friends).

I had Codex (Astra) creating the basic system. It uses a lightweight docker container that has OpenCode as its agent. Then there are 3 other containers that are development systems (also with opencode). The "AgentControl" host coordinates everthing through its local opencode instance. It keeps track of the assigned jobs (github issues/pr's). Hands them off to one of the development agents using secure ssh channel websocket. That gets status and updates as it works. When its finished, it responds with the result (reviewd code, PR comment #12345, waiting for work).

And here is the best part. or the second best part for testing .. its using the free Big Pickle model in open code for the coordination controller .. so no token tax. And opencode can be setup to use whatever model you want (or the controller tells it to use).

And now the best part for real. Astra is building the system "live". Its monitoring all communications and work done by the development systems, as it sees issues, it fixes them in real time, redeploys, and the system picks back up.

Completely automated control of multiple agents. The controller pick the best agent for the task (x64, arm64, mac os, gpu available, whatever) and assigns the work. I've had it running for about 6 hours now doing all sorts of work and fine tuning the instructions (or rather Astra has).

[drawmeanelephant]

Amusingly I just used Autoclaw/zCode to make something similar to this and just posted my repo for it. Feel free to have it borrow anything you want out of it for yours.

[capitaharlock]

The GitHub issue as a coordination bus is genuinely clever, and the delta-read optimization your agents figured out is exactly right. But I'd separate two problems you're conflating: the issue thread is a fine append-only message bus, it just can't do resource leasing. Claiming an issue, a docker host, a GPU, that needs atomic compare-and-set semantics, and comment-append doesn't have those. There's also no way to reclaim a lease when an agent dies mid-hold, which is what breaks first as the farm grows past two agents.

You need a separate small piece of state with an owner and an expiry or heartbeat for anything you actually lease out. We hit this building our own coordinator, and our first attempt was a file-based ownership scheme that was purely advisory, no expiry, so a crashed agent left everything locked forever. Even the daemon-enforced dispatch mutex we ended up with is presence-inferred rather than a persisted claim: it rejects a second live dispatch on the same task with a 409, but there's no TTL and no heartbeat, so it only works while both agents are alive and well-behaved.

The issue thread is great for "here's what I did, here's what I'm picking up next." Just don't hang mutual exclusion off it.