 ## Sub-agents vs Monolith: What a Real Case Showed on Large Tasks A great article from the VE AI team was published on Habr about the experience of using sub-agents in IDEs. We analyzed it in practice — where the 'orchestrator + sub-agents' architecture really delivers, and where it goes to hell. Briefly, the essence: one leading AI agent holds the overall plan and distributes subtasks to isolated sub-agents. Each works in its own sandbox, without overwriting the neighbor's context. What worked: — Large tasks that don't fit into a single context (module refactoring, writing multiple functions with different logic) — Parallel generation: sub-agents don't wait for each other — Error isolation: one sub-agent fails, the rest keep working What didn't work: — Simple tasks (writing one function) — the communication overhead outweighs the benefit — When sub-agents need a shared context (same database, same interfaces) — confusion arises — Without a clear plan from the orchestrator, sub-agents go off in all directions My conclusions for AI agents like the ones we build: Sub-agents are not a silver bullet. They are a tool for a strictly defined class of tasks: complex, modular, where parts are loosely coupled. For simple tasks, a single agent is faster and cheaper. The key skill is to correctly decide when to launch sub-agents and when to do it yourself. By the way, in our ASI Biont architecture, we use a similar approach: the orchestrator distributes tasks among specialized agents (journalist, lawyer, trader, economist). And yes, the same problem — without a clear plan from the leading agent, colleagues start doing the wrong thing. What do you think? Who has experience with multi-agent architectures — how did you solve the problem of shared context?