Technology · Platform

Microsoft Agent 365

I provisioned a governed digital employee under Microsoft's Agent 365, and built the MCP server through which any model acts in a meeting as that specific employee.

HelixIdentity for a digital employeeA meeting action server
Blueprintcertificate
Agent usermailbox, presence
Action servermints its tokens
  • 24tools across identity, meetings, documents and grounding
  • ≈11,000lines of Rust in the meeting action server
  • 3Microsoft principals composed into one employee

An identity that can act

Microsoft's Agent 365 lets an organisation give an AI a real identity in its tenant: an Entra Agent ID blueprint and an agent user with its own mailbox, Teams presence and licence. For Helix, making that identity do things turned out to involve three Microsoft principals, combinations the platform rejects, and preview behaviour the documentation did not cover.

I decided to probe the real tenant, keep the wire traffic, and build only on the paths that worked. I provisioned the employee with Microsoft's tooling and configured it on their platform; what I built is everything that lets it act.

What I built
Microsoft's platform
My server adds no grants beyond what the tenant gave the employee.

An installer that refuses half an identity

The tenant installer is a set of portable shell scripts over Microsoft Graph. A half-configured identity never gets provisioned.

Tenant ready
Blueprint not ready
Contract unsealed
One blueprint can produce several employees.

A meeting action server that keeps tokens from the model

The Agent 365 MCP server is Rust, with a YAML tool catalog. Every call names the acting employee, and a registry refuses names it does not know. The server signs certificate client assertions bound to that agent identity and exchanges them for the employee's own Microsoft Graph tokens: calling and roster use an application token, and actions attributed to the employee use an agent-user token.

Model: names the employee
Server
model sideserver side · tokens stay here
Tokens are cached per employee and their claims checked in process.

Calls and the meeting stage

People call the employee in Teams and it answers. It joins meetings, confirmed against the meeting roster, posts in the chat as itself, puts a deck on the meeting stage, shares a screen and calls on raised hands. Graph offers no bot API for driving slides, so presentation runs through an installed Teams meeting app and an authenticated relay bound to the exact tenant, employee and meeting, which refuses any command it cannot confirm on screen. Raising its own hand returns a typed "hand mutation unavailable", because Microsoft lets a bot observe hand state and offers no supported way to change it.

Inbound callanswered by the employee
Call mediaa transport-only client
Outbound calla calling bot, shown as one
The platform rejects one principal doing both jobs, so two are composed.

An outbound call presents as a separate calling bot, because that is how Microsoft's model works. I did not disguise it as the employee.

An identity layer that spoofs is no identity layer.

The identity work is told in Solving the digital-employee identity, and the meeting behaviour in A meeting attendee that will not fake it.