Introduction
Your framework does not have to be on any list. If an agent can emit OpenTelemetry spans, it can be governed here exactly like one built on a supported platform — same registry record, same policies, same incidents. This page is for everything the picker does not name.
Who this is for
An agent framework that is not in the platform picker.
An agent you wrote from scratch against a model API.
A service that is not obviously "an agent" but calls models and uses tools, and that you want governed like one.
An internal platform your organisation built, with many agents on top of it.
Note: Not being in the picker means no pre-written setup instructions. It does not mean unsupported. Platforms without setup content show "No setup available" on the
Setuptab. Use the SDK steps of the closest supported framework.
The approach
Register the agent — Pick the closest supported framework. There is no generic platform in
Register Agenttoday.Configure the exporter yourself — Point your OpenTelemetry exporter at the endpoint and key shown in that framework's SDK setup (
UNIFYAPPS_COLLECTOR_ENDPOINT,UNIFYAPPS_API_KEY). See OpenTelemetry.Emit model calls and tool calls as spans — This is the whole job, and the next section is about why the second half matters more than the first.
Verify, then run — The
Setuptab showsWaiting for traces…until the first trace arrives.
What makes an agent governable
Governance does not need to know your framework. It needs four things in the telemetry, and it can do progressively more as you supply them:
Emit | Unlocks |
A span per run, with parent-child structure | The agent appears, activity is counted, the run has a readable shape |
Model calls with token usage | Cost attribution, spend per trace, model-view reporting |
Tool calls with their arguments | Every tool-surface control — blocked tools, secrets, PII on egress |
Tool results | Prompt-injection detection on retrieved content, output validation |
The third row is the one teams skip, because instrumenting the model client is easy and instrumenting tools takes deliberate work. It is also where the irreversible actions are.
"An agent that only reports its model calls is telling you what it thought, not what it did."
Registering at the right granularity
With a custom framework you choose what counts as one agent, and the choice is harder than it looks because nothing forces it. The registry record is simultaneously the unit of ownership, of policy coverage, and of cost attribution.
Split into separate records when | Keep as one when |
Different people are accountable | One team owns all of it |
Different rules should apply | The same rules apply throughout |
You need cost broken out | Aggregate cost is the useful number |
One faces customers and one does not | They share an audience and a risk profile |
A platform hosting many internal agents is usually several records, not one — otherwise every incident names the platform and nobody knows which agent caused it.
One limit to be clear about
An agent registered this way is on an advisory footing: controls evaluate and record, and actions other than Flag need an enforcement point the platform provides. A custom agent reporting over OTLP has no such point — you are sending observations, not routing requests through anything.
So prevention for a custom agent lives inside the agent. Do not give it a tool it must never call; validate before you act on retrieved content; keep credentials out of tool arguments. Governance will tell you when something got through, and telling you is genuinely most of the value — see Governing Vendors Without a Control API.
A checklist before you call it done
Status is Active — Traces are arriving.
A trace shows tool calls, not just model calls — Open one and look. This is the check most worth doing by hand.
Cost is populated — If not, token usage is missing from your spans.
The Policies tab is not empty — Instrumentation without a policy is observation, not governance.
An owner is set, and it is not just whoever registered it — See Ownership, Workspace & Department.