platform.control_plane
A control layer over everything your agents do
Regentic.AI collects the telemetry from every execution, turns it into an inventory, evaluates it against deterministic rules and leaves it ready as auditable evidence. Four modules over a single trace table.
4
modules
over the same data
3
ingestion plans
OTel · REST · MCP
5
evaluation dimensions
LLM-as-Judge, 0–1
4
EU AI Act articles mapped
12 · 13 · 14 · 15
pipeline.stages
The same data, read four ways
There are not four products, nor four integrations. There is one trace that comes in once and is read as debugging, as quality, as control and as evidence. That is the whole thesis.
- 01
Ingestion
Every execution arrives as OpenTelemetry traces and lands in a single table.
- OTLP/HTTP · /v1/traces
- REST · /api/v1/otel-traces
- MCP · /mcp
- 02
Governance
Deterministic thresholds over metrics, plus quality evaluation across dimensions.
- rules engine
- LLM-as-Judge
- agent_compliance_profiles
- 03
Analytics
Aggregation by agent, model and period, with estimated cost and trends.
- Executive Dashboard
- estimated cost
- CSV export
- 04
Evidence
Versioned, verifiable reports, each with its EU AI Act section and its hash.
- manifest_hash SHA-256
- PDF with disclaimer
- daily · biweekly · monthly
module.telemetry
Telemetry
every execution, reconstructable
Monitoring, alerts, incidents, agent logs and — the hard part — the full conversation reconstructed from loose spans.
- Monitoring of traces, latency, tokens and errors per agent
- Alerts and incidents with an open → acknowledged → resolved cycle, deduplicated by entity
- Automatic reopening if the condition recurs, and automatic resolution once it stops
- Agent Logs: the execution step by step, with its tool calls
- Conversations: turns reconstructed from the telemetry, with no extra instrumentation
Conversation reconstruction
The platform does not store conversations: it reconstructs them. Each trace is a turn; a conversation is the set of traces sharing a session identifier. That identifier is extracted from whichever key each framework emits, and it is never the same one.
Session keys it recognises
gen_ai.conversation.idsession.idsession_idmetadata.thread_idmetadata.conversation_id
The identifier is extracted from the key each vendor uses. There is no need to change how you instrument your agents.
Reconstructed conversation
01K9F3…A72C- user · turn 1
How many invoices went unreconciled last month?
- agent · turn 2
42 invoices went unreconciled, 6% of everything issued.
- user · turn 3
Show me the five largest by amount.
deterministic correlation · no LLM at runtime
module.asset_registry
AI Asset Registry
an inventory, not a spreadsheet
Knowing which agents exist is the precondition for governing them. The registry is the living list of your AI assets, and every agent carries its compliance profile with it.
- Agents classified by type and by origin: yours and the platform's own
- Every agent with its unique service name, which anchors its traces and prevents impersonation
- Knowledge Bases on Qdrant, with their usage traced
- One compliance profile per agent, 1:1 — not a parallel record that drifts out of sync
Registered agents
customer-support-botconversationalgovernedinvoice-extractorautomationgovernedinfra-watchdogmonitoringgovernedregentic-report-writercustomplatform
{{WIP: systems, IoT and data sources appear in the product navigation as a roadmap vision; today they have no functional backing and are not offered as a capability}}
module.governance
AI Governance
deterministic rules, no LLM at runtime
A threshold that always fires the same way is auditable; a judgement that shifts between runs is not. That is why the rules engine is deterministic code, and the model only steps in where it adds something: scoring the quality of a response.
- Thresholds over real execution metrics, per event or over a time window
- Severity from low to critical and an alert or incident action, with deduplication
- LLM-as-Judge evaluation across five dimensions, scored from 0 to 1
- Per-agent coverage of Articles 12, 13, 14 and 15 of the EU AI Act, derived from real data
Governance rule
- WHEN
error_rate > 0.05 - MODE
windowed · 24h - SEVERITY
HIGH - THEN
incident
evaluable metrics
- tokens_per_query
- latency
- cost
- sensitive_data
- missing_session_id
- error_rate
Evaluation of one execution
0 – 1task_success0.94groundedness0.88tool_call_correctness0.97pii_leakage0.91policy_adherence0.83
The five dimensions are scored from 0 to 1 over traces already recorded, in batches or on demand. Evaluation always happens after execution: it never sits between the agent and the user's answer. Each result stores the judge model and the prompt fingerprint, so it can be reproduced.
module.analytics
Analytics
from aggregated data to sealed evidence
The executive dashboard answers the board's question — what is this costing us, which agents are failing, how much coverage do we have — and the report generator turns that answer into a document you can file.
- Estimated cost, tokens, executions, error rate, average evaluation score, open events and compliance coverage
- Cost trend per service and agent ranking by spend
- Filters reflected in the URL, so a dashboard can be shared as it stands
- CSV export of the detail behind every figure
- Daily, biweekly or monthly reports, per agent or for the whole platform
- 01Executive summary
- 02Key indicators
- 03Operations and performance
- 04GenAI usage and costs
- 05Knowledge (RAG)
- 06Governance and compliance — EU AI Act
- 07Incidents and events
- 08Recommendations
- 09Annexes and methodology
manifest_hashsha256:9f2c…d41e
The figures are calculated deterministically from the telemetry. The model writes the narrative over figures already calculated and generates none of them; if the model is unavailable, the report is still produced with a minimal narrative derived from the manifest. Every version is sealed with the fingerprint of its dataset.
Two caveats we would rather state before the demo
Cost is a deterministic estimate based on public per-model rates, not an invoice: it is there to compare and to spot drift, not to reconcile with your provider. And there is no custom dashboard builder and no machine-learning anomaly detection: there is one defined executive dashboard and a threshold engine you can read and predict.
capability.chat
Chat is a capability, not a module
It runs through the whole platform as a side panel and also has its own full-screen view. It is enabled per client, so it may not be in your deployment.
- Natural-language queries over your own telemetry data
- Read-only SQL agent, with a denylist over sensitive columns
- The charts it returns are validated against a closed catalogue of types: line, bar, area, pie and scatter
- Deep links from the answer to the specific entity in the product
Natural-language chart generation lives in the chat. It is not in the executive dashboard, and that is a product decision, not an oversight.
mcp.tools
The MCP server
Exposed at /mcp over streamable HTTP. Three of its tools are contractual — their names come from a signed integration guide and cannot be changed — and the rest extend querying, always scoped to the authenticating agent.
See how an agent connects# contractual — frozen names
check_policy(action, params?)
-> { allowed: true, policy_id: "OBS-DEFAULT", mode: "observation" }
report_result(action, result, metadata?, trace_id?, parent_span_id?)
report_trace(payload)
# scoped to the authenticated agent
get_stats()
query_traces(status?, page=1, size=20)
get_trace(span_id)check_policy observes today; it does not block
The tool runs in observation mode: it records the policy query and always returns allowed. It does not intercept or prevent actions at runtime. Regentic.AI observes, evaluates, audits and leaves evidence — and that is exactly what it promises.
faq.technical
Frequently asked questions
Do I have to change my agents to integrate them?
No, not if they already emit OpenTelemetry traces: point the exporter at your instance and you are done. If they do not, there is a REST API that accepts the same format in JSON, and an MCP server. All three paths write to the same trace table, so functionality does not depend on which one you pick.
Can Regentic.AI stop an agent from doing something?
No. The platform observes, evaluates, audits and produces evidence; it does not sit in the execution path. The check_policy tool runs in observation mode today and always returns allowed. If your requirement is blocking actions in real time, we do not cover that today.
Is a language model used to decide whether there is an alert?
No. The rules engine is deterministic code: thresholds over metrics, in per-execution or windowed mode. The same data always produces the same result, which is what makes it auditable. The model appears in only two bounded places: scoring the quality of a response, and writing the narrative of the reports.
How are conversations reconstructed if you do not store them?
By correlating the spans we already receive through the session identifier, extracted from whichever key each framework uses. The process is deterministic and runs over stored telemetry, without calling any model.
Do the reports guarantee that I comply with the EU AI Act?
No, and be wary of anyone who promises that. The reports document, with real data, what evidence exists for each obligation and where the gaps are, which speeds the work up enormously. An agent's risk classification is declared and assisted, not an automatic legal determination.
Which SDKs are available?
Two, both in Python: one for the REST API and one for MCP. There is no official SDK for JavaScript, .NET, Java or Go. For any other language the route is the OpenTelemetry SDK you already use, or the REST API directly — which is precisely why all three plans write to the same place.
Put it over your own agents
The fastest way to know whether this is useful to you is to see it with your telemetry, not ours.