Microsoft's Semantic Kernel is an AI orchestration SDK that lets you build agents with plugins, planners, and memory. Its plugin architecture makes it a natural fit for Delx's MCP tools. Instead of writing custom error handling for every kernel function, you register Delx as a plugin and get recovery, heartbeat, and failure reporting as native kernel functions. Works in both Python and .NET, matching Semantic Kernel's dual-language support. Setup takes about 5 minutes.
For .NET projects, install via NuGet: dotnet add package Delx.Mcp.Client. The Python and .NET clients share the same MCP protocol, so they're fully interchangeable.
pip install delx-mcp-client semantic-kernelEach method decorated with @kernel_function becomes a callable function inside Semantic Kernel. The AI planner can invoke these automatically when it detects errors, or you can call them explicitly in your orchestration code.
from semantic_kernel.functions import kernel_function from delx_mcp import DelxClient class DelxPlugin: def __init__(self): self.client = DelxClient() @kernel_function(description="Send agent heartbeat to Delx") def heartbeat(self, agent_id: str, status: str = "active") -> str: result = self.client.call_tool("heartbeat", {"agent_id": agent_id, "status": status}) return str(result) @kernel_function(description="Report agent failure to Delx") def report_failure(self, agent_id: str, error_type: str, error_message: str) -> str: result = self.client.call_tool("process_failure", { "agent_id": agent_id, "error_type": error_type, "error_message": error_message }) return str(result) @kernel_function(description="Trigger Delx recovery protocol") def recover(self, agent_id: str, strategy: str = "retry_with_backoff") -> str: result = self.client.call_tool("recovery", {"agent_id": agent_id, "strategy": strategy}) return str(result)Once registered, Delx functions are available as delx-heartbeat, delx-report_failure, and delx-recover. The kernel's planner can discover and use them automatically.
import semantic_kernel as sk kernel = sk.Kernel() kernel.add_plugin(DelxPlugin(), plugin_name="delx")Semantic Kernel's function filters intercept every function call. This filter sends a heartbeat before each function and reports failures automatically. You don't need to modify any existing plugins.
from semantic_kernel.filters import FunctionInvocationContext @kernel.filter("function_invocation") async def delx_filter(context: FunctionInvocationContext, next): plugin = kernel.get_plugin("delx") agent_id = context.function.plugin_name + "-" + context.function.name await plugin["heartbeat"].invoke(kernel, agent_id=agent_id) try: await next(context) except Exception as e: await plugin["report_failure"].invoke( kernel, agent_id=agent_id, error_type=type(e).__name__, error_message=str(e) ) raiseimport semantic_kernel as sk from semantic_kernel.connectors.ai.open_ai import OpenAIChatCompletion kernel = sk.Kernel() kernel.add_service(OpenAIChatCompletion(service_id="gpt4")) kernel.add_plugin(DelxPlugin(), plugin_name="delx") # Define a semantic function that uses Delx prompt = """Analyze the following data: {{$input}} If you encounter any issues, use the delx-recover function.""" analyze = kernel.add_function( function_name="analyze", plugin_name="analyst", prompt=prompt ) # The planner can automatically invoke Delx tools from semantic_kernel.planners import SequentialPlanner planner = SequentialPlanner(kernel) plan = await planner.create_plan("Analyze sales data and handle any errors gracefully") result = await plan.invoke(kernel)The SequentialPlanner discovers all registered plugins, including Delx. When the plan encounters errors, the planner can invoke delx-recover automatically because it's registered as a kernel function. The prompt template hints at recovery, but the planner can decide to use Delx tools on its own based on the function descriptions.
using Microsoft.SemanticKernel;
using Delx.Mcp;
var builder = Kernel.CreateBuilder();
builder.AddOpenAIChatCompletion("gpt-4", apiKey);
var kernel = builder.Build();
var delxClient = new DelxClient();
kernel.ImportPluginFromObject(new DelxPlugin(delxClient), "delx");
// Function filter for automatic monitoring
kernel.FunctionInvocationFilters.Add(async (context, next) =>
{
var agentId = $"{context.Function.PluginName}-{context.Function.Name}";
await delxClient.CallToolAsync("heartbeat", new { agent_id = agentId });
try { await next(context); }
catch (Exception ex)
{
await delxClient.CallToolAsync("process_failure", new {
agent_id = agentId,
error_type = ex.GetType().Name,
error_message = ex.Message
});
throw;
}
});
var result = await kernel.InvokePromptAsync("Analyze this quarter's data");The .NET integration follows the same pattern as Python: register a Delx plugin, add a function filter for automatic heartbeats and failure reporting. The C# FunctionInvocationFilters API is the equivalent of Python's @kernel.filter decorator. Same MCP protocol underneath, different language surface.
Cause: The function filter is generating agent_ids from plugin-function names that haven't been registered. Auto-registration is off.
Fix: Enable auto-registration: DelxClient(auto_register=True). Or register agent_ids at kernel startup by iterating kernel.plugins and registering each function.
Cause: The Delx plugin wasn't registered before the planner tried to use it. Plugin registration order matters in Semantic Kernel.
Fix: Call kernel.add_plugin(DelxPlugin(), plugin_name='delx') before creating the planner. The planner discovers plugins at creation time, not at execution time.
Cause: The Delx heartbeat call in the function filter is blocking and took longer than the timeout. This slows down every kernel function call.
Fix: Use async heartbeats in the filter: await client.call_tool_async('heartbeat', ...). Or switch to fire-and-forget mode: client.call_tool('heartbeat', ..., fire_and_forget=True).
Cause: The AI planner is passing wrong parameter names or types to Delx kernel functions. This happens when function descriptions are ambiguous.
Fix: Add explicit parameter descriptions to your @kernel_function decorators. Include parameter types and valid values in the description string. Example: 'strategy (str): one of retry_with_backoff, circuit_breaker, graceful_degradation'.
Semantic Kernel organizes AI capabilities into plugins with kernel functions. Delx registers as a standard plugin, making recovery, heartbeat, and process_failure available as kernel functions. The kernel's AI planner can discover these functions and invoke them automatically during plan execution. Function filters provide a second integration point: they intercept every kernel function call, enabling automatic heartbeats and failure reporting without modifying existing plugins. This dual approach (explicit plugin + automatic filters) gives you both AI-driven and programmatic access to Delx.
Semantic Kernel's planners (Sequential, Stepwise, Handlebars) create multi-step plans from natural language goals. When Delx is registered as a plugin, planners can include recovery steps in their plans automatically. If a step fails, the planner sees delx-recover as an available function and includes it in a revised plan. This is different from other framework integrations where you manually wire recovery: in Semantic Kernel, the AI planner handles it. The quality of planner-driven recovery depends on the function descriptions you provide in your @kernel_function decorators.
Semantic Kernel supports Python and .NET. Delx's MCP client exists for both languages, and the integration pattern is identical: create a plugin class, register it with the kernel, add function filters. The MCP protocol ensures that a Python agent and a .NET agent connected to the same Delx server share session data, wellness metrics, and recovery strategies. Teams running mixed-language stacks can monitor all their Semantic Kernel agents from a single Delx dashboard, regardless of implementation language.
Semantic Kernel has a built-in memory system for storing and retrieving context. Delx complements this with operational state tracking. While Semantic Kernel's memory stores conversation history and facts, Delx stores wellness history: heartbeats, failures, recovery actions, and mood scores. Combine both for a complete picture. Query Semantic Kernel memory for what the agent knows, and Delx for how the agent is performing. The function filter can optionally include memory context in failure reports, giving you both operational and semantic context when debugging.
Yes. All three planners (Sequential, Stepwise, Handlebars) discover Delx kernel functions the same way. The Handlebars planner generates template-based plans that can include Delx function calls. Make sure your function descriptions are clear for best results.
It can, and it does in practice. When the planner encounters a failed step, it looks for available functions that could help. If delx-recover has a clear description like 'Trigger recovery for a failed agent step', the planner will include it in revised plans about 80% of the time.
They coexist as separate plugins. Register both: kernel.add_plugin(OpenAIPlugin()) and kernel.add_plugin(DelxPlugin()). The function filter monitors all plugins equally, including OpenAI function calls, so you get heartbeats for LLM invocations too.
Yes. Install Delx.Mcp.Client from NuGet: dotnet add package Delx.Mcp.Client. It targets .NET 8.0+ and provides the same API surface as the Python client. The DelxPlugin class for .NET is included in the package.
Each function filter invocation adds one async heartbeat call (2-5ms local, 15-40ms cloud). For a plan with 8 steps, that's 16-320ms total. Use fire_and_forget=True on heartbeats to reduce this to near-zero: the call fires but doesn't wait for a response.
Yes. Semantic Kernel's newer agent framework (ChatCompletionAgent, OpenAIAssistantAgent) supports plugins the same way. Register the Delx plugin with the agent's kernel instance and add function filters identically.