I continue to experiment with AI in the context of software engineering. I'm fortunate that my team supports me in exploring different ways to impr...
For further actions, you may consider blocking this person and/or reporting abuse
I’ve tried similar multi-agent setup, but gets expensive quickly. Adding a shared memory layer helped a lot. Leveraging GitNexus (for codebase knowledge graphs) + Serena (semantic IDE-style tools via MCP) cuts tpm
Oh yeah!
It's my professional environment setup, and we get quite a leeway regarding tokens usage.
the hard part is usually keeping context coherent between design and implementation agents. without a shared state layer they diverge fast. what's your coordination mechanism look like?
Designers write the PLAN.md, while implementors code it.
To be honest, I didn't get any divergence, but perhaps my scope is more limited than yours?
PLAN.md as a shared contract is smart — effectively the same idea. my divergence was runtime, not design-time: impl agents querying a state that design had already moved past. scope probably is the difference — once pipelines get interdependent it compounds fast.
The team-of-agents framing exposes a planning problem most blog posts skip: who holds the shared mental model? With humans, the senior on the team carries it in their head and corrects course informally. With agents you need that mental model to be explicit, queryable, and durable across runs, otherwise each agent rediscovers the same constraints in isolation. Coordination overhead climbs fast once you have more than two agents touching shared state.
Good point. I think the
README.md, a customPLAN.md, or the Wiki itself if you use GitHub can serve as the shared mental model.Agreed. The shared mental model usually starts as README.md, ADRs, PLAN.md, or internal docs. The problem is that coding agents don’t reliably operationalize those constraints during generation. That’s the gap we’re exploring with Mneme: turning architectural intent into enforceable workflow constraints.
The maturity levels framework is useful. One pattern that works well in practice: specialized small agents (vision agent for GUI, code agent for scripts, data agent for analysis) coordinated by a lightweight orchestrator. Each agent runs its own model optimized for that modality. This "scaling out" approach avoids the single-point-of-failure problem of routing everything through one monolithic LLM. The challenge shifts from "making one model do everything" to "making agents communicate efficiently."
The autonomy/security tradeoff framing is the right one — and the bit that I think is under-discussed is that who carries the shared mental model (your Theo Valmis quote) is a load-bearing design choice, not a nice-to-have.
A few observations from running similar agent-team setups in practice:
--dangerously-skip-permissionsis a permission-system smell, not a fix. When the choice is "approve every command" or "approve nothing", the actual problem is the system has no way to learn the operator's risk policy. The interesting design is permission policies that are queryable from a CLAUDE.md / config layer: "agents in domain X may write within paths Y, never run network commands, must escalate any DELETE." That's the shape that scales past 3 agents. Anthropic'ssettings.jsonpermission rules are most of the way there but don't yet propagate to subagents reliably (cf. issue #59309 in claude-code).Context coherence across agents collapses to "where does the shared state live." If it lives in the coordinator's context window, it dies on every compaction. If it lives in a file in the project root, every agent can read/write but no one knows when it changed. If it lives in a key-value store, you've reinvented a distributed system. There's no good answer yet — but the "agents independently rediscover the same constraints" pattern Mykola flagged is the symptom of choosing none of the above.
The cost scalability point is correct and also underrated. Running 6 Opus agents in parallel isn't 6x a single Opus session — it's 6x plus the cost of the coordinator's increasingly-bloated context as it tries to merge outputs. The economically rational architecture is "minority of expensive agents doing decomposition + judgment, majority of cheap agents doing fan-out work." Anyone running all-Opus all-the-time on agent teams is going to bounce off the bill fast.
The "may change significantly or not exist at all" disclaimer is doing real work in this post — it's worth taking literally. The protocols around agent teams are still settling, and anything built on the current shape will probably need to be re-plumbed in 6 months. Build in the lessons, don't build on the API.
I love using agents... I have experts in the fields I use to develop, and also I created expert agents in a frameworks I created so I can create apps based on that framework very easy...
Great breakdown of autonomous agent teams! The planner/challenger/coder/tester structure makes a lot of sense — having a dedicated challenger agent to push back on plans before implementation is something I hadn't considered but seems really valuable for catching issues early.
The autonomy vs. security tradeoff you mention is real. In my own experiments with multi-agent setups, I've found that being explicit about what each agent can and can't touch (rather than blanket permissions) helps a lot. Looking forward to seeing where the experimental Agent Teams feature goes!
Great. I liked the idea, thanks for sharing.
The subagent specialization pattern you describe is really powerful. I have been experimenting with something similar where different subagents handle different phases of a feature — one for architecture decisions, one for implementation, one for test generation — and the orchestrator coordinates them.
The key insight I found is that the orchestrator prompt matters enormously. If it is too vague about handoff criteria, subagents either overlap in scope or leave gaps. Defining explicit "done" signals for each subagent — like "return a PR-ready diff" or "return a passing test suite" — makes the coordination much more reliable.
One challenge I keep running into is debugging when a subagent produces subtly wrong output. The context isolation that makes subagents efficient also makes it harder to trace why a particular decision was made. Have you found good patterns for observability across subagent boundaries? I have been toying with structured logging from each subagent (JSON traces of decisions and tool calls) but it adds overhead.
One thing I’d add from product-side workflows: the tricky part is not only splitting roles, but deciding what each agent is allowed to decide.
In sourcing/matching workflows I’ve been testing, one agent can extract intent, another can check evidence, another can draft the reply. But none of them should silently decide that missing data is “probably fine.” That boundary matters more than the agent names.
I’ve found it useful to make each handoff include three things: what is known, what is assumed, and what still needs a human or tool check. Otherwise the team can sound coordinated while passing uncertainty downstream.
The "who holds the shared mental model?" question is the real blocker. With human teams, the senior engineer carries the context in their head and corrects course. With agents, that context has to be explicit, queryable, and durable. A PLAN.md file works for small tasks, but once agents start stepping on each other's state, you need something more formal. The coordination overhead grows fast.
I think the interesting direction is splitting responsibilities between local and cloud agents instead of making one giant agent do everything.
Local AI can continuously read the repo, collect context, track changes, and structure the user's intent into clean prompts. Then a stronger cloud model handles reasoning and creates the action plan. After that, the local agent executes the smaller modifications step by step inside the repo.
Feels cheaper, more private, and probably more scalable than sending the entire codebase to a cloud model every cycle.
The real gap between single-agent + tools and multi-agent collaboration is communication protocol design. Most multi-agent setups fail not because individual agents are weak, but because the handoff format between them loses critical context. Structured intermediate artifacts (specs, test cases, interface contracts) between agents matter more than the agents themselves.
The insight that resonated most with me is that the shift from single-agent coding assistance to autonomous agent teams requires more than just adding more LLMs to the conversation. It demands a fundamental redesign of the developer's role into an orchestrator of inter-agent communication protocols and permission boundaries. The tension you highlighted between autonomy and security feels like the central bottleneck that will determine whether these team architectures remain experimental demos or evolve into production workflows.
When your Planner, Challenger, Coder, and Tester communicate directly rather than routing through the main agent, how do you handle shared state and potential race conditions when multiple agents need to modify the same codebase? Have you found yourself needing to implement explicit locking mechanisms, or does the underlying architecture naturally serialize file operations?