Semantic Kernel To Agents Framework

Semantic Kernel to Agents Framework Migration

1. Assessment

Scan the solution to build a complete picture of SK agent usage. Capture findings in assessment.md.

Packages to Scan For

Search all project files and package management files (Directory.Packages.props) for:

• Microsoft.SemanticKernel.Agents.Core
• Microsoft.SemanticKernel.Agents.OpenAI
• Microsoft.SemanticKernel.Agents.AzureAI
• Microsoft.SemanticKernel — check if used solely for agents or also for other SK features (prompts, memory, connectors)

File Inventory

Search all code files across the solution for using Microsoft.SemanticKernel.Agents. Record which files in which projects contain these usings — this gives a quick per-project file count that drives planning.

Code Patterns to Identify

For each project with SK agent references, scan code files for:

| Pattern | What to Record |

|---------|---------------|

| Agent types (ChatCompletionAgent, OpenAIAssistantAgent, AzureAIAgent, OpenAIResponseAgent, A2AAgent) | Which types, how many instances |

| Provider usage (OpenAI, Azure OpenAI, Azure AI Foundry) | Provider per agent — determines target AF package |

| Tool/function registration (KernelPlugin, KernelFunction, [KernelFunction]) | Agent-specific vs shared kernel plugins |

| Thread management (AgentGroupChat, AgentThread, manual thread passing) | Multi-agent orchestration complexity |

| InnerContent access | Breaking-glass pattern — needs RawRepresentation migration |

| DI registration of agents or SK services | How agents are wired into the application |

Risk Indicators

Flag these as higher complexity in the assessment:

• Mixed SK usage: Project uses SK for both agents AND other features (prompts, memory, connectors) — cannot remove Microsoft.SemanticKernel package entirely
• Multi-agent orchestration: AgentGroupChat or custom agent-to-agent patterns — thread management differs significantly in AF
• Custom channel implementations: Extending SK agent channels — no direct AF equivalent
• Test projects mocking SK agent types: Test seams change with AF interfaces

Assessment Output

Create assessment.md in the workflow folder with this structure:

# Assessment: Semantic Kernel to Agents Framework

## Affected Projects
| Project | SK Agent Packages | Agent Types | Provider | Risk |
|---------|-------------------|-------------|----------|------|
| MyApp.Agents | Agents.Core, Agents.OpenAI | ChatCompletionAgent (2) | Azure OpenAI | Low |
| MyApp.Tests | (transitive) | Mocks ChatCompletionAgent | — | Medium |

## Transitive Consumers
Projects that reference affected projects but don't directly use SK agents:
- [list or "none"]

## Key Findings
- [Notable patterns, risks, or decisions needed]

2. Planning

Based on the assessment, create plan.md with a task per project ordered bottom-up (leaf dependencies first, then consumers).

For each task include:

• Project name and path
• What changes are needed (packages, code patterns)
• The AF provider package to use (based on assessed provider)
• Risk level and anything requiring user decision

Projects that are transitive-only consumers (no direct SK agent code) still need a task if their code references types from affected projects that will change.

3. Execution

Execute the plan task by task. For any task that involves migrating SK agent code or packages, apply the migrating-semantic-kernel-to-agents feature skill. It provides:

• Package replacement mappings
• API and namespace transformations (ref/api-mappings.md)
• Provider-specific patterns (ref/provider-patterns.md)
• Validation checklist

After completing all tasks, do a final solution-wide search for any remaining Microsoft.SemanticKernel.Agents references and fix stragglers.

4. Validation

• Build the full solution — zero errors required
• No remaining Microsoft.SemanticKernel.Agents namespace references in code
• If the project had tests, run them and report results