Recently, I had a conversation with a Solution Architect about different Copilot Studio approaches. We started discussing the creation of agents—specifically whether to create new standalone agents that can connect to other agents, or child agents that exist within a parent agent.

We are all familiar with the Parent/Child concept, but what exactly is the difference between them in Copilot Studio, and what should be the practical architectural approach?

1 – Creating an agent (Standalone/Parent Agent)

When you create a standalone agent that can be connected to by other agents, Copilot studio provisions it a fully autonomous, publishable AI product.

Note:

• Whenever a new agent is provisioned, 14 agent components are created in your solution.
  • Although Microsoft has increased solution size limits, it is still important to be mindful of the number of artifacts being introduced into your solution.

2 – Creating a Child agent

It is a lightweight agent created within the context of a parent agent.

Note:

• Whenever a child agent is created, 1 agent component is added to your solution as a Topic. Additional artifacts may be created depending on the tools or other resources you connect to the child agent.
  • Tools connected to child agents are also created as Topic components in the solution.

3 – Capability comparison

Regular agent (Connectable, Full Agent)

Benefits

1 – Reusable across multiple parent agents

• Can be connected to multiple orchestrator agents
• Ideal for shared capabilities. (e.g., a Policies Agent)

2 – Independent lifecycle

• Can be published, governed separately
• Better ALM support for enterprise scenarios
• Support environment promotion

3 – Separate governance

• independent tracking and telemetry
• Clear ownership and accountability

4 – Future proof

• Can be exposed across multiple channels (Microsoft Teams, web, etc.)
• Can invoke child agents

Trade-offs:

A larger number of artifacts in the solution

Child Agent (Lightweight)

Benefits

1 – Minimal footprint

• Fewer artifacts
• Simpler creation

2 – Tightly scoped execution

• Designed for a single responsibility or intent
• Helps prevent orchestrator confusion by limiting tool usage to explicit instructions

Trade-offs:

• Cannot be published independently
• Can only be invoked by its parent agent
• Cannot be reused by another parent agent
• No independent ALM, ownership, or lifecycle management

Architectural Rule of Thumb

If you would ever want more than one agent to use it →  Create a full regular agent.

If it only exists to help one parent act → Create it a child agent.

If you have additional thoughts, alternative patterns, or edge cases you’ve encountered, I’d be interested to continue the discussion.