Exploring agent development

I’ve been using AI to build software for a while now, including Keepit’s MCP server, a PowerShell module for managing Keepit, Flightmap, M365Mutator, and a variety of other goodies. Recently I’ve started digging into actually developing agents, and this has been an adventurous experience given my lack of experience with most of Microsoft’s developer-platform tools. I thought it would be useful for me to document some of what I’ve learned along the way.

One of the first things I had to get straight is understanding how agents are identified and get access. Within Microsoft’s Agent 365 and Entra Agent ID model, there are three basic access patterns. They differ in whose identity the agent uses and how persistent that identity is.

Delegated agents

A delegated agent acts as you, using your delegated permissions, so it can only reach what you can reach. Its access is ephemeral and tied to the request. If you ask Copilot or Claude to organize your inbox, you’re using a delegated agent; the agent does its work using your identity, governed by whatever policy is attached to your user account. The agent can never do more than your user account can. In the real world, a travel agent is a good example of a delegated agent: she can’t spend more than my credit card limit, and in general can’t do things that exceed my own limits (like sending me to a country where I don’t have a visa).

Autonomous agents

These agents are the type people most often think about. They use their own agent identity, with scoped application permissions, and no user in the loop (although they may be built to require or allow human approval for some actions). For example, a background agent that generates reports on a schedule, or automatically triages support tickets, would fall into this category. For autonomous agents, the policy attaches to the agent identity (or its blueprint, something I’ll talk more about in a future post). Microsoft describes these as “agents operating behind the scenes.” To stay on my travel theme, the rebooking agents that United and Delta operate work this way: they have a policy that controls what the agent may do when there’s a flight disruption, and the agent will make changes to my flights within the bounds of that policy when there’s a delay, cancellation, etc. I may be able to review and approve the change, but I don’t have to trigger it, and the agent’s scope of actions have nothing to do with me as an individual flyer.

AI teammate agents

An AI teammate is an agent with its own Entra user account, which gives it a mailbox, calendar and Teams presence. It takes part in team workflows the way a colleague would, for example in Teams chats. The Planner agent in Microsoft Planner is a good example; I can @-mention it, assign tasks to it which it will try to perform, and so on, exactly as I might work with a real human. Microsoft’s docs say an AI teammate always uses the Agentic-User authentication. Its access is persistent and accumulative, and policy attaches to the agent’s user account. Microsoft’s partner agents from Zendesk, Genspark, Manus and others are deployed this way.

The short version

A delegated agent borrows your identity, an autonomous agent has its own application identity, and an AI teammate has its own user identity. Agent 365 governs all three from one control plane, but the access model, and so the risk profile, is different for each. In addition, you may build, deploy, manage, and monitor these agent types in very different ways, something I’ll have plenty to more to say about in the future.