Key insight
Every agent moves through six stages: build (created in a workshop), register (made visible in the registry), deploy (installed for chosen people), observe (instrumented so its actions are seen), govern (access limited, policy applied, lifecycle actions taken), and retire (blocked, disabled, or deleted with access removed). These stages form a loop, not a line — observation feeds governance, and governance decides what the agent may do next, or whether it should exist at all. Agent 365 makes that loop visible and controllable from one place.
We have met the pieces separately: the registry, identity, the pillars, the ecosystem, the licensing. This article threads them into one continuous story by following a single imaginary agent — call it a “travel-approvals assistant” — from the moment it is created to the moment it is retired. Seeing the whole arc makes every later, deeper article feel like a zoom-in on a stage you already understand.
1 · Why think in a lifecycle loop, not a line
It is tempting to picture an agent’s life as a straight line: make it, use it, forget it. That mental model is exactly what produces agent sprawl — agents that were deployed once and then drifted, unwatched, retaining access for years. A loop is the healthier model: every stage feeds the next, and the later stages feed back. What observation reveals shapes governance; what governance decides shapes what the agent may do; and when an agent stops earning its access, the loop carries it to retirement. Agent 365’s job is to make that loop continuous and visible, so agents never quietly fall off the edge of the line.
Build
The agent is created in one of the build tools — Agent Builder for natural language, Copilot Studio for low-code, Azure AI Foundry for pro-code, or the Microsoft 365 Agents SDK for any stack. It is given its instructions, knowledge, and tools. At this point it exists, but the organisation does not yet formally know about it — which is precisely why the next stage matters.
Register
Registering makes the agent visible and manageable in the Microsoft 365 admin center, so administrators can find it in their organisation’s inventory. Registration can use an existing Microsoft Entra application registration or an identity blueprint (a reusable definition of a class of agents). Notably, for some external platforms — Google Vertex AI and Amazon Bedrock — agents are pulled in automatically, with no code changes required. Registration is the moment a shadow agent becomes a known, governed one.
Deploy
An administrator selects the agent in the Copilot Control System and deploys it, choosing the audience: just themselves, the entire organisation, or specific users and groups. Deploying effectively installs the agent on people’s behalf by accepting the necessary Microsoft Entra permissions for them — and the admin reviews those permissions and the agent’s security and compliance details before confirming. This is the gate between “an agent exists” and “people can use it.”
Observe
Once registered, the agent is instrumented for observability — and Microsoft is explicit that developers are required to do this. Instrumentation uses OpenTelemetry (an open industry standard for emitting traces) to record every input, output, tool call, and model invocation. That telemetry flows into the Microsoft 365 admin center and feeds Entra, Purview, and Defender, so IT and security teams can actually see what the agent does. Observability is not decoration; it is the eyes of the whole control plane.
Govern
This is the continuous heart of the loop: limiting what the agent may access with role-based access control and risk-based Conditional Access, applying policy templates, and taking lifecycle actions — publish, deploy, block, delete, approve, reassign the owner, pin. Many of these can be automated with conditions-based rules, so, for example, an agent that goes unused for a period is automatically flagged or disabled. Governance is where Levels 200 and 300 of this series live.
Retire
When an agent is no longer needed — the project ended, a better agent replaced it, or it simply fell out of use — it is blocked, disabled, or deleted, and its access is removed. This is the stage most often skipped in the wild, which is how orphaned agents accumulate standing access. Doing retirement deliberately is what keeps the estate clean and closes the loop, so nothing lingers with permissions long after its purpose is gone.
7 · Glossary — every short-form term, spelled out
- Lifecycle
- The full arc of an agent’s existence — build, register, deploy, observe, govern, retire — treated as a continuous loop rather than a one-time event.
- Register (an agent)
- Making an agent visible and manageable in the Microsoft 365 admin center so it appears in the organisation’s inventory.
- Identity blueprint
- A reusable definition of a class of agents used when registering, so many agent instances inherit the same identity and policy.
- Application registration (Entra)
- An existing Microsoft Entra identity record an agent can be registered against.
- Deploy (an agent)
- Selecting an agent and making it available to chosen users or groups, which installs it on their behalf by accepting the needed permissions.
- Copilot Control System
- The part of the Microsoft 365 admin center where agent lifecycle actions are performed.
- Observability
- Recording an agent’s inputs, outputs, tool calls, and model use so its behaviour can be seen and audited; required of developers.
- OpenTelemetry (OTel)
- An open industry standard for emitting traces and telemetry, used by Agent 365 to capture agent activity.
- Lifecycle action
- An administrative action on an agent: publish, deploy, block, delete, approve, reassign owner, or pin.
- Conditions-based rule
- An automation that performs a lifecycle action when a condition is met, such as disabling an agent that has been idle.
- Conditional Access
- Policies that add checks or block access when a request looks risky; applied to agents during governance.
- Retire (an agent)
- Blocking, disabling, or deleting an agent and removing its access when it is no longer needed.
- Orphaned agent
- An agent left in place, unwatched and unretired, that keeps standing access long after its purpose has ended.
An agent moves through six stages: build, register, deploy, observe, govern, retire.
Registering an agent makes it visible and manageable in the admin center; some external agents (Vertex AI, Bedrock) register automatically.
Deploying installs the agent for chosen people by accepting Entra permissions on their behalf, after the admin reviews security and compliance.
Observability is required, not optional — OpenTelemetry captures every input, output, tool call, and model use, feeding Entra, Purview, and Defender.
Governance is ongoing: limit access, apply policy, take lifecycle actions, and automate them with conditions-based rules.
Retirement closes the loop — block, disable, or delete and remove access so no agent lingers with standing permissions.
The stages form a loop, not a line; Agent 365 makes the whole loop visible and controllable from one place.
References
- Microsoft Learn, Get started with Agent 365 development — register, observability (required), and adding capabilities incrementally; Vertex AI / Bedrock auto-registration. learn.microsoft.com
- Microsoft Learn, Assign and deploy agents for Microsoft 365 Copilot — lifecycle actions and deployment audiences. learn.microsoft.com
- Microsoft Learn, Deploy Copilot Studio agents — deploying on users’ behalf by accepting Entra permissions. learn.microsoft.com
- Microsoft Learn, Observability (monitor agents) — OpenTelemetry-based agent observability. learn.microsoft.com