Skip to main content

Command Palette

Search for a command to run...

Orchestrating Agents vs Reality: My Failure to Delegate and What I Learned

Updated
3 min read
M

I am a mobile developer specialising in Android and Flutter. I maintain open-source Flutter packages on GitHub and pub.dev. This blog is where I share my experiences and insights from my development journey.

In short:

  • Narrow the manager’s expertise so it can’t do everything.

  • Not always need a complex multi-agent system

  • Try not to think in a human company way, by context instead

Last year, Orchestrating brought a lot of excitement to AI project enthusiasts. Numerous solo projects and skills are flourishing on GitHub. The design phase feels truly wonderful, but diving into reality reveals it's not as easy as it seems. Here is my journey.

At the beginning, I tried to build an agent project with collecting local news and analysis with CrewAI orchestrating mode. With a manager agent (CrewAI orchestrator) first process the updated news article and pass to the professional colleagues (sub-agent) to analysis based on their professional background including technology, business, public health wealthy and political.

It felt like having a small team in a company, but often, the manager agent ended up handling most of the tasks on its own instead of delegating them to the sub-agents even i change the prompt to "force" it to

I tried to figure out why some tasks were easily delegated to the sub-agent while others weren't. After going through discussions with other developers and examining my own use case, I realized the issue was that my manager agent had a broad range of expertise. I initially thought this would help it assign tasks to the right person, but instead, it felt capable enough to handle everything on its own. The one task that was consistently delegated was the one I hadn't included in the manager's background by mistake.

So i changed a bit of the "background" of the manager agent. And now some cases are able to get task from the manager agent. So, if that really the case, then i started to think, since we now have the skills for different aspect, do I really need to cater the "role" of the agent is? instead why not I let the main agent to select the required skills to handle the analysis task? Then I changed a bit. Now the analysis fit what i preferred and even faster then previous.

In the end I moved away from trying to make the manager a multi‑domain expert and instead made it a dispatcher: the manager now identifies which retrieval-augmented (RAG) skills to call, reviews their outputs, and coordinates fixes. After all, not every case actually require to be so complexly implemented. Instead of build the agent system to fit our sense of a team/company, it will be easier and better to think how the context can be cut logically.