ecosystem.agents

Connect any agent. Govern them all.

It does not matter which framework it is built on, who maintains it or where it runs: if it emits telemetry, it is in. Three ways in, one trace table and the same governance for all of them.

Request a demo See the platform

agent.origin

Three origins, one registry

A real agent estate is never homogeneous. What matters is not where each one came from, but that they are all visible in the same place and under the same rules.

governed

The agents you already have

Built with whatever framework, on your infrastructure or someone else's. They are registered with their service name, receive their key and start emitting. There is nothing to rewrite.

governed

The ones you build with AKP

AKP is the kernel Social Labs uses to deliver bespoke agents for large clients. It ships with the policy, tracing and telemetry connectors to Regentic.AI: point them at your instance and there is no integration to write.

platform

The platform's own

Regentic.AI runs its own agents to analyse, evaluate and write. They are registered in the same registry and emit to the same table, flagged as platform agents.

ingest.plans

Three integration plans

The choice is one of transport, not of functionality: all three write to the same trace table and look identical in the product. Pick whichever gives you the least friction.

Plan A · OpenTelemetryrecommended

Native OpenTelemetry

If your agents are already instrumented with OpenTelemetry, there is no integration to write: point the exporter at your instance and that is it.

endpoint: https://<your-instance>/v1/traces
authentication: Authorization: Bearer agv_…

You already have tracing with OpenTelemetry or MLflow Tracing
You want the full span detail without reshaping formats
You would rather route through your own Collector

exporter environment variables

# point your existing OpenTelemetry exporter at Regentic.AI
export OTEL_EXPORTER_OTLP_ENDPOINT="https://<your-instance>"
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer agv_..."
export OTEL_SERVICE_NAME="customer-support-bot"

Plan B · REST API

REST API

A POST with the same data model in JSON. This is the route when you cannot stand up OpenTelemetry, or when your network makes it awkward.

endpoint: POST https://<your-instance>/api/v1/otel-traces
authentication: X-Agent-Key: agv_…

There is no OTLP support in your environment
You would rather control sending and retries yourself
You want to start today with a single HTTP call

sending one trace

curl -X POST https://<your-instance>/api/v1/otel-traces \
  -H "X-Agent-Key: agv_..." \
  -H "Content-Type: application/json" \
  -d '{
    "trace_id": "3f9a...",
    "spans": [{
      "span_id": "a1b2...",
      "name": "agent-run",
      "attributes": {
        "gen_ai.request.model": "gpt-4o-mini",
        "gen_ai.usage.input_tokens": 142,
        "gen_ai.usage.output_tokens": 387
      }
    }]
  }'

# 202 Accepted -> {"accepted": 1, "trace_ids": ["3f9a..."]}

Plan C · MCP

Model Context Protocol

The agent consumes governance as MCP tools: it queries policy before acting and reports the outcome afterwards, all within the same trace.

endpoint: https://<your-instance>/mcp
authentication: Authorization: Bearer agv_…

Your agent already speaks MCP
You want governance to be just another tool for the agent
You care about correlating decision and outcome in the same trace

MCP server configuration

{
  "mcpServers": {
    "regentic": {
      "url": "https://<your-instance>/mcp",
      "headers": { "Authorization": "Bearer agv_..." }
    }
  }
}

Whatever arrives by any of the three paths lands in the same table and feeds exactly the same modules. Switching plan later does not force you to redo any of the earlier work.

agent.identity

Every trace belongs to someone, and it can be proven

In a governance system, telemetry that can be forged is worth nothing. An agent's identity is anchored to its key, not to whatever the agent itself declares.

Every agent has its own prefixed key and its own unique service name
The service name sent in the payload is overwritten with that of the authenticated agent; what was declared is kept aside as forensic data
On read, an agent only sees its own telemetry: it cannot query anyone else's
Platform agent keys cannot be used to ingest, so nobody can emit while posing as one of them
Keys can be rotated without deregistering the agent or losing its history

identity anchored to the key

# what the agent claims in its payload
resource.service.name         = "some-other-agent"

# what Regentic.AI actually stores
service_name                  = "customer-support-bot"   # from the API key
client.reported_service_name  = "some-other-agent"       # kept as forensic data

The service name is the agent's canonical identity across the whole system: it is what ties a loose trace to its entry in the registry and to its compliance profile.

mcp.loop

The full loop: query, act, report

With MCP the agent asks before acting and reports afterwards. Both calls hang off the same trace, so the decision and its outcome stay joined and can be audited together.

The six tools

contractual

check_policy
report_result
report_trace

Their names come from a signed integration guide and cannot be changed.

query tools

get_stats
query_traces
get_trace

They extend the contract and are always scoped to the authenticating agent: they include an ownership check, so asking for someone else's trace returns "not found".

governance loopMCP

# 1 — ask before acting; returns the ids of the span it just wrote
policy = check_policy("query_knowledge_base", {"kb": "moves-iii"})
# -> { "allowed": true, "policy_id": "OBS-DEFAULT", "mode": "observation", ... }

# 2 — the agent does its work
answer = agent.run(question)

# 3 — report back, hanging off the very same trace
report_result(
    action="query_knowledge_base",
    result={"status": "ok", "tokens": 529},
    trace_id=policy["trace_id"],
    parent_span_id=policy["span_id"],
)

What check_policy actually does today

It runs in observation mode: it instruments the query and always returns allowed, under the OBS-DEFAULT policy. It does not intercept or prevent any action. What it gives you is an auditable record that policy was consulted at that point in the execution — not an admission control. If your requirement is blocking in real time, we do not cover that today, and we would rather tell you now.

agent.origin=platform

The platform governs itself

The agents Regentic.AI runs internally sit in the same registry as yours, with their declared risk classification, their oversight mechanism and their telemetry in the same table. It is the cheapest proof that the model works: we apply it to ourselves first.

regentic-analyst
Data Expert
The conversational agent behind the chat. It queries telemetry read-only and returns answers with their charts and verified links.
conversationallimited risk
regentic-judge
Telemetry Evaluator
Scores recorded executions across the five quality dimensions and leaves its reasoning as evidence.
monitoringminimal risk
regentic-reporter
Report Writer
Writes the narrative of the reports over figures already calculated. It emits its own trace, with its model and its consumption.
automationminimal risk

faq.integration

Frequently asked questions

Which agent frameworks do you support?

The right question is which telemetry formats we understand, and there the answer is broad: alongside the OpenTelemetry semantic conventions for GenAI, we normalise the MLflow and OpenInference formats and generic usage objects. If your framework emits tokens and model in any of those shapes, we read them without you having to adapt anything.

Do I have to pick a plan for good?

No. All three write to the same table and produce exactly the same result in the product. You can start with REST because it is the quickest and move to OpenTelemetry once you have the Collector in place, without losing anything already ingested.

Can one agent see another agent's telemetry?

No. With an agent key, queries are forced to its own service name, and asking for a trace that does not belong to it returns "not found". Isolation does not depend on the agent behaving well.

What happens if an agent declares a service name that is not its own?

It gets nowhere. The canonical name of the authenticated agent overwrites whatever comes in the payload, and what was declared is stored separately precisely so it can be investigated. Identity is anchored to the key.

Can Regentic.AI stop an agent from executing an action?

No. The policy query is recorded but always allows: it is observation, not admission control. What you get is the evidence that the decision was taken and with what result, not the ability to veto it.

How much work is connecting the first agent?

Register the agent, copy its key and point the exporter or make a POST. What usually takes longer is not the integration, but agreeing internally on which agents exist — which is exactly the problem the registry solves.

Start with one agent

You do not need a governance programme to start. You need one agent emitting traces and someone looking at them.