Chapter 4 of 6
Decisions and stop conditions#
Select the route#
| Runtime fact | Route | Who acts | Expected live state | Stop or switch route when |
|---|---|---|---|---|
| The agent's platform is already integrated with Agent 365 | built-in | The platform operator enables or publishes the agent through that platform's current path | The agent is visible in Agent Registry through the platform integration | The platform does not document the integration, or the scenario needs code-level capabilities it does not supply |
| The runtime is one of the supported connected platforms | registry-sync | The Agent 365 administrator creates or reviews the connection in the Microsoft 365 admin center, validates its credentials, and runs the sync | The connection names the provider and shows a current sync result; the agent is visible in Agent Registry | The platform is not supported, the credential decision is unresolved, or the agent is not returned by that platform |
| The runtime owner builds and deploys the agent and needs Agent 365 identity, observability, tooling, or notifications in code | sdk | The runtime owner adds the Agent 365 SDK integration and releases it through the product's approved path | The released integration produces a live Agent Registry record | A built-in or Registry sync route already meets the need, or the runtime owner cannot release the change |
Registry sync currently supports Amazon Bedrock, Anthropic Claude Managed Agents, Databricks Genie, Google Vertex AI, Oracle Generative AI Agents, and Salesforce Agentforce. It is a preview surface, so recheck the connected-platform guidance before you start.
Stop if the team proposes a manual registry entry, an unsupported sync platform, or an SDK change with no approved release path.
Decide the connected-platform credential#
Registry sync authenticates to the external platform with a credential that platform issues. On every supported platform that credential also carries delete permissions on agent resources, so treat it as a privileged account.
Record these before anyone opens the connection dialog:
Field in onboarding-decision.json | What to record |
|---|---|
issuingOwner | The role on the external platform that creates the service identity and key |
grantedScope | The approved permission set, named as the platform names it, plus the change reference that approved it |
deleteCapabilityDecision | accepted-by-retirement-coordinator once that person has accepted the delete permissions the connection requires |
storageLocation | The managed secret store that holds the credential, named, not a file path |
rotationAndRevocationOwner | The role that rotates the credential and can revoke it on demand |
revocationPath | The concrete revoke action, for example deleting the platform API key and then deleting the connection |
Grant the smallest permission set the platform documents for this connection. Oracle's least- privilege policy option and Amazon Bedrock's list, get, and delete actions are the shape to aim for; do not fall back to a full-management role because it is fewer steps.
Stop before creating the connection if the credential has no named issuing owner, no rotation and revocation owner, no approved store outside this repository, or if the retirement coordinator has not accepted the delete permissions. Never paste a key, secret, token, or the raw permission policy into this repository.
For the built-in and sdk routes there is no platform connection. Set registrySyncPlatform and every credential field to N/A; preflight rejects a stray value.
Name the owners and the retirement path#
Four roles go in the record: the Agent 365 administrator, the runtime owner, the agent owner, and the retirement coordinator. Each must control the system they are named for.
The retirement coordinator links one cross-platform plan in planReference. That plan covers blocking user access, revoking the connection credential, removing the Agent Registry record, retiring the source runtime, and preserving the audit records the organization has to keep. Preflight checks that all five actions stay in requiredActions.
Stop if one person claims a role without control of its live system, if a role has no owner, or if the retirement plan is missing.
Handle a mismatched record#
If the expected record does not appear, check the route first: the platform publication, the connection's latest sync result, or the released SDK integration. If a record describes the wrong agent, is duplicated, or has a conflicting owner, stop. Do not overwrite the live record or create a manual replacement. The Agent 365 administrator, runtime owner, and agent owner resolve it in the source platform, then you repeat the review.