+ P

Integration · Evaluate

Evaluate 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 evaluates your Semantic Kernel agents — score outcome quality against the captured spans, track drift by comparing custom spans across versions and environments, and classify every run's risk on two axes: data sensitivity and action consequence.

Evaluate

pillar

TS + Py

official SDKs

Spans

LLM · tools · agents

Tokens

usage captured

How to add evaluate 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

Outcome quality

Score agent outputs against your own criteria, task by task, using the continuous run history as the record to measure against.

Drift detection

Compare custom spans for the same operation across versions and environments — a model update or prompt change shows up as a difference between spans, before it shows up as a quality drop.

Risk classification

Every run scored on data sensitivity and action consequence, weighted into a Low / Medium / High / Critical classification.

Data tagging

Tag PII and other sensitive fields once in the schema; every run carrying that tag becomes searchable — the record enforcement acts on.

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 evaluate — FAQ

Does evaluation reuse the same Semantic Kernel integration?+

Yes — evaluation runs on the spans the SDK already records for Semantic Kernel, so there is one integration, not a separate one for evaluation.

What is quality drift and how is it detected for Semantic Kernel agents?+

Drift is a change in behaviour over time — after a model update, a prompt change, or a data shift. Because a custom span records the same Semantic Kernel operation every time it runs, this week's spans can be compared directly against last week's, or against a different version or environment.

How is risk scored for Semantic Kernel runs?+

On two axes — data sensitivity (what kind of data the run touched) and action consequence (what the agent did with it) — combined via configurable weights into a Low/Medium/High/Critical classification per run.

Can I tag and find PII across Semantic Kernel runs?+

Yes — tag the fields that matter once in your agent's data schema, and every run carrying that tag becomes searchable across your whole Semantic Kernel deployment, not just the run it was tagged in.

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 evaluate in production.

Book a demo → Talk to integrations