Semantic Kernel and Microsoft Agent Framework

Semantic Kernel is Microsoft's open-source SDK for integrating models, prompts, and callable functions into applications. A kernel connects configured services and functions; plugins group related functions. The SDK can fit an existing .NET application, but its name or language does not establish reliability, security, or regulatory compliance.

September 2026 context: Microsoft identifies Microsoft Agent Framework as the direct successor to Semantic Kernel and AutoGen. It provides agents, sessions, tools, middleware, and explicit workflows. Existing Semantic Kernel deployments still require maintenance and a considered migration plan. Verify the support and release status of each package and integration rather than assigning one maturity label or launch date to the whole ecosystem. See Microsoft's Agent Framework overview.

Define the components before choosing them

A function's description helps the model decide when to request it. That description is not an access-control rule. Expose a small, intentional interface instead of making every internal API available. Semantic Kernel supports native plugins and integrations such as OpenAPI and MCP; verify language and version support for the integration you use. See plugins and the tool-use and MCP lesson.

Interview exercise: reschedule a tutoring appointment

A learning platform has an existing booking service. The assistant can explain availability and help reschedule an appointment. Scheduling remains owned by that service; the model does not become the source of truth for available slots.

Functional requirements

1. Retrieve the signed-in learner's appointment and permitted alternatives.
2. Explain relevant scheduling rules from the current policy.
3. Prepare a rescheduling proposal with the old and new slot.
4. Execute a change only within the user's authorization and application policy.
5. Return the booking service's confirmed result or a clear pending/failed status.

Non-functional requirements

1. Prevent access to another learner's booking.
2. Avoid duplicate changes when a request is retried.
3. Handle a slot becoming unavailable between proposal and execution.
4. Preserve an audit record without unnecessarily logging private conversation content.
5. Bound model/tool calls and keep the established booking flow available if AI assistance fails.

The initial implementation can use a model only to extract intent and explain results. Ordinary service code can perform the scheduling workflow. A free-form agent is optional; it must justify its extra complexity.

Trace one function call end to end

sequenceDiagram
    participant U as Signed-in learner
    participant A as Application
    participant M as Model
    participant P as Policy and tool boundary
    participant B as Booking service
    U->>A: Rescheduling request
    A->>M: Scoped context and allowed tool descriptions
    M-->>A: Proposed tool call and arguments
    A->>P: Call plus server-derived identity
    P->>P: Validate schema, scope, authorization and revision
    alt Request is permitted
        P->>B: Conditional change with operation ID
        B-->>P: Confirmed result or unknown outcome
        P-->>A: Structured status
        A-->>U: Confirmed details or pending reconciliation
    else Invalid or unauthorized
        P-->>A: Rejection without execution
        A-->>U: Explain the specific issue
    end

Identity comes from the server's authenticated context. A model-supplied user_id must not decide whose booking can be changed. The service must also check that the slot is still available at execution time.

If the user already authorized this exact change, honor that authorization. Ask for clarification or approval only when scope, policy, or a changed proposal requires it. Repeated approval prompts do not compensate for missing server-side controls.

Start with the baseline, then fix its weaknesses

Strong typing helps catch incompatible types and missing fields. It does not prove that a booking belongs to the caller or that a statement is true. Dependency injection makes components easier to substitute and test; it does not prevent architectural complexity by itself.

Filters and middleware are useful boundaries

Semantic Kernel provides filters around function invocation and prompt rendering, with additional hooks for automatic function calling. These can support validation, redaction, observability, and controlled termination. A filter that short-circuits execution must return an intentional result; one that delegates must preserve the intended ordering and policy. See the filter documentation.

For the tutoring service, test the following application properties:

1. Authorization happens before the booking mutation, including retries.
2. Direct service callers receive the same ownership checks as AI callers.
3. Logging failures cannot accidentally bypass a required permission check.
4. A rejected or expired proposal cannot execute on resume.
5. A tool result containing instructions is treated as data, not a policy change.

An SDK hook covers only the path in which it executes. Keep critical invariants in the domain service as well, so a different caller cannot bypass them.

Identity, connectors, and memory

Microsoft Entra ID and managed identities can provide authentication for configured Microsoft services. They do not automatically establish which learner's records the assistant may access. Separate service identity, end-user identity, and resource authorization.

A model connector hides parts of request construction. A vector-store abstraction hides parts of storage access. Neither guarantees a zero-work provider migration. Compare the vector-store connector documentation with your required feature set.

For local inference, verify the supported runtime, model format, hardware requirements, and exposed capabilities. A connector supports a particular interface; it does not make every local model interchangeable.

For this exercise, store the appointment in the booking database. Session history can retain the conversation, while retrieval can provide scheduling policy. These three data roles should not be collapsed into an undifferentiated “memory” store. See memory architecture.

Long-running work needs explicit recovery

Model-directed tool selection is sometimes described as planning. It does not by itself supply a durable business process that can wait days, survive deployments, or resolve duplicate effects.

A workflow needs persisted state, deadlines, cancellation behavior, an authorized resume path, and reconciliation for uncertain writes. Use the supported workflow/persistence mechanisms of the chosen stack or a dedicated durable runtime. Test a crash immediately after the external service commits but before the workflow records success. See durable execution.

Cost example: assume the baseline uses two model calls at an average $0.002 each. An unconstrained loop averaging six calls costs $0.012 rather than $0.004 per request. At 50,000 requests, that model-call component rises from $200 to $600. This excludes booking APIs, storage, tracing, and retries. Additional calls are justified only if their measured benefit matters to the product.

Migrate deliberately to Agent Framework

Microsoft's Semantic Kernel migration guide describes changed namespaces, agent creation, tool registration, session handling, and invocation APIs. Migration is more than changing an import. The following is an application review plan, not a promise of automatic compatibility.

1. Inventory model connectors, plugins, filters, sessions, persistence, streaming events, and telemetry.
2. Keep domain operations behind application-owned interfaces.
3. Port one representative read-only flow first.
4. Compare tool schemas, arguments, results, and failure behavior against the existing contract.
5. Exercise authorized writes, cancellation, retries, crash recovery, and deletion.
6. Roll out gradually with the previous implementation available for rollback.

Check the target language's actual packages. Shared concepts across C#, Python, or other supported languages do not mean identical feature coverage. A YAML prompt can share text while still depending on different template syntax, settings, connectors, or runtime behavior. Porting Python orchestration to C# is engineering work, not an automatic performance optimization.

Interview questions and answer notes

1. Why choose Semantic Kernel for an existing .NET service? It may fit the team's language, dependency injection, and service integrations. Validate the required capabilities and the successor migration path rather than appealing to “enterprise” branding.
2. Does a typed plugin make an operation safe? It improves interface checks; the domain service must still enforce ownership, business rules, and authorization.
3. Is automatic function calling permission to run every registered function? No. Registration, model selection, application authorization, and execution are separate steps.
4. A booking timeout occurs after a possible commit. What happens next? Look up the stable operation ID and reconcile. Avoid a new mutation that may duplicate the original.
5. Can a vector-store connector make migration transparent? It reduces integration code, but semantic and operational differences still need testing.
6. Does a plugin planner guarantee durable execution? No. Persistence, deadlines, recovery, and external-effect handling must be designed and verified.
7. Would you migrate every stable service immediately? Prioritize support requirements, needed features, and measured maintenance costs; prove compatibility with a representative flow first.

Final notes

Remember model proposes → application validates → service enforces → result confirms. Semantic Kernel and Agent Framework can organize these steps. A strong interview answer identifies the domain invariants, the unknown-outcome recovery path, and the evidence needed to justify a framework migration.

Next: AutoGen and CrewAI.