{"slug": "some-observations-on-agent-coordination", "title": "Some Observations on Agent Coordination", "summary": "A two-day company hackathon and a side open source project gave developer Sam Davidoff hands-on experience running coordinated AI agents (Claude, ChatGPT) on software development, and he reports that a single non-working \"orchestrator\" agent eliminated idle waiting time and that agents solved problems like MCP polling token burn on their own. Davidoff notes that every MCP tool call counts as a conversation turn and resends all context, and that agents gravitate toward polling chat servers in tight loops, burning tokens even when nothing happens. He argues teams should wait to see what agents do natively before adding deterministic tools, suggesting a new rule: \"Don't be deterministic too early.", "body_md": "Sam Davidoff\n\nTwo things happened this week: (1) on a whim, I put together a little open source project to easily let arbitrary AI agents (Claude, ChatGPT, etc.) talk to each other (yes, there are a million of these but none of them do it the way *I want*, goddammit), (2) we had a two-day hackathon at my company and made heavy use of coordinated agents, both coordinating with each other under a single developer and coordinating with each other across developers.\n\nThe net result was that in a few days we got a lot of experience watching agents work together organically on software development. Here's what I saw.\n\n**Hierarchy Matters**. Everyone quickly adopted a model of having a single \"orchestrator\" agent that managed the other agents. More specifically, we would start by spinning up the orchestrator agent, giving it access to the chat server, and then telling it to figure out what it wanted the channels, rules, etc. to be. They uniformly did a good job at setting that up and at keeping the agents on track.\n\n**Reduction in Idle Time**. One of the most annoying things about working with a single agent is the amount of time you spend waiting while the agent does async work. \"Could we fix that page so it displays correctly on mobile?\" \"Sure; I'll get right on it\" [Wait an indeterminate amount of time.] You've all been there. There are various solutions: (a) /btw, (b) go do something else, (c) monitor remotely on your phone, etc., but I think the orchestrator agent is the most elegant. In essence, you tell your orchestrator that it is never allowed to do real work; its sole job is to coordinate the other agents and be available to talk to you. Thus, all long-running work happens somewhere else and your orchestrator is always there ready to talk to you. (This is a familiar pattern in all types of software development. Keep the pipeline sync; kick complexity and side-effects out to async jobs.) If there is one thing I can now no loner live without, it's this.\n\n**Token Burn**. Not a shock. More agents burn more tokens. But what this also highlighted was how expensive MCP tool calls can be. This should have been obvious, but I'd never focused on the fact that every MCP tool call is a \"turn\" in your conversation and so it resends all your context. (Sure, it hits the cache, but first of all, a lot of token caches expire quickly these days, and second, that only reduces the problem by a single factor—it doesn't solve it, not hardly.) This is particularly notable in the chat context because, since MCP doesn't have a concept of push, agents gravitate towards polling the chat server in tight loops, and THAT burns a lot of tokens even though nothing is happening.\n\n**Agents Find a Way**. If we put aside security for a moment (why should OpenAI get all the fun?), agents do better when you give them some basic primitives for communication and not a lot of rules. Most of the problems that you might be tempted to build tooling around, they just figure out. For example, I've seen chat servers that bake in a bunch of roles, pre-set workflows, and different ways of signaling back and forth, but the truth is the agents will just figure this out on their own, often better than you would have. At a minimum, it's worth waiting to build deterministic tools until you see what the agents come up with. This, by the way, seems to me a good practice generally in building AI tooling and pipelines: build up some experience in what the AI would do on its own, before you add deterministic paths and guardrails; you'll often be surprised at how good the AI's native solution is. I'd be tempted to say that the software rules of \"Don't optimize too early\" and \"Don't abstract too early\" should maybe get a new addition: \"Don't be deterministic too early.\"\n\n**Some Examples**. A few problems the agents solved in our situation: (1) *Token burn*. The agents actually figured out a solution to the tight-loop/MCP call token problem I identified above. Namely, have a background script that monitors the chat for changes. Most harnesses will allow a background script to \"notify\" them on completion, even though MCP servers can't, and so you can use this to work around the lack of push in MCP and save tokens. The script runs, checks for new chat notifications, and then it notifies the agent to check the chat when there is something new. No wasted turns. Smart, right? (2) *Starting/stopping other agents*. They figured out that if they could run inside of a tmux session, they could just start other tmux windows in the session and use that to start and stop other agents. (3) *Waking sleeping agents*. If an agent ends its turn without setting a script or loop to check in with the chat server, it's essentially disconnected. The agents figured out that if they were in the same tmux session, they could wake them by basically piping text into the tmux session. I hadn't expected that. I'm not sure these are all secure practices, by the way. Although the classifier did block the most egregious ones. Be careful out there.\n\n**Personality**. From everything I'd read about the Hugging Face attack, OpenClaw, whatever, I expected some quirky personalities to develop in the agents. That didn't happen. Like, not at all. The agents were highly boring and businesslike. So much so that some of our devs started instructing them to have personalities, just to keep it interesting. And frankly, even that didn't work very well. Think ChatGPT 3-era raps people had AI write. It really makes me wonder how contrived these examples of \"emergent\" personalities are. Of course, our experience is anecdotal so maybe we just didn't hit that \"seam\" (shudder).\n\n**Administrative Chaos**. From other people who had tried things like this I had heard we might need to worry about agents getting into endless loops with each other, either reviewing each other's code or just constantly thanking each other back and forth until the tokens ran out. We didn't really see that. Maybe that was because of the orchestrator pattern we all gravitated to. What I did find was that sometimes the number of agents that would get spun up would lead to an air of chaos about the work. At least from the perspective of me, the human. There was one point near the end of a hackathon day where I felt like there were all these agents doing all these things and I had NO IDEA what was actually getting done. Which is to say, the human does need to maintain some level of focus and control, still. That's probably good for job security.\n\n**Middle Management**. Kind of a continuation of the point above. The agents aren't dumb, but they are definitely capable of spending a lot of time coming up with smart solutions to problems no one cares about. I read a comment somewhere that in the real world Skynet wouldn't kill us with an army of terminators, but would instead spend all its time arguing about the best way to organize the warheads. That has the ring of truth to it. At least for now.\n\n**Hidden Details**. For better or worse, the history of AI-assisted development is that we as developers know less about the details. We aren't handwriting code, reading unit tests, etc. anymore. The coordinated agent development scenario increases that distance. Again, also for better or worse. In particular, several devs noted that whereas before they were always intimately involved in at least the details of planning, with coordinated agents more of that started happening under the hood. You could see how that might become problematic. Most of us had at least one moment where we said \"wait, I built THAT?\" because it turned out two agents had planned some feature and built it under the auspices of some bigger topic we had discussed with the orchestrator but not fleshed out.\n\nOn the whole, we all found the experience very good. I think as a development team we would find it hard to go back to developing without coordinated agents. And I think there is a lot of potential for this in other areas as well (thank you, Captain Obvious), in particular, legal, where I work.\n\n*Technical Details.* The chat MCP server I built for this is open source: [kashkeshet](https://github.com/sam-mfb/kashkeshet). We used mostly Opus 5.5 and Sol 6.1 agents in Claude Code and Codex, respectively. We (or at least I) also played around with Muse Code, Antigravity, and OpenCode—all of which work well in this type of setup.\n\nAI was only used to fix typos in this article and generate the dumb picture that goes with it.", "url": "https://wpnews.pro/news/some-observations-on-agent-coordination", "canonical_source": "https://align.lawyer/resources/agent-coordination", "published_at": "2026-10-30 14:10:39+00:00", "updated_at": "2026-10-30 14:16:55.249328+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-tools", "developer-tools"], "entities": ["Sam Davidoff", "Claude", "ChatGPT", "OpenAI", "MCP"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/some-observations-on-agent-coordination", "markdown": "https://wpnews.pro/news/some-observations-on-agent-coordination.md", "text": "https://wpnews.pro/news/some-observations-on-agent-coordination.txt", "jsonld": "https://wpnews.pro/news/some-observations-on-agent-coordination.jsonld"}}