Agent Lifecycle: Add, Update, Retire

An agent is not a prompt you paste somewhere. It is a managed service with an identity, a version history, an endpoint, consumers, and — eventually — a retirement plan. The exam expects you to treat agents the way you'd treat any production API.

The lifecycle stages

| Stage | What you do | Key artifact | | --- | --- | --- | | Create | Define instructions, pick a model, attach tools, assign an identity | Version 1 snapshot | | Test | Run in playground, exercise tool integrations, run evals | Eval report, trace IDs | | Publish | Promote to a stable endpoint with managed access controls | Endpoint URL, registry entry | | Update | Snapshot a new version, eval-gate it, canary, promote | Version N+1 + delta eval | | Monitor | Track latency, error rate, cost, eval scores in production | Dashboards, alerts | | Retire | Announce deprecation, warn consumers, migrate, disable | Migration guide, traffic-to-zero signal |

Foundry Agent Service automates several of these: versions are snapshotted on every save, publishing creates a stable endpoint, and the Entra Agent Registry handles discovery and governance.

Add: identity is the first decision

The first thing a new agent needs is a dedicated identity. Sharing identities across agents collapses your audit log — when something goes wrong you can't tell which agent did it. A scoped Microsoft Entra identity with the minimum permissions for the agent's tools is the canonical baseline.

Update: never edit in place

In-place edits are the most common lifecycle anti-pattern. They:

1. Destroy the previous version, so rollback is impossible.
2. Make eval comparisons meaningless — you can't A/B against yourself.
3. Hide the change from the audit log.

The right pattern is immutable versions + stable endpoint. You snapshot a new version, eval it, route some fraction of traffic to it (canary), and promote it to the stable endpoint when it clears the bar. Consumers calling the stable endpoint pick up the new version without code changes.

Retire: deprecation, not deletion

Retiring an agent without a deprecation window is how you take down every dependent workflow on a Monday morning. The standard playbook:

1. Announce the retirement date and the replacement.
2. Warn on every call — log a deprecation notice consumers can grep.
3. Document the migration path with code samples.
4. Monitor traffic until it reaches zero (or the date arrives).
5. Disable the endpoint; archive the version history.

Exam tip: Lifecycle questions often pit the "fast" answer (edit in place, delete immediately) against the "safe" answer (new version + canary, deprecate + migrate). The safe answer is the right answer essentially every time on GH-600.

Quick check

Where this shows up on the exam

GH-600 frames lifecycle in terms of operational discipline: versioning, evals between versions, canary deploys, deprecation windows, and per-agent identity. If a scenario describes a change that would silently affect production traffic, the correct answer almost always introduces an explicit version, eval, or rollout gate.