Two Copilot Studio changes landed on the Microsoft 365 roadmap in the first half of October 2026. Agent Readiness (roadmap 568762) moved to Launched on 1 October, with a September 2026 general availability month. Conversational configuration of connectors (569930) is Rolling out, updated 9 October, also against September 2026, across web, desktop and Mac. A related item, discover and use shared plugins (570669), is still listed as in development and is mentioned only so nobody mistakes it for shipped.
Both shipped items are maker-side. They change what a person building an agent sees and does inside Copilot Studio, not what an administrator controls from the Power Platform admin centre. That distinction is the point of this note, because Frontrow has watched Australian businesses treat a maker-side quality signal as if it were a governance control. It is not. It is a useful pre-flight check that sits inside the controls described at /insights/block-copilot-studio-agent-creation-controls and /insights/copilot-studio-bill-shock-diagnose-cap-spend.
What Agent Readiness does
Microsoft's description is compact. Agent Readiness gives makers a real-time, always-visible health check for their Copilot Studio agents. A single Review indicator in the build experience surfaces anything blocking or at risk before it derails a publish. The entry names two examples: policy restrictions and missing evaluations. Blocked capabilities are greyed out up front with a clear reason, so makers do not spend time configuring something that was never going to work in their environment.
Those two examples are different kinds of problem. A policy restriction is something an administrator decided: in a Power Platform environment it most often means a data policy that classifies a connector as blocked or business-only, so an agent using it will fail at publish. A missing evaluation is something the maker has not yet done: Copilot Studio lets a maker run test conversations against an agent, and Readiness treats the absence of that evidence as a risk. One is a wall, the other is homework. Before this feature both tended to surface at the same moment, the failed publish, usually on the afternoon the business unit expected to start using the thing.
Frontrow's practical reading: Readiness turns a late, binary failure into a continuous status. That matters most for the maker who is not a developer, which in a Copilot Studio deployment is most of them.
What conversational connector configuration does
Roadmap 569930 is described in one sentence: configure the connectors your agent needs, with a simple in-chat sign-in instead of a full settings experience. Until now a maker who wanted an agent to reach a ticketing system or a finance application had to leave the authoring flow, open connector settings, create and authenticate a connection, then return. The rolling-out change lets that sign-in happen in the chat where the agent is being built.
That is a genuine friction removal and it also lowers the bar for connecting an agent to a system of record. Lower bars are where governance questions live, and the one to ask is whose credentials the connection ends up holding. A connection authenticated by the maker in a chat is still a connection, with an owner and a credential lifecycle, and if that maker leaves or changes role the agent's access to the line-of-business system goes with them. The identity design for that is at /insights/entra-agent-id-governing-ai-agent-identities.
Why Readiness belongs before a business-unit handover
Most Copilot Studio agents in Australian mid-market businesses are built by one or two people and then handed to a team that did not build them. The handover is where quality problems become support tickets. Readiness gives a maker, and an IT lead reviewing the maker's work, a visible answer to three questions that previously required asking around: is anything in this agent blocked by policy, has it been evaluated, and is there any at-risk configuration left from an earlier iteration. An agent whose Review indicator is clean is not guaranteed to be good, but an agent whose indicator is not clean should not be handed to anyone.
The second reason is cost of change. Discovering a blocked connector after the finance team has been promised an agent means either a policy exception request or a redesign. Discovering it on day one, greyed out with the reason, means the design conversation happens before anything has been promised.
What it means for an Australian business
Licence prerequisites. Both are Copilot Studio features, so the prerequisite is whatever Copilot Studio access the organisation already holds; the roadmap entries add no licence condition of their own, and nothing here changes the consumption billing model for agent usage.
Admin controls. Neither feature is an admin control. Readiness reports on the restrictions administrators have set; it does not set them. The controls that decide who can build agents, and in which environments, are laid out in /insights/block-copilot-studio-agent-creation-controls, and the point made there still stands: the Copilot Studio Authors group is not a deny list, and the real leak is Environment Maker in the default environment. A tenant with that leak open now has makers with a nicer pre-flight check building agents nobody asked for. Fix the environment strategy first; Readiness then makes the sanctioned makers faster.
What data the agent touches. In-chat sign-in makes it faster to attach an agent to a line-of-business system. The data policy on the environment decides whether that attachment is allowed, and Readiness will grey the connector out if it is not. The safe sequence is unchanged: classify connectors in the data policy for each environment, then let makers build inside those lines. The billing matrix at /insights/copilot-agents-governance-billing-by-type explains how Copilot Studio agents are charged relative to SharePoint agents and Agent Builder, which is the other half of deciding where an agent should be built.
Where bill-shock risk sits. Readiness does not check cost. An agent can pass every policy and evaluation check and still loop against a connector, and the sequence at /insights/copilot-studio-bill-shock-diagnose-cap-spend is written for exactly that: Azure pay-as-you-go has no hard spend cap and billing data lags a day. Treat a clean Review indicator as a quality gate and keep spend alerts and caps as a separate gate that no maker-side feature replaces.
What to do this month
- 1Open every published Copilot Studio agent in the tenant and read its Review indicator. Record any showing blocked or at-risk items; those were published before the check existed.
- 2Make a clean Review indicator a written condition of handing an agent to a business unit, alongside the evaluation run it will now prompt for.
- 3Audit connections created by makers, especially any made through in-chat sign-in once it reaches the tenant. Confirm each has an owner who still holds the role, and plan the credential handover for when they do not.
- 4Re-check the data policy on each environment where agents are built. Readiness greys out blocked connectors, which is right only if the policy is right.
- 5Keep the Copilot Studio consumption alerts and caps where they are. Nothing in this release changes the spend exposure.