Introduction

When Discovery reports that a platform is running sixteen agents, the obvious question is how it knows. This page answers it, because the answer determines what Discovery can and cannot find.

The short version: UnifyApps asks the platform. It does not infer.

Where to find it

AI Governance > Discovery — the DISCOVERED column is the output of the process described here.

How identification works

Every platform that hosts agents exposes its own API for listing them. Discovery calls that API through the connection you selected, and reads the asset-type metadata the platform returns.

1. The connection authenticates — Discovery uses the credentials already stored on the connection. It sees exactly what that identity is permitted to see, and nothing more.

2. The platform's list API is called — Each connector knows the right call for its platform. What comes back is the platform's own inventory, in the platform's own vocabulary.

3. Each connector decides the asset type — Most providers return agents only; OpenAI and Core42 Compass return models; n8n reads workflow definitions and returns each AI Agent node as an agent.

4. Counts are written to DISCOVERED — The result is summarised per asset type on the connection's row — for example 10 agents, or 132 models.

Why not inference

A heuristic approach — matching names, watching traffic patterns, guessing from model calls — would find more things and be wrong about some of them. In governance, a wrong inventory is worse than a smaller one: it produces incidents against assets that do not exist and gives an auditor a list nobody can reconcile.

"An inventory you cannot reconcile against the source system is not an inventory. It is a second opinion."

Reading the provider's own metadata means every row in your registry can be traced back to a record on the platform that hosts it. That is the property an audit needs.

What this means for coverage

1. Coverage is bounded by the platform's API — If a platform does not expose a list-agents API, Discovery cannot enumerate its agents. Those agents are governed by registering them manually and instrumenting them with an SDK.

2. Coverage is bounded by the connection's permissions — Discovery sees what the connection's identity can see. A connection scoped to one project returns that project's agents, not the tenant's. An empty DISCOVERED on a platform you know is busy is usually a permissions gap, not a product limit.

3. New platforms arrive quickly — Because identification rides on the connector layer rather than on bespoke detection logic, adding a platform is largely a matter of teaching the connector one more call.

Refer: For agents on platforms Discovery cannot reach, see Register an Agent Manually.

Identification is not governance

Identifying an agent puts it in the registry. It does not put it under policy, and it does not start collecting traces from it.

A discovered agent with no traces and no policies is a known unknown — you have established it exists, which is the whole point of the exercise, but you have not yet established what it does. Applying a policy is a separate, deliberate step.

Best Practices

1. Scope connection credentials to the widest read you can justify — Discovery inherits the connection's blind spots. A narrowly scoped identity produces a narrow inventory that looks complete.

2. Reconcile the first sweep against what the platform team believes exists — The gap between the two numbers is the finding. It is usually the most useful output of the first week.

3. Treat an empty result as a question, not an answer — A dash in DISCOVERED means the sweep returned nothing. Confirm whether that is the truth or the permissions.