Article 27/50 — Child Agents: Decomposing Complex Agents in Microsoft Copilot Studio

Enterprise AI Agents Series

Architecture, Delegation, Knowledge Specialization, SharePoint Integration, Security, and Enterprise Design Patterns

1. Introduction

Enterprise AI agents rarely remain as simple as their original design.

An organization might initially create a Microsoft Copilot Studio agent to answer questions about corporate policies stored in SharePoint Online. The first implementation may contain a few Instructions, a single Knowledge Source, and no external Tools.

As adoption increases, new requirements emerge.

Employees want to ask questions about HR policies, IT procedures, training programs, procurement processes, and operational documentation. Some departments eventually request transactional capabilities, such as creating service requests or initiating approval workflows.

The original agent gradually becomes responsible for multiple business domains, each with different knowledge requirements, behavioral rules, and operational dependencies.

This creates an architectural challenge:

Should every responsibility remain inside one agent, or should the solution be decomposed into specialized agents?

Microsoft Copilot Studio addresses this problem through multi-agent capabilities, including Child Agents.

A Child Agent allows developers to organize related Instructions, Knowledge Sources, and Tools into a specialized component within a larger agent.

However, decomposition introduces its own considerations. More agents can mean more orchestration decisions, additional execution latency, and a larger testing and governance surface.

This article examines Child Agents from an enterprise architecture perspective, using SharePoint Online as the primary knowledge platform.

The objective is to understand not only how Child Agents work, but also when they improve a solution and when a simpler architecture remains preferable.

2. What Is a Child Agent?

A Child Agent is a lightweight agent that operates within the context of a main agent in Microsoft Copilot Studio.

Child Agents logically group Instructions, Knowledge Sources, and Tools into specialized components within a larger solution.

Consider a corporate assistant responsible for answering questions across several departments.

Instead of maintaining all business-specific behavior within the main agent, the solution can use specialized Child Agents.

Each Child Agent has a clearly defined purpose.

The Parent Agent coordinates requests and delegates work to the appropriate specialist.

This resembles the separation of concerns principle in traditional software engineering, although AI-based delegation introduces probabilistic orchestration rather than purely deterministic function calls.

2.1 Understanding the Agent Harness

The Child Agent functionality described in this article applies to agents powered by the standard harness in Microsoft Copilot Studio.

Other agent experiences, including the GitHub Copilot harness, may offer different composition mechanisms.

Architects must verify which experience is being used before applying a Child Agent design.

3. Parent Agent and Child Agent Architecture

The Parent Agent is the main conversational entry point.

It receives requests, interprets user intent, and coordinates available capabilities.

Child Agents specialize in narrower responsibilities.

A conceptual architecture is:

                  Enterprise User
                         |
                         v
                Corporate Assistant
                   (Parent Agent)
                         |
                Generative Orchestration
                         |
          +--------------+--------------+
          |              |              |
          v              v              v
     HR Policy       IT Documentation   Training
     Child Agent     Child Agent        Child Agent
          |              |              |
          v              v              v
     SharePoint       SharePoint       SharePoint
     HR Policies      IT Documents     Training Policies

This is a logical architecture rather than a representation of every internal platform operation.

The Parent Agent does not need to invoke every Child Agent for each request.

Delegation depends on the user’s request, the available capabilities, their descriptions, and orchestration behavior.

4. Why Decompose an Enterprise Agent?

The strongest reason for decomposition is not the number of documents an agent accesses.

It is the complexity of its responsibilities.

A single agent may answer hundreds of questions from a well-organized SharePoint library without requiring Child Agents.

Conversely, an agent supporting several unrelated business processes may benefit from decomposition even if the total number of documents is relatively small.

4.1 Architectural Benefits

These are potential benefits, not automatic guarantees.

Poorly designed Child Agents can increase complexity instead of reducing it.

5. Child Agents and Logical Independence

A Child Agent exists within the context of its Parent Agent.

It is not equivalent to an independently published enterprise agent.

This distinction is particularly important when designing reusable corporate capabilities.

For example, an HR Child Agent inside a Corporate Assistant does not automatically become an independently deployable HR service.

If an organization requires a reusable HR Agent maintained by a separate department, with its own lifecycle and governance, a Connected Agent may be a better architectural choice.

Logical specialization and operational independence are different requirements.

Child Agents primarily address specialization within a larger agent.

Connected Agents are better candidates when separate ownership, deployment, or cross-agent reuse is required.

6. How Delegation Works

Delegation occurs when a Parent Agent assigns responsibility for a request to a specialized Child Agent.

Consider the following question:

What is the approval procedure for external technical training?

A possible execution sequence is:

1. The Parent Agent receives the request.
2. Generative orchestration evaluates available capabilities.
3. The Training Child Agent is selected.
4. The Child Agent processes the request using its configured Instructions and Knowledge.
5. The resulting information is returned or presented according to the configured behavior.

Generative orchestration is not identical to a hard-coded conditional statement.

Selection depends on the information available to the orchestrator and must be validated through testing.

6.1 Why Descriptions Matter

Consider two Child Agents:

These descriptions are too similar.

A better design provides clear specialization.

Clear descriptions help the orchestration mechanism distinguish responsibilities.

They do not guarantee perfect routing, but they improve the architecture’s clarity.

7. Designing Parent Agent Instructions

The Parent Agent should focus on overall conversation behavior and coordination.

An illustrative configuration is:

You are the Corporate Knowledge Assistant.
Help employees find information from approved
corporate knowledge sources.
Delegate HR policy questions to the HR Policy Agent.
Delegate IT documentation questions to the
IT Documentation Agent.
Delegate training and course approval questions
to the Training Policy Agent.
Do not invent corporate policies.
If sufficient information cannot be found,
explain that the answer could not be verified.
Do not claim that an approval or business
operation was completed unless a configured
capability confirms successful execution.

These Instructions establish the intended behavior of the Parent Agent.

However, Instructions do not create capabilities.

A Child Agent must actually be configured before the Parent Agent can use it.

8. Designing Child Agent Instructions

The Training Child Agent should have a narrower mandate.

For example:

You are the Training Policy Specialist.
Your responsibility is to answer questions
about corporate training policies, course
eligibility, approval requirements, and
training procedures.
Use the configured training Knowledge Sources.
Do not invent approval requirements or budgets.
If the requested policy cannot be found,
state that the available information does
not establish the answer.
Do not create training requests or initiate
approvals. Your role is informational.

This creates a clear behavioral boundary.

The Child Agent is responsible for interpreting training policies, not executing business transactions.

Instructions define intended behavior, but they are not a substitute for authorization or technical security controls.

9. Knowledge Sources and Domain Specialization

SharePoint Online is a natural platform for organizing enterprise knowledge.

Suppose an organization maintains three document libraries.

Each Child Agent can be configured with the Knowledge Sources relevant to its responsibility.

This establishes a clearer relationship between the user’s question, the responsible specialist, and the authoritative information.

9.1 Knowledge Specialization Does Not Require Data Duplication

The same SharePoint repository can remain the authoritative source of corporate information.

Child Agents do not require separate copies of the documents.

SharePoint continues to provide document management, permissions, versioning, metadata, and lifecycle capabilities.

The agent architecture should build upon these capabilities rather than unnecessarily replacing them.

10. Knowledge Versus Action

Knowledge and Action must remain clearly separated.

Consider two requests:

Request A:

What documents are required for an external training application?

This is a Knowledge request.

The agent retrieves and explains documented requirements.

Request B:

Submit my external training application.

This is an operational request.

It requires an authorized Tool or Action capable of creating the corresponding business transaction.

A Training Child Agent may eventually support both capabilities, but they are fundamentally different.

For our initial SharePoint architecture, we will support only informational requests.

This keeps the implementation focused on Retrieval, Grounding, Instructions, and delegation.

11. Retrieval and Grounding in Child Agents

Child Agents do not eliminate the need for reliable Retrieval and Grounding.

They introduce another orchestration boundary within which those capabilities operate.

A conceptual information flow is:

User Question
     |
     v
Parent Agent
     |
     v
Training Child Agent
     |
     v
Knowledge Retrieval
     |
     v
Relevant SharePoint Content
     |
     v
Grounded Response Generation
     |
     v
Result Returned or Presented

Successful delegation does not guarantee a correct answer.

Two separate questions must be evaluated:

1. Did the Parent Agent select the correct Child Agent?
2. Did the Child Agent retrieve and use the correct information?

An agent may select the correct specialist but retrieve an outdated or irrelevant policy.

Therefore, orchestration testing and knowledge quality testing should be treated as separate concerns.

12. Input and Output Contracts

By default, Child Agents can receive natural-language tasks and return natural-language results.

Explicit inputs and outputs may also be configured when structured interaction is required.

For example:

These names are illustrative.

Structured contracts can help the Parent Agent interpret outcomes consistently.

For example, the Parent Agent may need to distinguish between a successful answer, insufficient evidence, and an unsupported request.

However, a result indicating that a policy was found is not independent proof that the generated answer is accurate.

13. What Happens After a Child Agent Finishes?

The communication pattern between Parent and Child Agents is an important design decision.

In the standard harness, the Child Agent’s After running configuration can determine how the Parent Agent proceeds.

Available behaviors include:

The selected completion behavior should not be confused with complete control over every message the Child Agent might send during execution.

For enterprise knowledge assistants, a useful starting pattern is to let Child Agents perform specialized work while the Parent Agent coordinates the final response.

This creates a more consistent conversational experience.

However, the Parent Agent may summarize or transform returned information.

That transformation must be tested when policy accuracy and source attribution are important.

14. Child Agents and Tools

Child Agents can also organize related Tools.

For example, an IT Child Agent might eventually use Tools that:

• Check service request status.
• Retrieve authorized device information.
• Create an IT support ticket.

The Parent Agent can delegate the higher-level responsibility instead of coordinating every individual operation.

14.1 Avoiding Duplicate Capabilities

Suppose the Parent Agent directly exposes a Tool named Check Ticket Status.

At the same time, an IT Child Agent is configured to handle ticket status requests.

Both capabilities may appear relevant to the same question.

This can create orchestration ambiguity.

A better design establishes clear ownership of each operation.

Every important capability should have a well-defined orchestration path.

15. Tool Limits and Orchestration Scope

Microsoft documents limits for Tools used with generative orchestration.

For the standard harness, the documented maximum is 128 Tools per agent, with recommendations to keep the number substantially lower for effective selection.

Child Agents can have their own orchestration and Tool configuration.

This makes decomposition useful for organizing larger capability sets.

However, the maximum number of Tools should not be treated as a design target.

An agent with a small set of well-described Tools may perform more predictably than one exposing many overlapping capabilities.

16. Performance and Latency

Introducing Child Agents adds orchestration complexity.

A request may require the Parent Agent to select a Child Agent, delegate the task, wait for its execution, and process the result.

Additional orchestration steps can increase latency.

This creates a trade-off.

Performance should be measured rather than assumed.

A multi-agent architecture is not inherently faster or more accurate than a single-agent solution.

17. Security Architecture

Security is one of the most important aspects of Child Agent design.

Creating separate Child Agents does not automatically create separate security identities.

Nor does it establish independent authorization boundaries.

The actual security behavior depends on the authentication configuration, Knowledge Sources, Tools, connections, and underlying services.

17.1 SharePoint Permissions

For supported SharePoint Knowledge integration scenarios, retrieval is subject to the signed-in user’s permissions.

Connecting a SharePoint library to an agent does not automatically grant every user access to its contents.

Consider the following example:

An employee who lacks permission to restricted HR documents should not receive that protected content merely because the Parent Agent can invoke the HR Child Agent.

The underlying authorization controls must remain effective.

17.2 Instructions Are Not Security Boundaries

An instruction such as:

Only answer questions about HR policies.

defines intended behavior.

It does not replace SharePoint permissions, API authorization, or connector security.

Sensitive information must be protected by enforceable technical controls.

18. Authentication and Runtime Identity

Every external capability should be evaluated against three questions:

1. Who is the authenticated user?
2. Which identity accesses the external system?
3. Which permissions are enforced?

For SharePoint Knowledge, the supported user-authenticated integration can respect the user’s SharePoint access rights.

For Tools and Connectors, execution identity depends on the configured connection and authentication model.

A Tool using a privileged maker-managed connection may have different access characteristics from a Knowledge Source that uses the signed-in user’s permissions.

This distinction must be documented and tested.

19. Security Testing

Testing only with the agent maker’s account is insufficient.

The maker may have broader permissions than ordinary employees.

A practical security test matrix should include:

Security testing must inspect the generated answer, not merely whether an error occurred.

20. Child Agent vs Tool vs Connected Agent

These concepts solve different architectural problems.

When to Use a Tool

A user asks:

Create a SharePoint list item with this title and description.

A configured SharePoint Tool or Power Automate flow may be sufficient.

When to Use a Child Agent

A user asks:

Explain our external training requirements and identify the documents I need.

This may benefit from specialized instructions and domain-specific knowledge.

When to Use a Connected Agent

An organization already maintains an independent HR Agent used by several business applications.

The Corporate Assistant needs to reuse that capability.

A Connected Agent is a stronger candidate because the HR solution has independent ownership and lifecycle requirements.

21. Child Agent vs Topic

Not every specialized interaction requires another agent.

A Topic may be preferable when the conversation follows a predictable sequence.

For example, a training request might require collecting:

• Employee ID.
• Training course.
• Requested date.

A Topic can implement a deterministic conversational workflow.

A Child Agent is more appropriate when specialized generative reasoning and orchestration are required.

These are architectural recommendations rather than absolute platform restrictions.

22. Practical SharePoint Architecture

Consider a fictional enterprise site:

It contains three document libraries:

• HRPolicies
• ITDocumentation
• TrainingPolicies

The organization wants a single conversational interface without mixing every department’s instructions.

Proposed Architecture

The initial solution deliberately avoids Power Automate, Microsoft Graph, custom APIs, and custom Dataverse application tables.

Those technologies are not necessary for the immediate objective.

The architecture provides a controlled environment for studying delegation and knowledge specialization.

23. Implementing a Minimal Child Agent

The following procedure is based on the standard harness experience.

Step 1 — Create the Specialist

Open the Parent Agent in Microsoft Copilot Studio.

Navigate to:

Agents → Add → New child agent

Create a Child Agent named:

Training Policy Specialist

Step 2 — Define Its Purpose

Use a specific description:

Handles employee questions about corporate
training policies, external course eligibility,
training approval procedures, and required
training documentation.
Use this agent for informational requests
about corporate learning policies.
Do not use this agent for HR benefits,
IT support, or unrelated corporate procedures.

Step 3 — Configure Instructions and Knowledge

Add specialized Instructions.

Configure the relevant SharePoint Knowledge Source.

Verify that the intended test user has access to the documents.

Step 4 — Save and Test

Save the Child Agent.

Test:

What approvals are required before enrolling in an external technical course?

Inspect the orchestration activity and the generated response.

The exact interface may differ depending on product updates and the agent experience.

24. Testing Delegation Systematically

Testing should distinguish routing quality from answer quality.

The evaluation should record whether the correct specialist was selected, whether the relevant Knowledge Source was used, and whether the final answer was accurate.

It should also verify permissions, response time, and unsupported-request behavior.

25. Troubleshooting Incorrect Delegation

Suppose a training question is consistently routed to the HR Policy Specialist.

The investigation should begin with the smallest likely cause.

An important consideration is that citations may not always be preserved when information passes between agents.

For policy-sensitive solutions, source traceability must be explicitly tested.

26. When Child Agents Improve an Architecture

Child Agents are useful when a responsibility has several of these characteristics:

• A distinct business purpose.
• Specialized Instructions.
• Domain-specific Knowledge Sources.
• Multiple related Tools.
• Clear inputs and outputs.
• A meaningful testing boundary.
• Shared ownership with the Parent Agent.

An IT Documentation Specialist, for example, may support several related tasks involving workstation configuration, technical standards, and internal troubleshooting procedures.

These responsibilities form a coherent domain.

27. When Not to Use Child Agents

Multi-agent architecture should not be adopted merely because it is available.

Consider an agent that answers questions from a single SharePoint library containing ten documents.

It has no Tools, no complicated Instructions, and no competing business domains.

Creating a Parent Agent and several Child Agents may introduce routing complexity without improving the solution.

Architecture Decision Matrix

The goal is not to maximize the number of agents.

It is to minimize unnecessary complexity while meeting business, security, and operational requirements.

28. Architectural Trade-Offs

Decomposition creates benefits and costs.

The appropriate architecture depends on the requirements of the organization.

Neither a single-agent nor a multi-agent design should be considered universally superior.

29. Incremental Migration Strategy

A mature enterprise solution does not need to begin as a multi-agent system.

A practical migration strategy is:

1. Start with a single Agent and one narrow knowledge domain.
2. Add another domain and measure routing and answer quality.
3. Extract one clearly bounded responsibility into a Child Agent.
4. Compare accuracy, latency, maintainability, and security.
5. Introduce additional Child Agents only when the results justify decomposition.

This creates an evidence-based architecture rather than a speculative one.

30. Enterprise Governance

Child Agents should be included in the organization’s agent governance model.

A Child Agent does not need to be treated as an independently deployed application.

However, its responsibilities and capabilities should still be documented.

31. Common Design Mistakes

Creating one Child Agent per document.

Documents are content assets, not necessarily separate architectural responsibilities.

Using overlapping descriptions.

Similar descriptions make orchestration less predictable.

Treating Instructions as authorization.

Behavioral guidance cannot replace technical security controls.

Exposing duplicate Tools.

Multiple competing paths can complicate capability selection.

Assuming independent deployment.

Child Agents and Connected Agents have different lifecycle characteristics.

Testing only successful questions.

Negative tests and unauthorized access scenarios are essential.

Ignoring response transformation.

The Parent Agent may summarize information returned by a Child Agent. This must be tested when accuracy and citations matter.

32. Reference Architecture Recommendation

For a SharePoint-centered corporate knowledge assistant, a reasonable starting architecture is:

This architecture is appropriate when the business domains are sufficiently distinct to justify specialization.

For a small homogeneous knowledge base, a single Agent remains preferable.

For independently managed capabilities, Connected Agents should be evaluated.

33. Learning Journey — Where We Are and What’s Next

This article is part of a progressive technical series covering the design and engineering of enterprise AI agents.

This progression is intentional.

Before designing a complete multi-agent architecture, we must understand the properties and boundaries of each component.

Article 27 establishes Child Agents as specialized components within a larger solution.

Article 28 will examine Connected Agents and the requirements associated with independent ownership, deployment, and reuse.

Article 29 will compare both approaches and establish a practical decision framework.

34. Official Microsoft Documentation

The following Microsoft Learn resources provide technical guidance for the concepts discussed in this article.

1. Add a Child Agent
   https://learn.microsoft.com/en-us/microsoft-copilot-studio/add-agent-child-agent
2. Add Other Agents Overview
   https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-add-other-agents
3. Multi-Agent Orchestration Patterns and Best Practices
   https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/multi-agent-patterns
4. Generative Orchestration
   https://learn.microsoft.com/en-us/microsoft-copilot-studio/advanced-generative-actions
5. Write Agent Instructions
   https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-instructions
6. Add Tools to Custom Agents
   https://learn.microsoft.com/en-us/microsoft-copilot-studio/add-tools-custom-agent
7. Add SharePoint as a Knowledge Source
   https://learn.microsoft.com/en-us/microsoft-copilot-studio/knowledge-add-sharepoint
8. Configure End-User Authentication
   https://learn.microsoft.com/en-us/microsoft-copilot-studio/configure-enduser-authentication
9. GitHub Copilot Harness FAQ
   https://learn.microsoft.com/en-us/microsoft-copilot-studio/agents-experience/faqs-copilot-harness
10. Connected Agents in the GitHub Copilot Harness
    https://learn.microsoft.com/en-us/microsoft-copilot-studio/agents-experience/authoring-add-other-agents

Because Copilot Studio evolves rapidly, implementation details, interface labels, and feature availability should be validated against the current Microsoft documentation and the agent harness being used.

35. Final Technical Summary

Child Agents provide a mechanism for organizing specialized responsibilities inside Microsoft Copilot Studio.

They allow developers to group related Instructions, Knowledge Sources, and Tools into focused components that participate in a larger orchestration process.

Their principal value is logical decomposition, not automatic security isolation or independent deployment.

A successful Child Agent architecture depends on clear responsibility boundaries, precise descriptions, carefully designed inputs and outputs, appropriate access controls, and systematic evaluation.

In SharePoint-centered enterprise solutions, Child Agents can help organize knowledge across business domains without duplicating repositories or introducing unnecessary integrations.

However, they should be introduced only when specialization offers a demonstrable benefit over a simpler design.

A well-designed enterprise AI solution does not need more agents. It needs the right boundaries between responsibilities, knowledge, operations, and security.