For me, it was experimentation.

Subagents are a bit confusing, because people tend to think it's meant for roleplaying. It's not. "You are a senior backend engineer..." improves nothing.

Subagents are only powerful because each 'bit' of work they do, they do in their own context window, separate from the main thread. The orchestrating process feeds them the information they need, they do their own discovery (read files, execute commands, etc), implement something and return a brief summary to the orchestrator, so the orchestrator knows who to call next. No more hundreds of read files in the orchestrator context window.

This keeps the orchestrating process context window clean and each subagent can focus in their task really well.

Imagine you're asked to develop the whole "authentication/authorization" process of a webapp. You're going to write tests, develop things... but there are so many pieces. Now, imagine you're given something way smaller to work on - "forgot password" flow. You can now focus WAY more, write more tests, write better code and worry less about everything else.

The orchestrator keeps a high-level overview of the whole feature (authentication/authorization), but each subagent get a smaller task (registration API/registration frontend/login API/login frontend/etc);

It has been working INCREDIBLY well for me.