Sub-Agent Architectures: Patterns, Trade-offs, and a Kotlin Implementation

The Problem Single-agent systems hit a wall fast. Give one agent too many tools and a complex task, and you get: Context bloat — every intermediate result accumulates in the conversation history Tool confusion — a model with 20 tools tends to make worse decisions than one with 5 (tool-use accuracy degrades with scale; see the Gorilla LLM benchmark for empirical evidence) No isolation — a failed step can corrupt the entire conversation state No parallelism — sequential execution even when tasks are independent Larger context windows reduce but don't eliminate these problems. A 1M-token context still degrades with irrelevant history, and tool confusion is a model behavior issue independent of window size. Architecture is the more scalable solution — but it's a trade-off, not a free lunch. Sub-agents add latency, coordination complexity, and cost. What Is a Sub-Agent? A sub-agent is a separate LLM call with its own isolated conversation context, invoked by a parent agent to handle a speci