Use Orq.ai as the model control layer for Semantic Kernel. Route LLM calls through one OpenAI‑compatible endpoint, capture traces, monitor cost, and manage fallback behavior without rebuilding your Semantic Kernel kernels, plugins, or agent workflows.
What is Semantic Kernel?
Semantic Kernel (SK) is Microsoft’s open‑source SDK and agent framework that lets you mix C#, Python, or Java code with LLMs via kernels, plugins (semantic + native functions), memory, and planners. It helps teams focus on orchestration and enterprise integration instead of wiring every model call and multi‑step workflow from scratch.
Why use Orq with Semantic Kernel?
Semantic Kernel (SK) is Microsoft’s open‑source SDK and agent framework that lets you mix C#, Python, or Java code with LLMs via kernels, plugins (semantic + native functions), memory, and planners. It helps teams focus on orchestration and enterprise integration instead of wiring every model call and multi‑step workflow from scratch.
Why use Orq with Semantic Kernel?
Card 1 – Trace kernel and agent behavior end to end
Trace Semantic Kernel runs end to end, including prompts, plugin calls, planner steps, memory lookups, model responses, and errors in one place. You get clearer visibility into how each kernel composed functions and reached a result, without stitching together logs from multiple services.
Card 2 – Model flexibility without rewiring kernels
Test new models, add alternative providers, or assign different model tiers to different SK services, plugins, or agents from Orq.ai, while keeping your kernel configuration and orchestration logic stable. Your kernel still “thinks” it’s talking to an OpenAI/Azure‑style client; Orq decides which underlying model or provider is called.
Card 3 – Evaluate real production runs
Use real SK traces like kernel invocations, planner plans, function chains, and LLM calls to build datasets, compare prompt or model changes, and move from subjective tuning to measurable quality checks. Failed or slow runs can be turned into eval inputs before you roll out changes
How the integration works
Card 4 – Control spend and access centrally
Track token usage and spend per kernel, plugin, agent, team, and workflow so you can see which routes drive cost. Add budgets, rate limits, and approved‑model lists at the Orq platform layer instead of enforcing governance separately inside each Semantic Kernel‑based application.
How the integration works
Step 1 – Point SK’s AI services at Orq.ai’s router
Configure your AIService / OpenAIChatCompletionService / AzureOpenAIChatCompletionService (depending on language) to use Orq.ai’s OpenAI‑compatible router URL and API key instead of calling OpenAI or Azure directly. SK continues to treat these as AI connectors; Orq becomes the routing backend.
Step 2 – Enable tracing from Semantic Kernel to Orq
Keep SK’s built‑in telemetry and filters while exporting OpenTelemetry spans (or other tracing) for LLM calls to Orq’s OTLP endpoint. Semantic Kernel remains your middleware with its own observability, and Orq records LLM interactions, latency, and cost metrics, so you see both kernel‑level and model‑level traces.
Step 3 – Define routes, fallbacks, and policies in Orq
Use cases
Create routes for key SK workflows (for example RAG plugins, multi‑step planners, or agent frameworks) and assign them model tiers, fallback chains, and region/data policies. SK sends LLM requests through configured Orq routes, and Orq applies routing rules before invoking OpenAI, Azure OpenAI, Gemini, Claude, or other models.
Step 4 – Monitor, evaluate, and tune
Once connected, use Orq’s dashboards to watch latency, errors, and cost for SK‑backed apps, and run evals or experiments on their traces. You can adjust routes, models, or prompt configurations centrally where supported, while Semantic Kernel continues to manage kernels, plugins, memory, and planners.
Use cases
Multi‑plugin and agentic apps with real observability
Trace which kernel, plugin (semantic or native function), memory call, and model contributed to a failed workflow or unexpected outcome, combining SK’s telemetry with Orq’s router‑level traces.
Cost‑aware enterprise copilots
Route simple semantic functions (summarization, translation) to lower‑cost models while keeping complex planning, multi‑plugin orchestration, or compliance‑sensitive flows on your strongest routes configured in Orq.
FAQ
Eval‑driven kernel and plugin improvements
Reuse failed plans, low‑quality outputs, and slow kernel runs as eval inputs before shipping prompt, plugin, or model changes, turning production telemetry into a continuous improvement loop.
Safer experimentation across providers
Test new models or providers (for example swapping Azure OpenAI vs OpenAI vs other LLMs) on a small share of SK traffic, then promote or roll back based on traces and evals, instead of editing each plugin or AI service config by hand.
Semantic Kernel alone
Semantic Kernel + Orq.ai
Model access
AI services (OpenAI, Azure OpenAI, etc.) and API keys are configured directly in the kernel’s AI connectors per project
Model access is managed through Orq.ai’s router, keeping provider changes and multi‑provider routing outside your kernel, plugin, and agent code
Observability
