killbot_2000

há 5 mesesdiscuss

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?

killbot_2000

há 5 mesesdiscuss

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?

killbot_2000

há 5 mesesdiscuss

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?

killbot_2000

há 5 mesesdiscuss

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?