AI agent registry by cloud and by framework: what each one sees and how to set it up

Section 01Summary: what a registry must answer, and what we found

Use each vendor's agent registry for the agents it finds on its own, and keep one register above them for everything else, with a named person who reconciles it. For every agent that register has to answer six questions. Where does the agent run? Who owns it? Which identity does it act as? Which tools and data can it reach? Is it approved and still in use? How is it stopped, and by whom? A list that answers only the first question is an inventory of deployments, and most vendor registries start there.

The main finding is about coverage. As of 10 November 2026, Microsoft, AWS and Google Cloud each have a generally available registry, and each fills itself from the vendor's own runtime. An agent that runs anywhere else appears only after a person registers it, points the registry at its URL, or runs a connector. Microsoft goes furthest across vendors, with a connector that reads agents from seven other platforms, and its own page says an admin has to start each sync by hand.

Each vendor registry sees its own agents automatically and other agents only by manual registration or sync. A company with agents in more than one place needs one register above the vendor registries, with a named person who reconciles it.

Automatic registration follows the runtime, so the choice of framework changes little about whether an agent is listed. The framework changes the credential the agent runs with by default and the metadata it emits, which decide how useful the record is. Governance fields usually have to be added separately. AWS and Google Cloud have no native field for the owner, the risk tier, the data an agent reaches or the model behind it. Those answers have to be added as tags or custom metadata, or kept in a company register. The section on the minimum register gives the columns.

Section 02Microsoft: Entra Agent ID, Agent 365, Foundry, Copilot Studio and Purview

Microsoft spreads the registry job across several products. Agent 365 holds the list. Microsoft Entra Agent ID gives each agent an identity. Foundry Control Plane lists what runs in Azure. Copilot Studio has its own inventory for makers, Purview shows the data risk, and Defender finds agents on laptops. The table gives the status of each on 10 November 2026.

What an entry records. The registry export holds Name, Status, Channel, Date created, Last modified, Publisher, Publisher type, Version, Owner, Description, Platform and Instructions, and Microsoft says it covers "over 30 different items for each agent". A Risks column combines signals from Purview, Entra and Defender. Purview adds the agent user ID and the parent agent an instance belongs to. For agents synced from Amazon Bedrock, optional permissions let Agent 365 read a Classic agent's action groups and knowledge bases and an AgentCore agent's gateway targets.

How an agent gets in. Agents from Agent Builder, Copilot Studio, Foundry, Copilot Cowork, Researcher and SharePoint arrive through built-in integration. An admin can upload an agent's manifest package as a .zip file under Agents, All agents, Add agent. Developers can use the Agent 365 SDK, which Microsoft says works for agents built with the Microsoft 365 Agents SDK, Microsoft Agent Framework, OpenAI Agents SDK, LangChain, CrewAI or LlamaIndex. Agents on other platforms come in through Connected platforms. The page dated 5 November 2026 lists seven: Amazon Bedrock (Agents Classic and AgentCore), Google Vertex AI, Salesforce Agentforce, Databricks Genie, Anthropic Claude Managed Agents, Oracle Generative AI Agents and Snowflake Cortex. Agents on laptops come in through Defender.

What it cannot see. The limits below come from Microsoft's own pages, and they decide how much checking the admin still has to do by hand.

• Connected platforms syncs only when an admin starts it. Microsoft's page says "Agent 365 doesn't currently sync on a schedule" and "Deletion reconciliation isn't guaranteed".
• Every supported platform needs a key-based credential. Keyless options such as workload identity federation or role assumption are not supported, and the sync fails if the source platform blocks public network access.
• The Bedrock connector reads Classic agents and AgentCore runtimes and harnesses. Microsoft's guide does not cover agents on plain EC2, ECS, EKS or Lambda. The connector reads AgentCore directly and does not read AWS Agent Registry.
• Microsoft warns that "Publishing the agent in Copilot Studio alone might not make it visible in the admin center", and one agent can appear twice, once as shared by its creator and once as published by the organization.
• Draft agents are visible only for Copilot Studio. Metrics for third-party agents start only when the organization activates Agent 365 licences.
• Purview DSPM does not alert an admin when a new agent appears. Defender says that installing an agent does not by itself guarantee an inventory entry, and only the combinations in its support matrix are covered.
• Foundry Control Plane does not support Classic agents or Azure OpenAI assistants, and Logic Apps agent loops have no traces.

Foundry needs a closer look, because the guidance changed. Until recently an admin could register an agent hosted outside Foundry as a custom agent. Microsoft's page now reads: "Microsoft Foundry Control Plane deprecates custom agents on May 7, 2027. You can no longer add new custom agents." The replacement is external agents, in preview. Foundry stores only the registration metadata for an external agent and matches incoming traces to it by an identifier the agent writes into its OpenTelemetry data. OpenTelemetry is the open standard most agent tools use to send traces. Foundry does not host, proxy or invoke an external agent, so it can show traces and run evaluations but cannot stop the agent's traffic. Existing custom agents have to move before that date. A naming change is also due: according to Message Center post MC1484008, read on a third-party mirror, Copilot users will select Plugins instead of Agents by late November 2026, while the admin registry keeps the word Agents.

Licence and unit of charge. Viewing the inventory needs no specific licence. Agent 365 is licensed per user, standalone or inside Microsoft 365 E7. Risk signals in the registry need an E7 or Agent 365 licence. Microsoft states that Agent 365 licences are required for data collection only for third-party agents. Message Center post MC1506727 (October 2026, read on a mirror) says usage insights for Microsoft-built agents become available without an Agent 365 licence by late November 2026. Observability for synced platforms can add query or storage charges at the source provider.

• Step 1: Confirm roles. Governance actions need the AI Administrator or Global Administrator role. AI Reader gives read-only access.
• Step 2: Open the Microsoft 365 admin center, then Agents, All agents, Registry. Note four numbers: Total agents, Agents without owners, Unmanaged agents and Agents at risk.
• Step 3: Export the registry to CSV as the first baseline, and set the columns under Customize view.
• Step 4: Check Copilot Studio coverage. Compare the registry with the Copilot Studio agent inventory, which Microsoft says can be read from the admin center, an API or Azure Resource Graph, and confirm that new agents carry an Entra Agent ID.
• Step 5: In Azure, open Foundry Control Plane (Operate, Assets, Agents) for each subscription. Register agents hosted outside Foundry as external agents. During the preview, create and update calls need the header Foundry-Features: ExternalAgents=V1Preview, and traces appear only when the agent's telemetry sets gen_ai.agent.id to the ID entered at registration. Plan the move of existing custom agents before 7 May 2027.
• Step 6: Connect other platforms: Agents, All agents, Connected platforms, Manage, Connect a platform. Enter the provider credential, choose Validate, Save, then Sync agents. Ask the platform's admin for a least-privilege key with list and read permissions only, and no delete permissions. For AWS, Microsoft's examples include bedrock:ListAgents, bedrock-agentcore:ListAgentRuntimes and ec2:DescribeRegions.
• Step 7: Put a recurring task in the calendar to run Sync agents again, since nothing runs it for you, and allow the Agent 365 outbound IP addresses if the source restricts network access.
• Step 8: Onboard devices to Defender for Endpoint to find local agents and MCP servers, and query the AgentsInfo table.
• Step 9: In Purview, use the current DSPM and its AI observability view, which needs the Compliance Administrator role. Record each agent user ID for DLP and insider risk policies, and schedule a weekly review because there is no new-agent alert.
• Step 10: Set the agent management rules: reassign ownerless agents, block unused agents and reject stale publish requests.

Section 03AWS: Amazon Bedrock AgentCore and AWS Agent Registry

What exists and its status. AWS Agent Registry entered preview on 9 April 2026 and became generally available on 31 August 2026. In October 2026 AWS added US East (Ohio), Europe (Frankfurt), Europe (London) and Canada (Central), which brings it to nine commercial Regions. On 6 November 2026 AWS announced general availability in AWS GovCloud (US-West). When we checked on 10 November, the developer guide's release notes had not yet listed that Region. The preview version of the registry, under the older bedrock-agentcore namespace, shut down on 30 October 2026, and AWS says customers lose access to any data left there. AgentCore Identity, which gives agents a workload identity, has been generally available since 13 October 2025. AWS Marketplace sells agents and tools, and we found no statement that a purchase creates a registry record, so register purchased agents yourself.

What an entry records. Each record has a name, display name, description, record version, record type and tags, plus one descriptor that describes the thing itself. The record types are AGENT, MCP, SKILL and CUSTOM, with GATEWAY for records detected from a gateway. A record moves through the states DRAFT, PENDING_APPROVAL, APPROVED, REJECTED and DEPRECATED, and only approved revisions can be discovered. Records that AWS detects automatically also carry where they came from: the resource ARN, the runtime version, the invocation URL and the workload identity ARN. Owner, business purpose, data classes, risk tier and model are not native fields. AWS supports a custom metadata schema and tags for those.

One gap matters for teams that use the A2A protocol, the open standard by which one agent describes itself to another in a small file called an agent card. AWS lists schema version 0.3 as the only version it validates for agent cards, while A2A 1.0.0 was released on 12 March 2026. The same AWS page also says the registry supports all versions of the A2A schema. We have not tested whether a 1.0 card is rejected, so check this with a real card before relying on it.

How an agent gets in. With an organization-scoped registry and auto-detection enabled, AWS catalogs the AgentCore Runtimes and Gateways in every member account and keeps the records in step when resources are created, changed or deleted and when accounts join or leave. Every detected runtime is typed as AGENT, because detection cannot tell a standalone MCP server from an agent, and an admin can change the type to MCP. A second route, Synchronize from endpoint, pulls the metadata of an MCP server or an A2A agent from its URL. The third route is manual entry through the console, the CLI or the SDK.

What it cannot see. Auto-detection covers AgentCore Runtimes and Gateways only. Bedrock Agents Classic, agents on Lambda, ECS, EKS or EC2, agents inside SaaS products, agents in other clouds and agents on desktops stay out unless someone registers them. An organization can have one active organization-scoped registry per Region, so a company in several Regions runs several registries. Detected records get a machine name built from the account, Region and resource ID in place of the runtime's display name, so a person has to add a readable name and an owner.

Unit of charge. The registry is billed by consumption with a monthly free tier: per 1,000 net records held, per 1,000 Search API calls and per 1,000 List or Get calls. AWS says resellers are not eligible for the free tier.

• Step 1: From the AWS Organizations management account, enable trusted access for Agent Registry auto-detection and register a delegated administrator account, which AWS recommends as the owner of the registry. AWS's page on Agent Registry with AWS Organizations, in the sources, gives the commands and the permissions.
• Step 2: In the delegated administrator account, create one organization-scoped registry in each Region you use where Agent Registry is available. Choose IAM or JWT authorization and the approval settings. A customer managed KMS key can only be chosen at creation.
• Step 3: Enable auto-detection by setting the registry's auto-detection configuration to enabled. Existing and new Runtimes and Gateways appear as records, and AWS says the first discovery can take up to 20 minutes.
• Step 4: Enrich the detected records with a display name, a description, owner tags and the right record type. Define a custom metadata schema for owner, risk tier and data classes.
• Step 5: Set the approval workflow. Subscribe to the registry's EventBridge events for new submissions, and log registry activity with CloudTrail.
• Step 6: Share the registry with other accounts through AWS Resource Access Manager, using the ReadOnly, Consumer, Publisher or Admin permission, and expose the registry's MCP endpoint through PrivateLink if agents need private access.
• Step 7: Register by hand, or by endpoint sync, the agents that auto-detection misses: Bedrock Agents Classic and anything on Lambda, ECS, EKS or EC2.
• Step 8: If you used the preview, confirm that nothing still calls the registry APIs under the old bedrock-agentcore namespace and that IAM policies use the agent-registry actions.

Section 04Google Cloud: Agent Registry in Gemini Enterprise Agent Platform

What exists and its status. Agent Registry, part of Gemini Enterprise Agent Platform, has been generally available since 18 June 2026 with a v1 API and support for A2A 1.0 alongside the 0.3 schema. Google's release note for that date carries two caveats: Access Transparency and Access Approval are not available for Agent Registry configurations, and the detective controls for data residency are limited. We found no change to the registry's status in Google's release notes through 10 November 2026.

Agent Identity is less settled. The release note of 18 June 2026 says the Agent Identity API is available in preview. Google's platform launch entry describes Agent Identity as generally available. We could not reconcile the two, so confirm the status with Google before building a control on it.

What an entry records. The registry holds agents, MCP servers and their tools, endpoints for external REST APIs, and skills. The console shows each entry's name, identifier, description, runtime and location. For an agent that speaks A2A, the registry reads the agent card at the standard address /.well-known/agent-card.json and indexes the skills and capabilities it advertises. For an agent that does not, Google says the registry "can't automatically capture metadata such as the endpoint URL where the agent is hosted, the agent identity, and A2A skills". Owner, risk tier, data classes and model are not native fields.

How an agent gets in. Agents deployed to Agent Runtime are registered automatically, and updates and deletions follow. Built-in Google Workspace and Gemini Enterprise agents are registered automatically as well. Workloads on GKE and Cloud Run can opt in. On Cloud Run that takes the flag --functional-type=agent together with --identity-type=agent-identity, and on GKE it takes the label registry.gke.io/functional-type set to AGENT, the annotation a2a-protocol.org/agent-card and the pod annotation iam.gke.io/spiffe-identity-type set to agent-identity. Agents hosted outside Google Cloud or on unsupported runtimes are registered by hand. Google's guide for custom ADK agents on your own infrastructure requires the agent to expose an A2A agent card and be registered by its endpoint.

What it cannot see. Agents in other clouds or SaaS products are missing unless someone registers them. So are desktop agents, and workloads in projects outside the management boundary. A management boundary is a setting on a folder or organization that gathers supported agents from member projects into one management project. Without it, components in other projects have to be registered one by one.

Unit of charge. Google's pricing page says registration, storage, discovery and API operations carry no charge. The one billed item is optional skill vulnerability scanning, charged per million input tokens. It is free through 31 December 2026 and billed from 1 January 2027.

• Step 1: Choose a governance project for a single-project setup. For several projects, configure a management boundary on a folder or the organization with a management project, and enable the Resource Manager API.
• Step 2: Grant the roles: Service Usage Admin to enable the API, Project IAM Admin, and Agent Registry API Admin. Developers who register custom agents need Agent Registry API Editor.
• Step 3: Enable the Agent Registry API in the governance project.
• Step 4: Deploy agents to Agent Runtime, where registration is automatic, or set the GKE label and annotations or the Cloud Run flags named above. Register external agents, MCP servers and endpoints by hand as Service resources.
• Step 5: Verify the result in the console under Agent Registry, on the Agents tab.
• Step 6: Optional, and each is a separate setup task in Google's documentation: attach Agent Gateway, add IAM access policies and add Model Armor inspection. For Gemini Enterprise apps, Google's note of 28 October 2026 says to use a single regional registry in the same project and region as the gateway.

Section 05Salesforce, ServiceNow and the neutral options

Agents also live inside business applications, and several vendors now sell a registry that sits across clouds. We cover these more briefly, because public documentation is thinner and several status dates conflict. The table shows what we could confirm.

Salesforce. Agentforce Observability monitors Agentforce agents. The pages we opened describe no inventory record, and data appears only for conversations that happen after Session Tracing is set up. For a list across vendors, Salesforce points to MuleSoft Agent Fabric. Its scanners import agents from Amazon, Anthropic, Databricks, GoDaddy, Google, Kong, LangChain, Microsoft, Agentforce, ServiceNow and Snowflake platforms on a schedule that runs at most once a day. A later scan overwrites metadata edited in the registry with the values from the source, and can restore entries that were deleted there. The ServiceNow scanner imports only agents built natively in ServiceNow. To stand it up, an admin confirms Agent Fabric access for the business group, holds the Exchange Administrator role, connects each provider with its credentials, and creates a scanner in Exchange with a name, a schedule, a review option and a tested connection. Some sources need preparation first. The ServiceNow scanner returns no agents unless AI Asset Governance is enabled and synced in ServiceNow, and it needs an integration user with read access to the AI asset tables and an OAuth client.

ServiceNow. AI Control Tower inventories AI systems, models, prompts, datasets and MCP servers. Connectors query the outside platforms. The release notes list connectors for Microsoft (including Agent 365), AWS, Google Cloud, Anthropic, Databricks, GitHub, Salesforce and OpenAI, among others. Discovered assets arrive as unmanaged, and an admin or an automation rule promotes them to managed. The November 2026 release adds a policy-driven kill switch for agents. ServiceNow's release notes also say ServiceNow-managed agents can be published to Microsoft Agent 365. To stand it up, an admin requests AI Control Tower from the ServiceNow Store, confirms the plugins com.sn_ai_disc and sn_sgc_central are installed, creates an AI connection for each connector, checks that the daily discovery job is active, and sets the rules that promote assets. Connector prerequisites are in ServiceNow knowledge article KB2986990, which sits behind a login and which we could not check.

The neutral options are building blocks for a registry. The official MCP Registry lists public MCP servers, and its own documentation warns that breaking changes or data resets may occur before general availability. It does not hold private servers, so a company that wants an approved list of MCP servers runs or buys a private registry that follows the same API. The A2A specification defines the agent card and states that it "does not prescribe a standard API for curated registries". A card describes the agent's interfaces and skills. It has no field for an owner, for data access or for risk. A card is still useful, because AWS and Google Cloud can read one from a URL they can reach with a supported authentication method. Test the schema version first, given the open question about A2A 1.0 on AWS.

Okta for AI Agents registers agents as identities in its directory, and Okta's own dates for general availability conflict. Workday's Agent System of Record is included in the core subscription and covers only agents that act on Workday. Four more vendors market agent registries or discovery, and each has a gap in the evidence. SailPoint Agentic Fabric has documented setup steps, but its list of supported agent frameworks comes from a community post. IBM's announcements disagree on whether discovery in watsonx Orchestrate is generally available or in tech preview. We found no public admin documentation for Palo Alto Networks Idira. Credo AI's registry is in public preview with no published integration list. We leave these four out of the recommendations.

Section 06What changes with the framework you build with

A framework is the code library a developer uses to build an agent. We checked eight: Strands Agents, LangGraph, Microsoft Agent Framework, OpenAI Agents SDK, Google's Agent Development Kit (ADK), CrewAI, LlamaIndex and Claude Agent SDK. In each cloud the registry record is created from the runtime resource the agent is deployed to. Any framework deployed to that runtime gets the same automatic record. An agent hosted elsewhere needs a supported connector or an explicit registration step. The framework decides two other things: the credential the agent uses when nobody configures an identity, and the metadata it emits about itself.

None of the eight frameworks provisions a dedicated identity for an agent. The agent runs with whatever credential is in its environment, usually a model provider's API key or the cloud role of the machine. The managed runtimes can provision an identity automatically, and self-hosted agents need an explicit step, such as creating a workload identity in AgentCore Identity or an agent blueprint with the Agent 365 CLI. AgentCore Runtime creates a workload identity for each agent at deployment. A Foundry hosted agent gets its own Entra agent identity at deployment. Google's Agent Runtime uses a service account unless the team opts in to Agent Identity.

The next table is the framework by cloud matrix. Native (runtime) means that deploying to the cloud's standard agent runtime creates the registry record with no registration step for the individual agent, whatever the framework. Native (framework) means automatic runtime registration, with the framework also adding metadata the registry uses. With work means manual registration, an SDK integration, a custom container or a manual sync. Unknown means we found no source. We found no combination that a vendor documents as unsupported, so that label does not appear.

The AWS column says native for seven of the eight because AgentCore Runtime accepts any framework and AWS publishes samples for those seven. A detected record still has to be approved before others can discover it, unless auto-approval is on. The ServiceNow column is unknown throughout because no source ties its connectors to a framework.

Some framework vendors keep a catalog of their own. LangSmith has an Agent Registry, available on LangSmith Cloud and not on self-hosted installations, and it is not linked to any cloud registry. Agents hosted on LangSmith Deployment therefore appear in none of the three cloud registries automatically. OpenAI's Agent Builder is scheduled to shut down on 30 November 2026, and we found no agent registry in OpenAI's Agents API. Anthropic's Claude Managed Agents, in beta, can be synced into Agent 365. Whether they appear in the AWS or Google Cloud registries is unknown.

One technical detail decides whether traces line up with registry records. Registries that work from telemetry match a trace to an agent by an attribute called gen_ai.agent.id, and each consumer expects a different value in it. Agent 365 expects the Entra application ID of the calling app, and Microsoft's reference says a mismatch returns a 403 error and that spans without the identity attributes are dropped on the server even when the export call reports success. Foundry external agents expect whatever stable string was entered at registration. The OpenTelemetry conventions say the value should be the identifier the hosting provider assigned, such as an ARN. LangSmith ignores the attribute and routes by request headers. An agent that reports to two registries therefore needs its telemetry configured for each, and a developer should test that traces arrive before anyone relies on the registry for monitoring.

Section 07Which framework are you using?

Find your situation in the first column. Each row gives our recommendation, the reasoning and the caveat that would make us advise differently.

Our position is that a company with agents on more than one platform should keep its own register above the vendor registries, even if that register is a spreadsheet for now. We would change that advice for a company whose agents all sit on one vendor's runtime, where the vendor registry plus a few tags is enough. We would also revisit it if one vendor ships a scheduled, keyless sync that reconciles deletions, because that removes the main reasons the single cross-vendor list cannot be trusted today.

Section 08The minimum register, and what standards and laws ask for

Where no product covers an agent, a register with fifteen columns answers the six questions from the summary. The columns below are our synthesis from the standards quoted later in this section and from the fields the three cloud registries already hold. Because they map onto those fields, the content of a spreadsheet can be moved into a product later. Add one working column for reconciliation: the record ID of the agent in every vendor registry that lists it, such as the Entra agent ID, the AgentCore resource ARN or the Google registry identifier. That column is how duplicates are merged into one internal Agent ID, and how a row whose source record has disappeared gets flagged for review, which matters because Microsoft's sync does not reliably remove deleted agents.

Nine further fields can wait until the first fifteen are filled: users and channels, where logs go and how long they are kept, evaluation and red-team evidence, known issues and CVEs, a bill of materials with framework and tool versions, links to documentation, vendor and contract for purchased agents, regulatory filings, and retirement details.

None of these texts prescribes a field list for agents specifically, so the fifteen fields are our synthesis. The EU text we quote is the consolidated version of 27 July 2026 on EUR-Lex, which states that it is a documentation tool with no legal effect. And this paper is not legal advice: a company that may deploy a high-risk system under Annex III should ask its lawyers what Articles 26 and 49 require of it and from when.

Section 09A 30-day plan

The plan below assumes a company with agents on at least two platforms and no register today. The order matters more than the exact days, because each step uses the output of the one before.

• Step 1: Days 1 to 3. Name one person in IT who owns the register, and agree the fifteen fields with security and compliance.
• Step 2: Days 1 to 5. Export the Agent 365 registry to CSV. Record the counts for Total agents, Agents without owners, Unmanaged agents and Agents at risk as the baseline.
• Step 3: Days 3 to 8. On AWS, enable trusted access, register a delegated administrator, create the organization-scoped registry in each Region and enable auto-detection. On Google Cloud, choose the governance project or management boundary and enable the Agent Registry API.
• Step 4: Days 5 to 10. List what your configured discovery routes miss. Ask each platform owner for agents on Lambda, ECS, EKS, EC2 and other compute, for agents inside SaaS products that no connector covers, and for agents on devices without discovery coverage. Onboard devices to Defender for Endpoint if you use it.
• Step 5: Days 8 to 15. Decide which list is the master. If it is Agent 365, connect the other platforms with least-privilege keys, run the first sync and schedule the next ones by hand.
• Step 6: Days 10 to 20. Fill the fifteen fields for every agent, starting with the business owner and the kill switch. Block or retire agents that nobody claims.
• Step 7: Days 15 to 25. Set the standard for new agents: deploy to a runtime that gives each agent its own identity, serve an A2A card where the framework supports it, and agree which agent ID goes into telemetry for each registry.
• Step 8: Days 20 to 28. Clear the dated items. Plan the move of Foundry custom agents to external or hosted agents before 7 May 2027, and confirm that nothing still calls the retired AWS preview namespace.
• Step 9: Days 25 to 30. Hold the first review with the owners, set the recurring review date, and recheck vendor statuses after Microsoft Ignite and AWS re:Invent.

Section 10Limits of this paper

This paper draws on research compiled on 10 November 2026, mostly from the vendors' own pages. We did not test the products in a tenant for this paper, and capability lists are the vendors' statements. Some dates come from earlier checks, as with the general availability dates for the Agent 365 and AWS registries and for ServiceNow AI Control Tower. Two Microsoft Message Center posts were read on a third-party mirror, because the originals sit behind a tenant login.

Several points remain open and are marked in the text: whether Microsoft's registry sync is still in preview, whether AWS accepts A2A 1.0 agent cards, whether Google's Agent Identity is in preview or generally available, the status of the LlamaIndex template on Google Cloud, and how any framework maps to ServiceNow's connectors. The framework matrix reflects documentation and sample repositories, and we have not built each combination.

Details may change within weeks. Microsoft Ignite runs from 17 to 20 November 2026 and AWS re:Invent from 30 November to 4 December 2026, according to event listings, and registry announcements are possible at both. We will recheck the status labels in this paper after each event and date any change.

We help companies set up this register and the controls around it: finding the agents already running, choosing the master list, connecting the vendor registries, and writing the ownership and review rules that keep it current. Our guide at querynow.com/ai-agents/registry covers the registry products and the record we keep for each agent in more depth. Since 2014 we have delivered more than 200 production deployments on AI and the Microsoft platform, and we build on Azure and AWS, with teams in Texas and Munich. Every engagement starts with one scoped workflow and a written definition of done. Commercial terms are set in the statement of work.

What to do with this on Monday morning

1. 1. Export the Agent 365 registry to CSV and record how many agents have no owner.
2. 2. On AWS, enable organization auto-detection and create an organization-scoped Agent Registry in each Region you use.
3. 3. On Google Cloud, enable the Agent Registry API in a governance project, or set a management boundary if agents sit in several projects.
4. 4. List the agents your configured discovery routes miss: those on Lambda, ECS, EKS or EC2, inside SaaS products without a connector, and on devices without discovery coverage.
5. 5. Start a company register with the fifteen fields in this paper, and name one person in IT who owns it.
6. 6. If you registered custom agents in Foundry Control Plane, plan their move before 7 May 2027.
7. 7. Recheck the status labels in this paper after Microsoft Ignite (17 to 20 November 2026) and AWS re:Invent.