Microsoft Work IQ to Invoke Custom Agents and Third-Party Tools: October 2026 Preview

That is the whole description. The dates are the more useful part: a preview is targeted for October 2026 and general availability for November 2026, on the web, in the Worldwide (Standard Multi-Tenant) cloud. The item is marked In development. Microsoft's roadmap page says all of its information is subject to change, so read October and November as targets, not promises.

What the roadmap entry says​

Here are the facts Microsoft has listed:

The important verb is invoke. Until now, public descriptions of Work IQ have mostly covered things flowing in: agents calling Work IQ for grounded workplace context. This entry points the other way, with Work IQ calling out to custom agents and to agents that use outside tools.

Section summary: The change is narrow but directional. Microsoft is targeting a web preview in October and GA in November, and the wording says Work IQ will call agents, not just be called by them.

What the entry leaves out​

The listing does not answer the questions admins and developers will ask first:

• Which custom agents qualify? Copilot Studio, Microsoft Foundry, Agent Builder, and fully external frameworks are all possible. The roadmap names none of them.
• What does "supported" mean for third-party tools? The word suggests an approved list, not any tool you like, but Microsoft hasn't published one.
• Whose authority do the calls run under? The entry says nothing about identity, consent, or approval steps.
• Which admin controls apply? Nothing specific to this feature is listed.
• Is there a separate charge? The roadmap doesn't mention pricing.
• Is it web-only for good, or is web just the first platform listed?

Until Microsoft publishes implementation documentation, treat these as open questions.

Where this fits in Work IQ's history​

Some background shows why this matters. Microsoft's developer documentation describes the building blocks. Third party agents can consume Work IQ through different protocols, depending on their actual needs: A2A: for agent-to-agent patterns. MCP: for agent-to-tool patterns. REST: for human/device-to-agent patterns.

Microsoft's product page puts it more simply: connect via A2A, MCP, or REST to use grounded, permission‑aware workplace intelligence in your custom agents, SaaS apps, and multi‑agent systems.

On the tools side, the Work IQ MCP collapses hundreds of operations into just 10 generic tools that provide direct access to Microsoft 365 data (mail, calendar, files, people, chat, and sites) and the ability to act on that data. These tools function as simple verbs (such as fetch, create, and update), while resource paths define what the agent is working with.

All of that describes Work IQ as a supplier of context. Roadmap 570853 suggests it will also start sending work out. If A2A has been the way outside agents reach into Work IQ, the obvious reading is that Work IQ will increasingly reach back out to them. Microsoft hasn't confirmed which protocol or mechanism the new feature uses, though, so that reading is my inference, not a documented fact.

A related announcement arrived just days earlier. Microsoft's Dynamics 365 blog post on business applications in Work IQ, published September 25, said that in any custom agent or third-party agent building platform, you can create teams of agents that oversee end-to-end processes and recommend process improvement. That post covers a different capability, business-app grounding through Dataverse and Dynamics 365, and it has its own schedule. It shouldn't be confused with this roadmap entry. Both do point the same way, toward Work IQ as a hub that coordinates agents rather than a lookup service.

Section summary: This is the next step in a clear direction. Work IQ started as a grounding layer that agents query, and Microsoft is now adding the ability for Work IQ to call agents itself.

Governance: what exists today​

The roadmap entry doesn't say which controls will cover custom-agent invocation or third-party tool calls. Microsoft has documented how Work IQ's current agent tooling is governed, and that gives admins a sensible starting point for their questions.

Microsoft Learn's Work IQ MCP overview, for Agent 365, says Microsoft-built and custom MCP servers both use the tooling gateway for governance, policy enforcement, and observability, so every tool call is secure and compliant. The same documentation says Agent 365 gives IT administrators centralized control to manage which Work IQ MCP servers and other MCP servers are available to agents. Admins can manage MCP servers directly in the Microsoft 365 admin center under the Agents and Tools section.

Microsoft's developer materials also say Work IQ offers permission inheritance - Respects existing user permissions, Security Group assignments, and sensitivity labels. Data Loss Prevention - Honors DLP policies across all Work IQ operations.

Microsoft's own internal IT team has flagged a catch. Work IQ doesn't create new access. It makes the access you already have far easier to act on. In its Inside Track write-up, Microsoft Digital describes a case where a sensitive document showed up in a Copilot query. The cause was a missing sensitivity label, not Work IQ. Once Work IQ can call third-party tools, that kind of oversharing matters more, because the data is no longer just summarized inside Microsoft 365. It could be passed to a tool outside it.

Nothing Microsoft has published confirms that this feature will go through the Agent 365 tooling gateway or the Agents and Tools controls. It's a reasonable guess, not a fact.

Cost: check before you pilot​

Pricing is the question most likely to catch someone out. Microsoft's Work IQ GA licensing guidance says that Work IQ API consumption consists of two parts: variable charge for query-style consumption (grounding, retrieval, and reasoning) and a static usage component for actions and tools invoked through Work IQ. Microsoft's developer blog adds that for Copilot-licensed users, Work IQ is billed consumptively for custom and third-party agents.

The roadmap item doesn't say whether invoking custom agents or third-party tools will use those meters, a new one, or none. Given how Work IQ billing already treats tool invocations, finance teams should ask before anyone starts a pilot that fans out into dozens of agent calls.

What admins and developers can do now​

The work to do before October is mostly readiness:

1. Watch roadmap ID 570853 and Message Center for the preview announcement and the official documentation that should come with it.
2. List the MCP servers already enabled in the Microsoft 365 admin center under Agents and Tools. That's your current agent tooling footprint, and the most likely place new controls would appear.
3. Audit sensitivity labels and oversharing in SharePoint and OneDrive. Microsoft's own deployment lessons show AI surfaces whatever permissions already allow.
4. Get your custom agents ready. Teams building in Copilot Studio or Foundry should document what each agent does, which tools it calls, and whose identity it runs under, before Work IQ can start invoking them.
5. Set up cost monitoring for Work IQ consumption so that any charges from agent invocation don't come as a surprise.
6. Plan a small preview pilot in a test tenant or with a limited group. It's a preview for a reason.

Analysis: a small entry with big implications​

On paper this is a single sentence on a roadmap. It still marks a real change in how Microsoft 365 Copilot is designed.

The optimistic view: businesses already run many agents across Copilot Studio, Foundry, and third-party platforms, and letting Work IQ call them directly means users don't have to jump between tools or work out which agent handles which task. Copilot becomes a single front door to the whole agent ecosystem.

The skeptical view is just as fair. Each hop from Work IQ to a custom agent to a third-party tool is another place for permissions to widen, data to leave the tenant, and costs to add up. "Supported third-party tools" is carefully vague. Until Microsoft publishes the list, the approval process, and the audit trail, that vagueness belongs on the risk register, not on anyone's list of launch-day wins.

There's also the schedule. A one-month gap between preview and GA is short for a feature that routes Microsoft 365 context to external tools, so don't be surprised if the dates slip.

For now, the practical position is simple: interested but not yet trusting. When the preview arrives, the documentation should matter more than the demo.