+ P

Integration · Observe

Observe for Semantic Kernel agents

Capture every Semantic Kernel plugin invocation and prompt render through the Kernel's own Filters — the same interception point Semantic Kernel uses for caching and responsible-AI checks.

Book a demo → Request access

TL;DR

Prefactor observes your Semantic Kernel agents in real time — every LLM call, tool invocation, and custom span captured as structured trace data the moment it happens, with cost attributed per call and a tamper-evident audit trail of every run.

Observe

pillar

TS + Py

official SDKs

Spans

LLM · tools · agents

Tokens

usage captured

How to add observe to Semantic Kernel

Install the SDK

Add prefactor-core to your environment.

Register & create spans

Spans flow to Prefactor

Structured trace data lands in Prefactor as your agent runs.

# pip install prefactor-core
import os
from prefactor_core import PrefactorCoreClient, PrefactorCoreConfig
from prefactor_http import HttpClientConfig

config = PrefactorCoreConfig(
    http_config=HttpClientConfig(
        api_url="https://app.prefactorai.com",
        api_token=os.environ["PREFACTOR_API_TOKEN"],
    )
)

client = PrefactorCoreClient(config)
await client.initialize()

# then instrument your Semantic Kernel run with spans — see docs.prefactor.ai

Shown with the Prefactor SDK — a first-class, working integration today.

How the Semantic Kernel integration actually works

Semantic Kernel's Filters (IFunctionInvocationFilter, IPromptRenderFilter) run before and after every function invocation and prompt render, with access to the function, its arguments, and its result — this is the real interception point Prefactor spans attach to, the same one Semantic Kernel's own docs use for caching and responsible-AI scenarios.
Because a function invocation filter can override the result, not just observe it, the same Filter interface is what a runtime policy check runs through — hold, replace, or block a plugin's result before the Kernel returns it.
Beyond auto-captured spans, use withSpan to record any custom step you define — an API call, a quality check, a business action.

What Prefactor captures for Semantic Kernel agents

LLM calls

Model, prompt, completion, and token usage recorded for every call — not batched, not sampled after the fact.

Tool invocations

Arguments, results, and errors for each tool the agent calls.

Agent spans

The run captured as nested spans you can inspect step by step — plus custom spans for whatever's specific to your own domain.

Cost per call

Token usage rolled up into cost, attributed to the agent, team, and task that spent it — the same span data, not a separate metering system.

Immutable audit trail

Every span and run written once, tamper-evident, full-text searchable, and exportable for compliance review.

Trace anything — not just LLM calls

The SDK captures LLM, tool, and agent spans automatically. With withSpan you wrap any operation in your own span type — an API call, a database query, a quality check, a business action — each with its own payload and schema. It all flows into the same Observe, Evaluate, and cost views.

research_competitorquality_checkpricing_lookuprefund_decisiondoc_retrieval …anything you define

import { withSpan } from "@prefactor/core";

// Wrap ANY operation in a span you define — an API call, a quality
// check, a business action — with its own spanType, inputs and schema
await withSpan(
  {
    name: "research competitor",
    spanType: "research_competitor",
    inputs: { competitor },
  },
  async () => {
    const results = await search(competitor); // your tool / API calls
    return summarize(results);                // captured as one span
  },
);

Nest spans to capture business-level actions, and start with permissive schemas you tighten over time. Instrumentation strategy →

An example run, span by span

Illustrative — a single Semantic Kernel run as nested spans.

Trace · Semantic Kernel run

1.84s6 spans1,210 tokensok

invoke_agent 1840

llm: plan 440

tool: search_kb 330

retriever: vector_search 210

llm: synthesize 700

tool: send_reply 320

agentllm calltool callretriever

Illustrative example.

Manual logging vs DIY vs Prefactor

Capability	Manual	DIY OpenTelemetry	Prefactor
LLM / tool / agent spans	Hand-rolled	✓ build it	✓ via the SDK
Token usage captured per call	—	Build it	✓
Configurable capture & sampling	—	Partial	✓
Hosted Admin UI (agents, instances)	—	—	✓
Risk profiles & audit trail	—	—	✓

Semantic Kernel observe — FAQ

What does Prefactor capture for Semantic Kernel?+

LLM calls, tool invocations, and agent spans — with inputs, outputs, and token usage — sent to the Prefactor API as structured trace data the moment they happen, not reconstructed from a log afterward.

Is Prefactor in my Semantic Kernel request path?+

No — the SDK instruments in-process and sends spans asynchronously. Your requests go straight to your model provider; Prefactor observes what happened alongside it.

How does cost tracking work for Semantic Kernel?+

Cost is derived from the token usage captured on each LLM span and rolled up by agent, team, and task — a view over the same trace data, not a separate metering system, so a cost spike traces back to the run that caused it.

Can audit records for Semantic Kernel runs be edited or deleted?+

No. Instances and spans are immutable once written, giving reviewers a real-time, queryable record of exactly what every agent did — the evidence a compliance review or an incident investigation actually needs.

Do I need a dedicated package for Semantic Kernel?+

You can instrument Semantic Kernel today with the framework-agnostic prefactor-core SDK; a dedicated package can be added on request.

What does Prefactor capture from Semantic Kernel?+

Prefactor records plugin (skill) invocations, planner steps, tool calls and LLM calls as structured, timestamped spans — so every Semantic Kernel run is captured as trace data you can reconstruct, search and export end to end.

Does Prefactor add latency or change how Semantic Kernel runs?+

No. Observability capture is designed to stay off your agent's critical path, so it doesn't alter your Semantic Kernel logic or your users' responses. The only part that acts inline is the optional runtime guardrails you enable per agent — by design, so a high-risk or low-confidence action can be held for human approval before it executes.

Can I evaluate agents built with Semantic Kernel and catch regressions?+

Yes. Once runs are captured, eval suites score quality and groundedness on real traffic, drift detection flags behaviour changes after deployment, and versioned eval history catches regressions before they ship — the observe → evaluate → improve loop applied to your Semantic Kernel agents.

Keep going

See it on your Semantic Kernel agents

Book a 15-minute setup and our team gets you observe in production.

Book a demo → Talk to integrations