Any Agent, Any Source

The first test of an agent control plane is whether it can manage the agents you already know about. The better test is whether it can find the agents you did not build with its preferred tools. The hardest test is an agent built entirely on another cloud platform, with no Microsoft code in its implementation. That is where the promise becomes concrete: agents built on Google Vertex AI, where AI means artificial intelligence, or Amazon Bedrock can be registered into Microsoft Agent 365 without development work, then enhanced later with deeper enterprise capabilities when the organization is ready.

The promise worth proving

A control plane is useful only if it can sit above the diversity that already exists in an enterprise. Most large organizations will not have one kind of agent, one build tool, one cloud, or one runtime. They will have agents created by business teams, professional developers, vendors, platform teams, and experimental groups moving at different speeds.

That is why the original promise matters: any agent, from any source. It is not enough for Microsoft Agent 365 to govern agents created with Microsoft tools. That would be the easy case. The meaningful test is whether the same control plane can reach agents built somewhere else, by some other platform, without requiring the builder to rebuild the agent around Microsoft-specific assumptions.

This closing article focuses on that test. It shows how discovery starts even when the agent has no Microsoft code, and how governance can then be added in practical layers rather than forced as a disruptive migration.

The hardest case: agents built on another cloud

Consider agents built on Google Vertex AI or Amazon Bedrock. These platforms are not Microsoft agent frameworks, and the agents may contain no Microsoft code at all. Even in that case, registration into the Agent 365 registry requires no development work from the agent builder.

The registration path uses the source platforms' own application programming interfaces (APIs). Those APIs make the agents discoverable so they can appear in the Agent 365 registry. The builder does not need to add the Microsoft Agent 365 software development kit (SDK), implement an identity blueprint, or change the agent's code just to make the agent visible.

This is an important distinction. The first milestone is not deep instrumentation or full policy enforcement. The first milestone is inventory: the organization can see that the agent exists, where it came from, and that it belongs in the same management picture as other agents.

Automatic registration is visibility, not magic

Automatic registration means the agent can enter the registry without a custom development project. It does not mean every governance capability is instantly complete. That separation is healthy. It lets organizations close the visibility gap first, then decide which agents need deeper controls next.

The source platform remains the place where the agent was built and where it may continue to run. Agent 365 becomes the control plane view that brings the agent into the enterprise inventory. From there, security, platform, and compliance teams can reason about the agent alongside the rest of the fleet.

This matters at scale because unseen agents are the hardest to govern. A perfect policy cannot help if the organization does not know the agent exists. Automatic registration turns the first problem from discovery by rumor into discovery through platform integration.

Enhancement happens in layers

Once an externally built agent is registered, the organization can decide how far to take it. The Agent 365 SDK can be introduced to add observability, Work IQ, Microsoft's work-context capability for agents, governed tool access, and other enterprise features.

The useful part is that this does not have to happen all at once. A low-risk internal agent may need only inventory and ownership at first. A high-impact agent that acts on business data may need telemetry, policy checks, governed tool calls, and stronger review before it is trusted in production.

This incremental model fits how enterprises actually change systems. It avoids the false choice between doing nothing and rewriting everything. Visibility can arrive first. Instrumentation can follow. Access governance can deepen as the agent's importance grows.

The decision leaders and practitioners face

The practical question is not whether every agent should be treated identically on day one. It is how to create a consistent path from unknown, to known, to trusted. Automatic registration gives leaders and practitioners a starting point for that path.

A chief information security officer may care first about unmanaged agents that can touch sensitive systems. A platform architect may care about whether agents across clouds can be inventoried without a bespoke connector for every team. A product team may care about whether adding governance will slow delivery. The architecture has to answer all three concerns at the same time.

The operating model should therefore separate discovery, classification, and enhancement. Discover broadly. Classify by risk and business importance. Add deeper capabilities where the risk and value justify them.

1. Make the registry the common inventory for agents across sources.
2. Assign ownership and business purpose as early as possible.
3. Prioritize deeper controls for agents that access sensitive data, invoke important tools, or act with high autonomy.
4. Use the Agent 365 SDK where observability, Work IQ access, or governed tool use is needed.
5. Avoid forcing every team into a rebuild when registration and incremental enhancement are enough.

How this closes the architecture

Seen in isolation, automatic registration for Vertex AI and Bedrock agents may look like a connector feature. In the context of the whole architecture, it is more than that. It proves that the control plane is not limited to one build path.

The series began with the need for a control plane, then explained Microsoft Agent 365 and its foundational pillars. It moved through agent identity, templates, registries, access control, data protection, threat protection, risk prioritization, build tools, governed connections to data, and observability. Each topic solved one part of the same problem: how to let software act with enough freedom to be useful while keeping enough control to be trusted.

External-cloud registration is the closing proof because it reaches beyond the easiest boundary. An agent can be built outside Microsoft, discovered through its source platform, placed into the same registry, and later enhanced through the same enterprise model.

The durable lesson

The phrase any agent, any source is easy to repeat and hard to make real. It becomes real only when discovery crosses vendor and cloud boundaries, and when governance can be applied without demanding that every team abandon the tools it already uses.

That is the durable lesson of the series. The goal is not to celebrate a particular toolchain. The goal is to build justified trust in agents that can decide, call tools, retrieve information, and take action. Trust requires visibility, identity, policy, protection, telemetry, and a way to improve controls over time.

Observe. Govern. Secure. Those three words remain the shortest useful summary. They apply to agents built by a central platform team, agents created inside a productivity suite, and agents running on another cloud. The source may vary. The need for control does not.

Glossary

Agent

An agent is software that can use information, make decisions, and take actions on behalf of a person, team, or process.

Control plane

A control plane is the central management layer that observes, governs, and secures systems without being the system that performs every task.

Google Vertex AI

Google Vertex AI is Google's cloud platform for building, deploying, and managing artificial intelligence models and agents.

Amazon Bedrock

Amazon Bedrock is Amazon's cloud platform for building and running generative artificial intelligence applications and agents.

Application programming interface (API)

An application programming interface is a defined way for software systems to exchange information or request actions from each other.

Software development kit (SDK)

A software development kit is a set of libraries, tools, and guidance that helps developers add capabilities to an application or agent.

Agent registry

An agent registry is the shared inventory where agents are recorded so they can be found, owned, reviewed, and managed.

Identity blueprint

An identity blueprint is a repeatable template for creating agent identities with the right ownership, permissions, and governance settings.

Observability

Observability is the ability to understand what a system is doing by collecting and analyzing signals such as events, traces, and metrics.