One of the many cool things about Copilot Studio is child agents, but I rarely see them in practice and I wondered why. Child agents give you so many new capabilities, and although they shouldn't be used all of the time, having them in your tool box is super useful. They have some particularly cool features:
- Reusability
- Parallel/speed
- Controlled Knowledge
- Controlled Inputs
- Different Models/cost
- Controlled Tools
Note distinct Instructions is also a benefit, but I thought that was self explanatory in using child agent so didn't mention it.
1. Reusability
This is the one that most people do know about, Child agents allow you to refuse the agent on other agents. Being able to reuse means "one version of the truth" and only having one version to maintain/update.
A good example would up and integration with a system like Service Now. The child agent could have all of the knowledge sources setup. MCP/tools, and refined topics/skills that deliver improved and consistent results.
This means:
- Every agent returns same results (as much as you can with LLM's)
- New tools and deprecations are rolled out easily and uniformly
- ALM like model changes are done once
2. Parallel/speed
This is a bit of a grey one, as although it's a big thing in other harnesses like GitHub and Claude, Copilot Studio defaults to sequential. But that doesn't mean you can't run the child agents in parallel, it just takes some effort, you need to:
- Call out the in instruction that parallel should be done when possible
- Describe the process as parallel in the topic/skill.
The benefits are clear, speed. Running in parallel means your user gets the results back faster then waiting for each tool/reasoning to run.
3. Controlled Knowledge
This is one of the best reasons to use child agents, we are able to ring fence knowledge sources. This is key when you have variants that have a lot of overlap but have different data.
A good example would be code reviews, lets say your agent code reviews Power Platform solutions (follow me if you want to see this in practice 😎) The solution has lots of components that need to be code reviewed, and each of them differently. Things like Power Automate expressions and Power FX are very different, and we don't want the agent to confuse the syntax and standards.
We also have the potential for repetion, with solution issues as an example, appearing multiple times. This can definitely be handled with topics and skills, but that is a lot harder to maintain, having distinct knowledge sources, only used in the context of that component, will always be the best approach.
4. Controlled Inputs
This is the flip side to Controlled Knowledge, and often used in tandem. You are able to strip out all the unnecessary context gathered by the main agent, and ensure the child agent only uses what you send.
Back to our code review example, for the Power Automate review agent we would only send the Power Automate data, for the Power App, only the app data, and so on.
Every bit of contradictory piece of information can be stripped out, delivering a "One version of the truth". And best of all those inputs can be used to guide the agent more. It no longer has to decide on what the key value is, it is told.
5. Different Models/cost
But if the agent decides on the inputs then how does that make it better then just the child agent deciding, good question, and that's because we can also save capability, and some precious credits.
Child agents allow us to use different models, in the above example we would us a "dumber" model, saving us credits. The expensive model can do all of the analysing and reasoning, then pass on the data and process to a cheaper model.
Being able to distribute tasks to the right skilled model is key, in real life you wouldn't expect the surgeon to tidy up the theatre after, no that would be a waste of their experience and money.
We can also flip this the other way, with out main agent being just smart enough, and then when we need the extra capability we pass it to a smarter child flow.
It could also be as simple as certain models being better at certain tasks, being able to split the session into distinct tasks based on skills allows the scope to improve performance through model selection.
This adds lots of complexity, and requires lots of testing to understand where the benefits are, but in the long run it will be worth it because you will get:
- Better performance
- More consistent performance
- Cheaper sessions
6. Controlled Tools
This one is more of security capability, but is very much need for your agents that have lots of capability. Being able to segregate tools to agents allows you to ring fence data and decision making.
A good example would be you want to pull sensitive data from a customer database, make decisions, and then email someone. Having one agent would give the agent the capability to:
- Get any data (within what it needs for decision)
- Send that data to anyone (within what it needs for the process)
So it is possible the agent decides one day to send data from the decision which should never have been sent.
But with a decision and send child agents, the decision data is never passed to the send agent.
Another benefit is limiting the agent from going off plan. An example would be an agent that can create, update and delete data from a database. The agent has those 3 capabilities because users want to be able to do each individually.
But what if something went wrong, like the agent could update a record because of an external permission issue, LLM's are very persistent and creative, it has happened before where they decide to delete the record and create it again. They don't know the impacts of deleting as their knowledge is scoped, so it could:
- Break relationships
- Break timelines/reporting (new created date)
- Lose information in field level columns it cant read
As you can see child flows give makers many capabilities that can improve, scale, and make your agents more stable. That's not to say they should be used all of the time, you have to balance complexity and ROI, some agents simply wont need or they don't return enough value to invest in them.
Top comments (0)