Copilot Studio: Child Agents vs. Connected Agents

Microsoft is changing how makers build multi-agent solutions in Copilot Studio—but the change is more nuanced than “child agents are gone.”

In the classic experience, child agents remain a supported way to organize a focused task inside a main agent. In the new agent experience, Microsoft uses a different composition model: a primary agent invokes separately created connected agents. The new experience is currently a production-ready preview, exists alongside the classic experience, and does not provide an automatic conversion path between the two. Microsoft Learn: Classic vs. new agent experience

That distinction matters. This is not simply a renamed button. It is a change in the architectural boundary between an orchestrator and the specialist capabilities it calls.

How Copilot Studio reached this point

Copilot Studio’s multi-agent model has evolved quickly. Child agents emerged during the platform’s 2024 agent expansion as the original inline composition pattern. The exact claim that they reached general availability in the first quarter of 2025 is difficult to substantiate from Microsoft’s current public documentation, so it should not be treated as a confirmed milestone here. What the current documentation does confirm is that child agents remain available in the classic experience as lightweight agents contained within a main agent. Microsoft Learn: Add a child agent

The larger architectural shift became explicit at Microsoft Build on May 19, 2025. Microsoft announced multi-agent orchestration in which Copilot Studio agents could delegate work to agents originating from the Microsoft 365 agent-building ecosystem, Azure AI Agents Service—the predecessor naming used in that announcement—and Microsoft Fabric. At announcement time, that broader capability was in private preview, with public preview planned. Microsoft Build 2025: Multi-agent orchestration announcements

Microsoft’s current classic-experience documentation now separates the choices more clearly. Makers can create a child agent, connect another Copilot Studio agent in the same environment, or connect supported external agent types such as A2A-compatible agents, Microsoft Foundry agents, Fabric Data agents, and agents built with the Microsoft 365 Agents SDK. Availability differs by connection type, and some integrations remain preview features. Microsoft Learn: Add other agents overview

This history explains the design change. Child agents began as a convenient way to decompose one agent. Connected agents extend the model into a network of independently managed specialists. The second model does not invalidate the first, but it gives architects a stronger reuse and ownership boundary.

The mental model: modules versus services

A useful analogy is the difference between a module inside an application and a separately deployed service.

A child agent behaves like an internal module. It helps divide a large agent into smaller responsibilities, but it remains part of the parent solution. A connected agent behaves more like a service. It has an independent boundary and can be invoked by another agent when its specialty is needed.

Architectural question	Child agent	Connected Copilot Studio agent
Where does it live?	Inside the main agent	As a separate agent in the environment
Can it be published independently?	No	Yes
Can it be reused by multiple primary agents?	Not as an independent agent	Yes
Does it have its own orchestration context?	No; it operates within the main agent’s context	Yes; it has its own instructions, knowledge, and tools
How is context handled?	Context is naturally shared within the parent	Relevant conversation history can be passed by the primary agent
Best fit	A focused subtask owned with the parent	A reusable domain capability with an independent lifecycle

This is why connected agents are not merely “better child agents.” They solve a different decomposition problem.

What child agents actually are

Microsoft describes a child agent as a lightweight agent that exists within the context of the main agent. It groups instructions, tools, and knowledge around a narrow task—for example, checking an order, creating a ticket, or translating text. By default, the main agent gives the child agent a natural-language task, and the child returns a natural-language summary. Makers can also define explicit inputs and outputs. Microsoft Learn: Add a child agent

In exported or code-view definitions, a child agent may appear through tool-selection semantics such as OnToolSelected. That implementation detail is useful, but it should not be stretched into the claim that a child agent is “not really an agent.” At the orchestration boundary, even a connected agent can be treated as an agentic tool by the primary orchestrator. The more meaningful distinction is ownership and lifecycle, not whether the runtime exposes tool-like invocation semantics. Microsoft Learn: Multi-agent orchestration patterns

Child agents remain a sensible choice in the classic experience when:

• the capability serves one main agent;
• one team owns the full solution;
• the specialist does not need independent authentication, settings, deployment, or channels;
• the logic is narrow and cohesive; and
• reuse outside the parent is unlikely.

Their biggest strength is low-friction composition. Their biggest constraint is the same thing: they are intentionally coupled to the parent.

What connected agents change

A connected agent is created and managed separately from the primary agent. When a user’s request fits the connected agent’s domain, the primary agent’s orchestrator can delegate the task. The connected agent processes it in its own orchestration context and returns a response to the primary agent, which then presents the result to the user. Microsoft Learn: Connected agents overview

This boundary creates four practical advantages:

1. Specialization — Each agent can concentrate on a clearly defined domain.
2. Reusability — The same specialist can be connected to more than one primary agent.
3. Independent ownership — A domain team can maintain its agent without editing every consuming orchestrator.
4. Controlled growth — You can add a new specialist instead of continuously expanding one agent’s instructions, tools, and knowledge.

The primary orchestrator still needs a reliable way to decide when to delegate. Descriptions therefore function like routing contracts: if two tools or agents have vague or overlapping descriptions, the orchestrator has less information with which to choose correctly. Microsoft explicitly recommends making the connected agent’s description specific to the context in which the primary agent will use it. Microsoft Learn: Connect to an existing Copilot Studio agent

Conversation context is configurable—not magic

Early inline designs were attractive because the parent and child naturally shared conversational context. Connected agents now address much of that gap by allowing conversation history to be passed during delegation.

For a connected Copilot Studio agent, Pass conversation history to this agent is enabled unless the maker clears it. If disabled, the connected agent receives only the explicit task supplied by the main agent. Microsoft Learn: Connect to an existing Copilot Studio agent

The source demonstration also shows a Trigger a conversation start when calling this agent option in its version of the classic interface. That setting is distinct from history passing: it controls whether the called agent’s conversation-start behavior runs when invoked. Because Microsoft’s current connection article does not document that option, treat its presence and wording as interface-dependent rather than as a universal architectural guarantee. Verify it in the target environment before making a design depend on it.

That checkbox is not merely a convenience setting. It is an architectural decision:

• Pass history when the specialist needs earlier user statements, preferences, or clarifications.
• Do not pass history when the task can be expressed completely in the delegation request or when data minimization is more important than conversational continuity.
• Use explicit inputs when the interaction depends on stable, testable values rather than the model inferring state from a transcript.

A good rule of thumb is to pass the minimum context required for reliable execution. More context is not automatically better context.

What the new Copilot Studio experience really means

The new agent experience introduces a redesigned authoring surface and an enhanced orchestration runtime. It is instruction-first rather than topic-first: makers describe behavior through natural language and assemble instructions, knowledge, tools, and skills in a unified surface. It is currently documented as a production-ready preview, and some classic capabilities are still unavailable. Microsoft Learn: Agents overview

Within that new experience, connected agents are the multi-agent composition model. Microsoft currently documents support there for connecting other agents built in Copilot Studio. This is narrower than the classic experience’s broader “add other agents” surface, which also documents child agents and connections to external agent types, with some external integrations carrying preview status. Microsoft Learn: Connected agents overview Microsoft Learn: Add other agents overview

The interface language reflects the architectural distinction. The classic experience presents a general Add an agent flow, where the relationship can be a child or a connection. The new experience presents Connected agents and Add a connected agent, and its picker lists eligible standalone agents rather than offering creation of an inline child agent. Labels can change during preview, but the underlying distinction is more important than the wording: inline ownership versus connection to a separately created agent.

So, if the Add a child agent command is absent in the new experience, do not infer that Microsoft has globally retired child agents. The accurate conclusion is narrower:

Prerequisites that commonly block a connection

In the classic experience, another Copilot Studio agent can be connected only when the documented prerequisites are met. The target agent must:

• be in the same Power Platform environment as the main agent;
• be published;
• allow other agents to connect to it; and
• be owned by or shared with the maker creating the connection.

Depending on authentication, the connected agent might also need to be shared with the main agent’s end users for the call to work at runtime. Microsoft Learn: Connect to an existing Copilot Studio agent

Changes to a connected agent must also be republished before the primary agent can use the updated version. In addition, the description stored by the primary agent is local to that connection; later description changes on the connected agent do not automatically synchronize to existing consumers. Microsoft Learn: Connect to an existing Copilot Studio agent

The same-environment boundary

For Copilot Studio-to-Copilot Studio connections, Microsoft currently requires the primary and connected agents to reside in the same Power Platform environment. Microsoft Learn: Connect to an existing Copilot Studio agent

That limitation affects enterprise architecture. Many organizations separate development, test, and production environments, or isolate business units to reduce unintended dependencies. A same-environment connection means teams cannot treat a Copilot Studio agent in another environment as a directly selectable connected agent.

This does not eliminate modularity, but it changes how boundaries must be drawn. A reusable agent and its consumers need a coordinated environment and application lifecycle management strategy. Cross-environment composition should not be presented as an available Copilot Studio control unless Microsoft documents a supported mechanism for the specific agent type involved.

Security follows the call chain

Connected agents can have different tools, knowledge, and privileges from the primary agent. That independence is valuable, but it creates a trust boundary.

If a primary agent cannot perform a sensitive action but can call a connected agent that can, the connection must not become an accidental privilege-escalation path. Microsoft recommends applying appropriate checks or user consent to sensitive operations and monitoring when connected agents are invoked. Microsoft Learn: Multi-agent orchestration patterns

For each connection, validate:

• what conversation data crosses the boundary;
• which identity and connection credentials are used;
• what knowledge the connected agent can retrieve;
• what actions it can perform;
• whether end users are authorized to invoke those capabilities; and
• how delegation and downstream actions will be tested and monitored.

The principle is simple: modularity does not erase authorization boundaries.

Migration guidance: plan a redesign, not a conversion

There is currently no supported conversion path between agents created in the classic and new experiences. Microsoft states that agents created in one experience cannot be transferred to the other. Both experiences remain available, and makers can switch the authoring interface from the Copilot Studio home page—but switching the interface does not convert an existing agent. Microsoft Learn: Classic vs. new agent experience Microsoft Learn: Switch between experiences

That leads to a more measured migration strategy than “rebuild everything now.”

1. Keep stable classic solutions stable

Do not manufacture an emergency where Microsoft has not announced one. If a classic agent with child agents is meeting its requirements, continue maintaining and testing it while tracking official product documentation and lifecycle announcements.

2. Inventory each child agent

For every child agent, record:

• its responsibility;
• instructions, knowledge, and tools;
• inputs, outputs, and variables;
• dependencies on shared conversation context;
• authentication and connection requirements;
• owners and expected consumers; and
• whether it needs an independent channel or reuse by other orchestrators.

3. Choose the correct target boundary

Use one of two refactoring patterns:

• Keep the logic inline: Move a small, parent-specific responsibility into the main agent’s instructions, skills, tools, or topic design as appropriate for the target experience.
• Create a connected agent: Rebuild a cohesive, reusable domain capability as a separate agent and connect it to the primary orchestrator.

Do not modularize merely for the sake of having more agents. Every agent boundary adds routing, testing, identity, publication, and observability considerations.

4. Redesign context transfer explicitly

Document what the child previously obtained implicitly from the parent. Decide whether the new connected agent should receive conversation history, explicit parameters, or both. Test ambiguous, incomplete, and adversarial prompts—not only the happy path.

5. Test the system, not just the specialists

A connected agent can perform perfectly in isolation while the overall solution still fails because the primary agent does not select it reliably. Test:

• correct delegation;
• intentional non-delegation;
• overlapping agent descriptions;
• context minimization;
• user authorization;
• downstream tool behavior;
• failure and fallback behavior; and
• behavior after either agent is republished.

Architecture decision guide

Choose a child agent in the classic experience when the capability is a focused internal responsibility, shares the parent’s lifecycle, and does not need independent reuse or publication.

Choose a connected agent when the capability has a stable domain boundary, needs independent ownership or publication, or should serve multiple orchestrators.

Keep the capability inside one agent without a subagent boundary when the task is too small to justify another routing decision or when splitting it would make the behavior harder—not easier—to understand and test.

Final perspective

The important change in Copilot Studio is not that every child agent has suddenly become obsolete. It is that Microsoft now offers—and in the new experience emphasizes—a stronger boundary for composing independently managed agents.

Child agents optimize for local organization and shared context. Connected agents optimize for independence, reuse, and domain separation. Neither pattern removes the need for clear descriptions, deliberate context transfer, secure authorization, publication discipline, and end-to-end testing.

The right migration question is therefore not, “How do I replace every child agent?” It is:

Answer that well, and the move from inline child agents to connected agents becomes an architectural improvement rather than a hurried rewrite.