Microsoft's agent taxonomy decides more than architecture

In December 2025 Microsoft added a dedicated AI agent adoption framework to the Cloud Adoption Framework. It defines what an agent is, walks through plan, govern, build and manage phases, and sorts agents into three categories by how much autonomy they carry. The guidance is good. It is also written for a global audience, so it never mentions the regulation that decides how much governance each category carries in the EU.

That mapping is worth doing, because the high-risk obligations of the EU AI Act apply from 2 December 2027, a date the June 2026 omnibus amendment has moved back once already. If your organisation is piloting agents now, the systems you classify this quarter are the systems you must have documented by then. Getting that classification right is the first step of any AI engagement on Azure we take on.

The three agent types

Microsoft's taxonomy runs along a spectrum of autonomy:

• Productivity agents retrieve and synthesise information. A user asks, the agent searches grounded sources and answers, the user decides what to do with it.
• Action agents perform defined tasks inside set workflows: update a record, create a service ticket, trigger a process.
• Automation agents manage multi-step processes with minimal oversight. They decide when to run, when to stop and when to escalate.

Microsoft's own framing notes that the third category "requires rigorous governance" without saying what that governance must satisfy. In the EU, a large part of the answer has a citation.

What the AI Act actually classifies

The EU AI Act does not classify technology. It classifies intended purpose. Annex III lists the areas where a system counts as high-risk: employment and worker management, access to essential services, credit scoring, education, law enforcement and several others. Whether the system behind that purpose is a chat interface, a workflow or an agent is irrelevant to the classification.

This is why two agents built on the same platform can live in different legal universes. A retrieval agent that answers questions about your HR policies is, in most configurations, not high-risk. An automation agent that screens applicants and shortlists candidates sits squarely in Annex III. Same Foundry tenant, same model family, a different set of obligations covering risk management, data governance, logging, documentation and human oversight.

Where the taxonomy becomes a governance proxy

Autonomy is not a classification criterion in the regulation. It correlates with the obligations all the same, in three ways.

First, probability. The further right you move on Microsoft's spectrum, the more the agent acts on people and processes rather than retrieving information for them, and acting on people is what Annex III is largely about. Automation agents end up in high-risk territory more often because of what they are built to do.

Second, Article 14. Human oversight for a retrieval agent is close to inherent: a person reads the answer and makes the decision. For an automation agent, oversight has to be designed, staffed and evidenced. Someone must be able to interpret what the agent did, intervene, and stop it. If your agent runs a multi-step process overnight, "a human reviews the output" is a claim you need to be able to defend, not a sentence in a slide.

Third, logging. Article 12 requires high-risk systems to log automatically across their lifetime, and Article 19 sets six months as the retention floor. A single-turn retrieval agent produces a tidy log by accident. A multi-agent orchestration that calls tools, spawns sub-tasks and revises its own plan produces a trace you must deliberately architect to capture, or you will not be able to reconstruct what happened.

The provider question

One more place where agent platforms and the regulation intersect uncomfortably. The obligations for deployers (Article 26) are manageable. The obligations for providers (Article 16 and onward) are a different order of work. Article 25 sets out when a deployer becomes a provider: putting your name on a high-risk system, substantially modifying one, or modifying a system so that it becomes high-risk.

Agent platforms make all three easy to do by configuration. An agent built in Copilot Studio or Foundry with your instructions, your tools and your branding is not obviously "a Microsoft system you deploy". Whether your build crosses the Article 25 line is a per-case assessment, and it is far cheaper to make that assessment before the agent exists than after.

What to do this quarter

Inventory the agents that already exist, including the ones individual teams built in Copilot Studio without telling anyone. Classify each against Annex III by intended purpose, at design time, not at legal review. Then use Microsoft's taxonomy as your triage: retrieval agents get a lightweight check, action and automation agents get the full Article 9, 12 and 14 treatment before they touch production. The taxonomy was published as an adoption aid. Read alongside Annex III, it is a perfectly serviceable risk-triage tool. Where that triage turns up an automation agent you still need to build, an AI Discovery Sprint ranks the candidates by feasibility and EU AI Act risk before any of them reaches production.