Enterprise Plugins and Connectors from Semantic Kernel

Semantic Kernel taught enterprise teams to package capabilities as plugins and to swap connectors for models and services behind a kernel.

Microsoft Agent Framework keeps the capability idea but simplifies the surface: tools attach directly to agents, chat clients replace many connector hierarchies, and optional SK compatibility helpers ease migration.

Summary

Map SK plugins to Agent Framework tools (@tool or plain functions), choose a provider chat client (Foundry, Azure OpenAI, OpenAI, and others), attach least-privilege tools per agent, and use middleware plus MCP/hosted tools where SK filters and remote skills used to live.

Recipe

1. Inventory existing SK plugins: functions, auth needs, side effects, and callers.
2. Classify each function as safe for model invocation vs host-only internal API.
3. Re-express model-callable functions as Python callables or @tool with clear descriptions.
4. Replace Kernel + service registration with a chat client (FoundryChatClient, OpenAIChatClient, Azure-routed clients - verify names at build).
5. Create agents with tools=[...] instead of attaching plugins to a kernel.
6. For gradual migration, convert supported KernelFunction assets via SK compatibility helpers when available (as_agent_framework_tool - requires sufficiently new SK).
7. Move cross-cutting auth, PII redaction, and allowlists into middleware.
8. Prefer MCP or Foundry hosted toolboxes for shared enterprise capabilities rather than copying plugin code into every service.

Working Example

SK-style plugin class → AF tools on an agent:

from typing import Annotated
from agent_framework import tool
from agent_framework.openai import OpenAIChatClient
 
class OrdersPlugin:
    """Enterprise-shaped capability group (not an SK Kernel plugin type)."""
 
    def __init__(self, api_client):
        self.api = api_client
 
    @tool
    def get_order_status(
        self,
        order_id: Annotated[str, "Customer order id"],
    ) -> str:
        """Return fulfillment status for an order."""
        return self.api.status(order_id)
 
    @tool
    def list_open_orders(
        self,
        customer_id: Annotated[str, "Customer id"],
    ) -> str:
        """List open orders for a customer."""
        return self.api.open_orders(customer_id)
 
plugin = OrdersPlugin(api_client=...)  # inject real client / credentials in host
client = OpenAIChatClient(model="gpt-4o")  # verify at build
agent = client.as_agent(
    name="OrderSupport",
    instructions="Answer order questions using tools. Never invent status.",
    tools=[plugin.get_order_status, plugin.list_open_orders],
)

Connector choice sketch:

# OpenAI-shaped
from agent_framework.openai import OpenAIChatClient
client = OpenAIChatClient(model="gpt-4o")
 
# Foundry-shaped
from agent_framework.foundry import FoundryChatClient
from azure.identity import AzureCliCredential
client = FoundryChatClient(
    project_endpoint=ENDPOINT,
    model=DEPLOYMENT,
    credential=AzureCliCredential(),
)

Deep Dive

Mental model shift

You still group related methods on a class for DI and shared clients. The framework no longer requires that class to be a formal kernel plugin to be useful.

Tool categories you will actually use

Connectors become clients

SK connector configuration moves into chat client constructors and environment settings. Agent Framework documents first-party paths for Foundry, Azure OpenAI, OpenAI, and expanding provider coverage (Anthropic, Bedrock, Gemini, Ollama - treat availability as version-sensitive).

Pick clients by:

1. Data residency and auth (Entra ID, managed identity, API keys).
2. Tool matrix (Responses vs Chat Completions capabilities differ).
3. Hosting plan (local process vs Foundry-hosted agent).

Migration compatibility

Official SK → AF guides show converting KernelFunction instances to Agent Framework tools with helpers such as .as_agent_framework_tool(...) on sufficiently new Semantic Kernel versions. Use that bridge for gradual cuts, not as a permanent dual-runtime architecture.

Vector store search functions created in SK can often be adapted the same way for hybrid retrieval while you re-home agents.

Enterprise packaging patterns

• Shared library of tools: versioned Python package of approved functions, imported by many agents.
• MCP server per domain: orders, HR, ITSM expose MCP; agents attach as clients.
• Foundry toolboxes: named, versioned hosted bundles when you standardize on Foundry.
• Secrets: inject via host DI into plugin class __init__; never prompt the model for keys.

Gotchas

1. Porting plugins without least privilege - a kitchen-sink plugin on every agent reintroduces SK anti-patterns.
2. Assuming every hosted tool works on every client - Responses vs Chat Completions matrices differ.
3. Keeping a Kernel forever "just in case" - dual stacks double support load; schedule an end date.
4. Missing descriptions - tools without clear docstrings degrade tool selection quality.
5. Side-effecting tools without approval - destructive operations need middleware or approval_mode patterns (verify defaults at build).
6. Connector sprawl - five slightly different Azure clients in one app confuse ops; standardize.
7. Treating MCP as automatic security - remote tools still need authz and egress controls.

Alternatives

FAQs

Related

• From AutoGen and Semantic Kernel to Microsoft Agent Framework 1.0 - why plugins re-homed
• Microsoft Agent Framework Basics - first tools demo
• Governance and Enterprise Controls in Microsoft Agent Framework - middleware and policy
• Graph-Based Workflows in Microsoft Agent Framework - tools inside executors
• Microsoft Agent Framework Best Practices - production practices
• Tool Use and Function Calling Basics - general tool design

Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana @solana/web3.js + @solana/spl-token.