A production milestone for agent visibility
Google has marked the App Topology API generally available in Gemini Enterprise Agent Platform. The 30 September release note says teams can now use the API to inspect agent topologies and highlights improvements to the Topologies page. A new query builder allows custom quick queries, while a single-agent topology with one-hop traffic to and from an agent loads automatically in Agent Registry. The change is about operating and governing agents, not adding a new model.
Visibility becomes harder as an organisation connects agents to MCP servers, data stores, other agents and cloud resources. A failure or unexpected permission path may cross several systems before it is apparent to an end user. A topology view aims to make those relationships explicit so a platform team can ask which component talks to which other component, which identity is involved and where a dependency or risk sits.
What the graph can show
Google’s documentation describes topology queries that correlate agent resources, traffic and supporting cloud data. Depending on configuration, a graph can include agents, MCP servers, endpoints, skills, identities, underlying infrastructure, alerts and vulnerabilities. Teams can use it to identify an unregistered workload, understand the effect of an access-policy change or investigate a security finding connected to a deployed agent.
A graph is only as complete as its inputs. Google instructs customers to register agent resources, instrument AI applications for traffic data and enable other services when they want corresponding details. Security Command Center information, for example, requires the appropriate organisational setup and service tier. The generally available API does not automatically discover every privately operated tool or fill gaps in uninstrumented traffic.
Custom queries alter the investigation flow
The updated query builder lets an operator start from a suggested query or create a custom one by choosing nodes, filters and directional relationships. The documentation gives examples such as an agent containing a vulnerability or a resource sending traffic to another service. This makes the view more than a static diagram. A security engineer can refine a question from all agents in a project down to those using a particular gateway, identity or dependency.
Google says the Topologies page can also show a simple single-agent view automatically when the traffic pattern is one hop in each direction. That may help an owner begin with a manageable picture before exploring a larger estate. It should not be mistaken for proof that no other dependency exists. The view depends on registered and observed data, and an operator should verify its completeness before using it for a change or incident decision.
Setup and access are not automatic
Documentation lists several prerequisites: a Google Cloud project with billing, enabled App Hub, App Topology, Cloud Asset Inventory and Observability APIs where relevant, and the roles required to view the results. An administrator can grant the App Topology Viewer role for read access. Organisations using VPC Service Controls need to account for the topology and source services in their perimeter. These steps affect whether the feature yields useful data in practice.
The need for a dedicated viewer role is a sensible boundary. Topology data can reveal how an agent is connected to internal systems, so access should be granted to people who need it for operations or review. Teams may also want to decide how long query results and related telemetry are retained, and whether alerts or security findings carry information that needs more restricted handling.
Where it is useful first
The strongest first use case may be change review. Before connecting an agent to a new MCP server, a platform team can inspect its current traffic and permissions, document the intended new path, then compare the resulting graph after deployment. During an incident, a topology can help locate the resources downstream of a compromised identity or a failed tool. In routine operations, it can reveal agents that were deployed but never properly registered for oversight.
General availability signals that Google considers the API ready for production use, but an organisation must still test its coverage and query results. The practical value is not a prettier diagram; it is a more reliable account of how agent systems are assembled and where an intervention should be made. As deployments grow from one assistant to fleets of autonomous workers, that kind of operational map becomes a necessary companion to model evaluation and prompt design.
A useful rollout measure is whether the topology answers a question the team previously struggled to resolve, such as which agents use a credential that is about to rotate or which external tool depends on a failing gateway. If the graph cannot answer that question, the next step is to improve registration or instrumentation rather than to assume the dependency is absent. Treating the view as an evidence surface, with documented gaps, is more valuable than treating it as an automatically complete inventory.