What is Boidra Platform?

Boidra Platform is an observability and evaluation dashboard for AI agents. Your agents, LLM calls, and MCP tool executions emit OpenTelemetry spans; Boidra Platform ingests them over OTLP, stores them, and turns them into traces, cost reports, alerts, and LLM-based evaluations.

If you already emit OpenTelemetry GenAI spans, pointing them at Boidra Platform is a matter of setting one environment variable.

Built for SAP BTP + AI Core

Boidra Platform is designed to run on SAP BTP and to observe agents that call SAP AI Core — the two work together:

• SAP AI Core is where your agents' LLM calls happen. Boidra Platform reads the AI Core foundation-model catalog (models, versions, retirement dates, per-token prices) and uses it to cost every trace accurately and to warn when an agent is calling a deprecated or soon-to-retire model.
• SAP BTP is where Boidra Platform itself is deployed. The dashboard also uses AI Core for its own LLM-powered features — the LLM judges, the AI-written usage reports, and Detect Issues — configured with an AI Core destination and resource group on the Settings page.

Built on SAP standard, not into it

Boidra Platform does not change SAP's standard products. SAP AI Agent Hub, the Integration Suite MCP Gateway, MCP Builder, Joule and AI Core stay exactly as SAP ships them; Boidra is the layer on top that makes working across them simpler. See what stays in SAP and what Boidra adds.

You are not locked to AI Core for emitting telemetry: any OpenTelemetry-compatible SDK works (see Connect AI assets). AI Core is what powers the pricing, model-lifecycle, and AI-assisted features on top.

What you get

• Trace explorer — one row per trace, drill into every span, and a swimlane flow view (Agent → LLM Chat → MCP Tool).
• Cost & usage reporting — spend over time, per-model and per-service breakdowns, and AI-written usage reports you can schedule and share.
• Alerts — rules on error rate, latency, and token/cost budgets (per service or across all services, over a rolling window, this month, or this year), with a one-click jump from a firing alert to the failing traces.
• Detect Issues — run an LLM over selected traces to surface correctness, latency, execution, adherence, relevance, and safety problems.
• Evaluation — datasets built from real traces + LLM judges + asynchronous eval runs.
• AI Asset Dashboard — one catalogue of approved agents, MCP servers and skills: register and review before publishing, rank by likes and installs, suggest by role, and install into Joule Work.

How it works

Your agent (instrumented with an OpenTelemetry-compatible SDK) exports spans to the Boidra Platform ingest endpoint. The backend maps each span to the telemetry data model, stores it, and the dashboard reads from there.

Storage: Postgres for non-production, HANA for production

Boidra Platform keeps its spans and app state in a relational database, and the tier depends on the environment:

Environment	Database	Why
Local / dev / staging	PostgreSQL	Zero-cost, easy to run anywhere, fine for non-production volumes
Production (SAP BTP)	SAP HANA Cloud	The managed BTP database — scales with production trace volume and stays inside your BTP account

The data model is the same either way; only the connection target changes between environments. See Installation for how to point at each.

The data model in one minute

Boidra Platform recognizes three kinds of span, keyed off the OpenTelemetry GenAI gen_ai.operation.name attribute:

Span type	Represents	Carries
invoke_agent	A top-level agent turn	agent name, model, tokens, conversation id
chat	An LLM call	model, input/output tokens
execute_tool	A tool / MCP call	tool name, tool type, MCP server

The spans nest into a tree by parent span id: an invoke_agent span wraps the chat and execute_tool spans it produced.

See Instrument → Overview for the full attribute mapping.

Why the conversation id matters

Every agent turn carries a conversation id (the OpenTelemetry gen_ai.conversation.id attribute, sometimes called the context id). It is the single most important field for making agent traces useful, because it stitches related activity together:

• It groups a multi-turn conversation. All the turns a user has with an agent share one conversation id, so you can follow a whole session — not just isolated requests.
• It ties an agent to the tools it used. Because the execute_tool spans nest under the invoke_agent span that carries the conversation id, Boidra Platform can answer "which tools did this agent call, for this conversation?" — you can filter the trace list to a tool (e.g. get_incident) and see exactly which agent turns invoked it, error status and all.
• It follows agent-to-agent hops. When one agent calls another over A2A, the conversation id (and trace context) propagate across the HTTP call, so an orchestrator → sub-agent → tool flow lands as one connected trace instead of disconnected fragments.

Set it once on your invoke_agent span and reuse it across the turns of a conversation:

# The conversation id is what links turns and ties tool calls back to the agent.
with tracer.start_as_current_span("invoke_agent my-agent", attributes={
    "gen_ai.operation.name": "invoke_agent",
    "gen_ai.agent.name": "my-agent",
    "gen_ai.conversation.id": conversation_id,   # ← reuse across a conversation
}):
    ...

In the dashboard, the conversation id appears as a Context ID column on the trace list (filterable) and as a chip on the trace detail header.

Next steps

• Installation — run the dashboard and backend, and configure the database.
• Quickstart — send your first trace and see it appear.
• Connect AI assets — wire up real telemetry.