LearnMicrosoft 365 Copilot › 5 · Agents

Deploying agents: store, approvals, targeting

Between 'a maker built it' and 'the company uses it' sits the deployment pipeline: submission, admin approval, and population targeting — the same machinery as Teams apps, now carrying AI.

The pipeline

  1. Submission: the agent (from Studio or dev tooling) is published toward the org — landing in the admin's approval queue rather than users' hands. Shared agents inside a team/channel scope exist too (lighter path, smaller blast radius) — know which path each agent took.
  2. Approval: the admin gate in the M365 admin center's agent management (integrated apps/agent pages). This is where the review checklist actually executes: manifest read (knowledge scope, actions, publisher), taxonomy classification, Studio-side checks done (previous concepts). Approve = it becomes DEPLOYABLE, not deployed.
  3. Targeting: availability to everyone / specific groups / opt-in — the same population mechanics as Teams app policies (that curriculum's three-layer model applies; agents ARE apps in the deployment plane). Stage it: pilot group -> department -> org, watching usage and cost per ring.

The governance properties this pipeline buys

  • A choke point: nothing org-wide without a named approver on record (audit-logged) — the difference between an agent ESTATE and agent SPRAWL is mostly this queue being real.
  • An inventory for free: the approved list + targeting is the deployment half of the census (Agent-ID registry being the identity half — governance concept; the two must reconcile).
  • Rollback: block/remove from the same surface — pair with the agent kill paths (previous concept) for the full stop story.

The two leaks to guard

Side-door sharing: team-scoped agents and maker-shared links bypass org review by design (small-blast-radius feature) — fine UNTIL a team-scoped agent holds broad knowledge scopes; the review trigger should be scope, not just audience. Marketplace drift: third-party agents from the commercial catalog ride the store pipeline — treat publisher trust like any ISV app decision, and re-review on UPDATE, not only on first approval (manifests change).

What to watch (proofs)

  • The queue's reality: pending/approved/blocked counts and approval latency — a queue nobody works is the wild west with paperwork.
  • Targeting census: which agents reach which populations (exportable) — joined with per-agent cost (Studio concept) and usage, this is the quarterly agent-portfolio review, on one page.
  • Side-door audit: team-scoped/shared agents with sensitive knowledge scopes — the query that finds governance bypass before it finds you.
  • Update diffs: manifest changes on already-approved agents — the re-review trigger, alertable from audit events.

Discussion

No messages yet — start the thread.

Sign in with your email to join the discussion — we send a one-time link, no password.