Agent 365 half baked and over sold?

Spent the last couple weeks actually trying to use Microsoft's new Entra Agent ID stuff. Blueprints, agent identities, registering into the Agent 365 registry, the whole flow. We've got Agent 365 through work so i wanted to see what a real onboarding feels like end to end. Posting in case anyone else is about to walk into this. &#x200B; There are two admin portals (admin.cloud.microsoft and entra.microsoft.com) and the agent stuff is split between them in a way that just doesn't match the docs. You spend the first hour figuring out which screen you're supposed to be on for the thing you want to do. The Entra portal owns blueprints and agent identities. The admin.cloud portal owns part of the registry view. Some flows force you out of the UI entirely. &#x200B; Licensing is its own little maze. Agent 365 covers the base. Conditional Access on agents needs Entra ID P1 or M365 E3. ID Protection needs P2 or E5 or Entra Suite. ID Governance, same. So the answer to "can I gate this agent with conditional access" depends on which SKU your tenant happens to have. None of this is summarised in one place that I could find. &#x200B; Then the actual setup. Entra admin portal lets you create a blueprint pretty cleanly: name, owner, click through. That bit's fine. Trouble starts the moment you need credentials. &#x200B; There's a recommended approach (managed identity with FIC) that requires running on an Azure compute resource, and then there's everyone else, who has to drop to the Graph API. Fine, I dropped to the Graph API. But the docs lean hard on the Microsoft.Graph PowerShell module rather than direct REST, and a bunch of the example payloads don't quite match what the endpoint actually accepts. Ended up adapting most of it to curl plus az rest becuase that was easier to debug. &#x200B; So this is the part that ate a couple of hours. The docs say to create a blueprint principal (a service principal that represents the blueprint at runtime). They give you a POST to /servicePrincipals/microsoft.graph.agentIdentityBlueprintPrincipal. So I ran it. And got back: &#x200B; Request\_MultipleObjectsWithSameKeyValue: The service principal cannot be created, updated, or restored because the service principal name <guid> is already in use. &#x200B; Turns out a different page of the docs says blueprint principals get created automatically when you instantiate the blueprint. So the explicit POST is wrong for the path I took, but the page telling you to call it doesn't say "skip this if you used the wizard." You trip a conflict error against a service principal you didn't know existed. Not destructive, but it's the kind of thing that undermines your confidence in the model. &#x200B; After credentials you need to register the agent in the Agent 365 registry so admins can govern it. Three documented paths: the Agents SDK (recommended), the Agent 365 CLI, or the Agent Registry API directly. I tried all three. &#x200B; The SDK quickstart says the SDK takes care of agent identity creation and registration in the Agent 365 registry for you, so your agent identities will appear automatically with no extra code. Ran the quickstart end to end, ran the agent locally in anonymous mode, watched it serve requests. Looked at the admin portal. Agent wasn't there. The quickstart itself doesn't actually say it'll do the registration step. Whether the SDK silently failed or just doesn't do this for the local-anonymous mode, idk. It's not clear from any of the docs I read. &#x200B; Agent 365 CLI requires .NET 8.0+, and the package setup lives in a different doc page than the CLI command reference, so you bounce between two pages to get going. I didnt feel like installing .NET on my Mac just for this so I dropped to the Agent Registry API directly. &#x200B; That worked, sort of. Built a POST against /beta/copilot/agentRegistrations with the agent card payload, fired it. Response: Forbidden, code UnknownError, empty message. Helpful. Checked the Entra admin center anyway: the agent was registered. So the API returned an error and did the thing. Either the response is lying or the error refers to a follow-up step that silently succeeded later. fwiw I'd love to know which. &#x200B; Other small papercuts. Deleting agent identities isn't supported in the admin portal at all, you have to drop to Graph API or Entra PowerShell to remove anything you created. The docs have a typo I won't bother quoting. Some links go to pages that no longer mention Agent 365 at all. &#x200B; IT wasn't any single bug. It was that every step has two or three documented ways to do it and the docs disagree about which way. When you guess wrong the error you get back doesn't tell you that's what happened. You get a conflict on a service principal you didn't ask to create, or a 403 UnknownError on a call that actually succeeded, or the SDK silently doesn't do the thing the docs claim it does. &#x200B; Just beyond frustraxted at this point, their example silently doesn't register agents the way the docs promise, this is nowhere near production level…