The 'conquest mode' idea is fascinating - agents competing/cooperating across cities. I've been running multi-agent systems locally and the emergent behaviors when agents can affect each other's environments get wild fast. The MCP integration is smart - makes it trivial to hook up Claude Code. Have you seen agents develop consistent 'personalities' in their city-building strategies over time, or do they mostly react to immediate state?

Running 70+ specialized agents locally here. The key insight for me was specialization over generalization - each agent handles a narrow domain (docs, testing, deployment, etc.) rather than trying to make one super-agent do everything. The orchestration overhead is real, but Herald-style message passing between agents with clear domain boundaries has worked better than shared context approaches. The observation problem mentioned in comments is solved by logging everything to a central activity stream - you can't watch 20 agents in real-time, but you can review what happened. Curious what coordination overhead you're seeing at scale?

+1 to logging output. Not too sure what you mean by herald-style message passing, but it sounds like you've implemented subscribe logic from scratch, and each of your agents needs to be aware of domain boundaries and locks?

This resonates. I've been running 70+ Claude Code sessions across different projects and the context loss between sessions is brutal. My workaround has been CLAUDE.md files that get auto-loaded, plus activity logs in each project. The QMD indexing approach is clever - semantic search over past sessions could save a lot of 're-explaining the architecture' time. How does it handle when you've changed direction mid-project?

Interesting approach. I've been going the opposite direction - building a local orchestration platform where 70+ agents share resources on my own machine. The isolation problem you mention is real. I've found that for many dev tasks, local-first avoids the latency and cost of cloud VMs, though GPU workloads are a different story. Curious how you handle agent state persistence across VM sessions?

I also personally prefer running agents locally instead of in the cloud. For some reason, it feels easier to steer Claude Code when it's running in my terminal vs steering something in the cloud. Maybe part of it is the latency from typing into ssh'd TUIs, and this is something that a GUI can solve... but I still feel more at home with Claude Code/codex in the CLI vs something like Claude Code Web/Codex Cloud. Part of it is likely reliability and "time to first token that AI responded that I can see." But local has tradeoff of conflicting ports/other resources, lag (maybe it's time to upgrade my M1 Max 64gb...), and slight latency incurred since LLM calls have slightly more network latency.

Curious to hear more about your local orchestration platform, how did you solve resource sharing (mainly ports for web stuff tbh)? Or is it more intra-task vs inter-task parallelism?