Copilot Studio: Agents Hand Work to Each Other – and Who Approves It?

Picture a perfectly ordinary request. An employee asks Copilot Chat about the parental leave rules. A sales colleague needs a proposal text that fits the brand guidelines. A department head wants to know which wording the legal team has approved for customer contracts. In all three cases the answer should not be “roughly right” but authoritative: as it applies in the company, and ideally always the same.

For exactly such cases, Microsoft published an announcement in the Message Center on October 21, 2026, which becomes generally available today, October 26, 2026. It carries the number MC1518233 and the title “Copilot Studio – Enhanced support for Copilot Chat agents.” This article shows what it says, what it explicitly does not say and what you can derive from it as the managing director of a mid-sized company. We stay close to the source and label every opinion of our own as such.

One note on the source situation, because transparency matters here: the Message Center itself is an administration area and requires a sign-in. We therefore could not read the entry in the original, but through a public mirror (mc.merill.net/message/MC1518233). The content is paraphrased there. Whatever we describe below as Microsoft’s statement comes from this mirror, and we have kept the feature names unchanged.

What Microsoft announced: six building blocks for Copilot Chat agents

The entry is about Copilot Chat agents, which Microsoft also calls “declarative agents”: agents that are described by instructions and work inside Copilot Chat. According to the entry, they are meant to deliver authoritative answers and standardized content. As examples, the announcement names standardized answers to HR questions and content that follows brand guidelines and legal requirements. That is a strikingly sober description of the goal: it is not about creative flights of fancy but about reliable, repeatable answers.

For building such agents in Copilot Studio, the entry names six capabilities. We list them in the order of the source:

• Topics for deterministic conversation flows. “Deterministic” means the flow is fixed and not re-rolled every time. For a question about a fixed procedure, the same path should always be followed.
• Connected Agents, to delegate work. One agent can therefore hand parts of a task to another agent.
• Evaluations, to improve agent quality. The source gives no details on how the assessment works.
• Monitoring, to track how the agents are used.
• A native preview in Copilot Chat with an activity map. It makes it possible to test and understand what users will see.
• Agent lifecycle management with separate agent versions for development, test and production.

As required action, the entry, according to the mirror, explicitly names none (“No action required”); it is for information. It recommends reviewing the new capabilities and assessing whether they improve existing development processes for Copilot Chat agents. Internal documentation and training material should also be updated where needed, and the capabilities communicated to makers and development teams. At Microsoft, “makers” are people who build agents and applications in the Power Platform, often in the business departments rather than in IT.

Laying the six building blocks side by side, it stands out that four of them do not concern the intelligence of the agent but its controllability: fixed flows (topics), quality measurement (evaluations), observation (monitoring) and orderly transitions between draft, test and operation (lifecycle). Only Connected Agents extend what an agent can do, namely hand work on. That is our observation, not a statement by Microsoft, but it matters for the classification: the announcement is less a leap in capability than a step toward operational maturity.

Four of six building blocks are not about what an agent can do, but about how you steer it, check it and put it into operation. That is the real news for the mid-market.

Connected Agents explained: when an agent hands off work

The term “connected agents” sounds more technical than it is at its core, so here is a short explanation as a building block of knowledge. Many people imagine an agent as a single assistant: you ask, it answers. With delegation, an agent works more like a team lead. She receives a task, recognizes that part of it is better placed with a colleague who has a different specialty and hands that part over. The result flows back, and the first agent continues her own work with it.

An example from practice, explicitly a thought experiment and not a description of a Microsoft use case: an agent answers questions about travel expenses. It knows the rules of the travel expense policy. But if someone asks about the tax treatment of a trip abroad, it could pass this sub-question to a second agent specialized in tax topics instead of guessing. The advantage lies in specialization: every agent has a narrow assignment, and narrow assignments are easier to check than a single agent that is supposed to know everything.

The price is a new kind of responsibility. As soon as two agents work together, there is a handover point, and handover points are where the typical mistakes happen. Information gets lost, an assignment is understood differently from how it was meant, or the second agent has rights the first should never have. Questions you ask only once for a single agent now arise for every connection: what may the agent pass on? What does the other one get to see? Who sees the result at the end before it reaches anyone?

The source describes connected agents only with the statement that they serve to delegate work. How the handover works technically, which permissions apply and whether connections can be restricted is not stated. We therefore explain the principle, not Microsoft’s implementation. Anyone who wants to use connected agents should read Microsoft’s product documentation on these points before making assumptions.

Availability, source situation and what we do not know

Let us start with what is documented. According to the announcement of October 21, 2026, the date of general availability is October 26, 2026. That is today. A note on a trial phase or preview for the named capabilities does not appear in the mirror of the entry. To that extent we can state: according to the Message Center, the capabilities are generally available as of today.

Equally important is what is missing. According to the mirror, the entry contains no information on licenses and none on regions. Concretely, that means:

• Whether a specific license or add-on package is needed for use is not documented.
• Whether the capabilities are available in all regions, and thus in Germany, Austria and Switzerland at the same time, is not documented. For the DACH region the status is therefore: unknown.
• Whether and how connected agents can be restricted or switched off in your tenant is not documented.
• Whether your administrators see the capabilities immediately or whether the rollout is staggered is not documented.

We say this so plainly because in conversations with companies the sentence comes up quickly: “We already have that, we use Microsoft 365.” That may be true, but it answers none of the four questions. Whether something is available to you depends on your contract, your tenant and your region, and your Microsoft contact or your IT administration can clarify that. We cannot judge it from the outside and therefore do not claim it.

What we also do not know: the entry names no usage figures, no costs and no experience reports. It describes no limits of the capabilities, such as how many agents can be connected or how deep delegation chains may go. It says nothing about how reliably delegation works in everyday use. And it says nothing about the data protection assessment, for example when an agent passes questions containing personal data, such as from the HR area, to another agent. The HR example of the source shows precisely why this question must be answered before use.

From these gaps follows a simple stance that we recommend: treat the announcement as reliable news about a product, but as an open question about your own situation. The news is “there are now connected agents, monitoring and lifecycle management in Copilot Studio.” The open question is “which of it may and should we use.”

What this means for a mid-sized company: four steps to prepare

The source recommends reviewing the capabilities, adapting documentation and training and informing the makers. That is right, but still fairly general for a company with 50 or 150 employees. We translate it into four concrete steps. They are our recommendation, not a Microsoft requirement, and they are deliberately chosen so that you can start them without technical background.

Step 1: Inventory. Find out which Copilot Chat agents already exist in your company and who built them. In many organizations such agents emerge in the business departments without the management knowing about them. A simple list is enough: name, purpose, responsible person, which information the agent uses. Without an inventory, you can later judge neither quality nor usage.

Step 2: Who may build and who may connect? The question of who may create an agent is familiar. The second question is new: who may connect agents with each other? With connected agents, a harmless agent with a narrow assignment can suddenly hand work to an agent with far-reaching capabilities. Define that connections do not arise silently but are deliberately approved by a named person. Whether this can be enforced technically in your tenant is, as described above, not documented. An organizational rule is possible regardless.

Step 3: The test-versus-production rule. According to the source, lifecycle management separates development, test and production. Use this separation as a rule: nothing that employees rely on for binding answers is changed directly in the production version. Every change first goes through the test version and is looked at there by a second person. Anyone who does not follow this has the feature but not its benefit.

Step 4: Name owners for evaluations and monitoring. Both capabilities are only as good as the people who look at the results. Decide in advance who looks at the monitoring regularly, who decides when answers look odd and who takes an agent out of service in case of doubt. Also define which sample questions are used to check an agent’s quality. For the HR agent, that could be twenty typical questions about vacation, parental leave and sick notes, whose correct answers the HR department fixes beforehand. This is a thought example of how to make quality measurable, not a result from a project.

Once you have taken these four steps, you have done most of the work before the technology even comes into play. That is no coincidence: keeping agents under control is rarely a question of the tool, but of the agreements around it. One more point follows from the HR example of the source. When an agent gives information on HR topics, it quickly touches personal data. Involve your data protection officer and, where applicable, the works council early, before such an agent goes into operation. That too is a recommendation of ours and not a statement of the source.

The Code-Operator: how we classify the news

On amazing-agents.com we describe eight agents. One of them is the Code-Operator with the description “Bugs, fixes, pull requests with your approval.” Why do we assign a piece of news about Copilot Studio to the Code-Operator, although the entry is not about program code in the narrow sense?

The reason lies in the shape of the task. Anyone who builds, connects, tests and moves agents from development into production in Copilot Studio is doing something very similar to developing software: there are versions, test runs, approvals and fallback points. This is exactly the mindset the Code-Operator brings. It prepares changes, proposes them, and a human decides whether they are adopted. The parallel is our classification, not a product statement.

We want to separate carefully here. Copilot Studio is a Microsoft product, not a product of Amazing Agents. We do not claim that the described capabilities are part of our offering or that the Code-Operator operates them. The assignment serves to describe the task: how an agent in this area should work and where its limits run.

We also describe an approach, not a result from a client project. This is how we proceed in the audit: together with you we collect the agents and assistants that already exist or that you plan. We assign each agent a narrow assignment. We define which actions it may carry out alone, which it only proposes and which it never touches. And for each handover we determine whether a human looks in your place. The website states for all agents in general: every agent runs within a defined framework with approval steps for critical actions. This framework is what makes an agent viable for a company. It is not a brake but the precondition for being allowed to give it tasks at all.

Agent with limits and an approval step: the difference

Finally, the thought that for us is the core of this news. Delegation from agent to agent is progress, but it does not replace an approval step. On the contrary: the more work moves between agents, the more important the point becomes at which a human looks. To make the difference tangible, we place two flows side by side. They are thought experiments, not reports from projects.

Without an approval step: An agent receives a request and passes it to a second agent. That one formulates an answer, which the first returns unchecked. If the answer contains an error, such as an outdated vacation rule, employees understand it as authoritative and follow it. Who caused the error is hard to say afterward, because the chain had several links and nobody looked in between.

With an approval step: The agents also work together, but every change to an agent first goes through the test version, is checked there by a named person and only then moves to the production version. The monitoring shows which answers are actually given, and when something looks odd, someone steps in. The decision has a name, and the path is traceable. This costs time per change, but saves the time an unnoticed error costs in an answer that many people rely on.

Our recommendation, expressly marked as such: the natural place for the human approval is the transition from test to production, which lifecycle management provides anyway. Microsoft does not say in the entry that a human approval should take place there or what it should look like. But the separation of versions offers exactly the point where it can be inserted without slowing down daily work. An agent that gives answers considered authoritative does not belong in operation without this step.

An agent with limits and an approval step works in this sense not against you but for you. It has a narrow assignment, knows the rights it has and knows that certain things happen only after a human yes. It is the counter-model to the promise that a network of agents will sort everything out by itself. The capabilities that Microsoft releases today, incidentally, make this counter-model easier: fixed flows, tests, observation and separate versions are exactly the tools with which limits can be drawn. Whether you use them is decided by your company, not by the technology.

Source: Microsoft 365 Message Center, MC1518233, “Copilot Studio – Enhanced support for Copilot Chat agents,” published October 21, 2026, general availability October 26, 2026. Read via the public mirror mc.merill.net/message/MC1518233, as the Message Center itself requires an administrator sign-in.