AICopy Anchor Link

AI in Owlpane spans three surfaces: the investigation assistant that chats over your telemetry at /observability/agent, AI Teammates that run role-based investigations at /observability/ai-teammates, and LLM observability that monitors the model traffic itself at /observability/llm.

What it isCopy Anchor Link

AI here is not a separate product bolted on — it reads the same logs, metrics, and traces the rest of the console does, and it proposes rather than acts. Two distinct audiences are served: engineers who want a hand investigating an incident, and teams who want to watch the latency, cost, and quality of their own LLM and agent features.

The investigation assistantCopy Anchor Link

The assistant (/observability/agent) answers questions about a scope and gathers read-only evidence to explain what it finds. Its surfaces are:

The assistant is bring-your-own-key: you configure the model provider and credentials under Settings → AI (/settings/ai).

AI TeammatesCopy Anchor Link

AI Teammates (/observability/ai-teammates) are role-based investigators — SRE, Security, and Delivery — that gather read-only evidence and produce structured briefings on alerts, SLO burn, and CI failures.

• Hire and lead — assign a human lead who is notified when a teammate's run finishes or fails.
• Scope — limit automatic runs to specific services or environments (an empty scope means all).
• Runbooks — index your procedures so briefings can cite them.
• Ask binding — open a chat session bound to a teammate's tool allowlist.
• Approve queue — teammates propose changes; a human approves them before anything is applied. Recent decisions show executed, failed, and rejected items.

Two requirements apply here specifically: AI Teammates require the platform LLM to be enabled for the workspace, and any AI-initiated operational action is routed through the approval queue rather than applied directly. The platform LLM is configured by the operator; Settings → AI is where you set bring-your-own-key and acknowledge egress.

LLM observabilityCopy Anchor Link

LLM observability (/observability/llm) tracks latency, errors, tokens, and cost across LLM and agent traffic. It has dedicated views for Sessions (/observability/llm/sessions), where calls are tied together by a conversation, session, or thread ID and can be compared, and Quality (/observability/llm/evals) for evaluations. Prompt and completion text are never stored or shown.

Where data gets inCopy Anchor Link

The assistant and teammates read the telemetry you already ingest — nothing extra is required beyond enabling the model. LLM observability needs LLM spans, which arrive over OTLP like any other tracing data.

• OpenLIT LLM observability integration — emit LLM spans to Owlpane.
• Distributed trace ingestion — the span pipeline LLM telemetry rides on.
• OTLP ingest reference — the endpoints involved.
• Environment reference — configuration endpoints.

ConceptsCopy Anchor Link

Safety modelCopy Anchor Link

Everything the AI does is read-only until a person approves otherwise. The assistant gathers evidence; teammates produce briefings and propose follow-up actions; those proposals wait in the approve queue. Operator flags decide whether an approval is executed or recorded only, so a workspace can graduate from audit-only to action as its operators gain confidence. Prompts are redacted before leaving Owlpane.

RelatedCopy Anchor Link

• AI Teammates task guide — roles, runbooks, and the approve queue.
• AI & IDE plugin (MCP) — inspect Owlpane from your editor.
• Alerts and on-call — the alerts and SLO burn teammates investigate.
• Metrics · Logs · Traces — the evidence AI reads.