AzureFeeds

Over the last few years, Microsoft has had two key open-source agent frameworks: Semantic Kernel (SK) and AutoGen. The Agent Framework unifies these two approaches into a single SDK + runtime for building agents and multi-agent workflows for both Python and .NET.

The value proposition:

• The framework converges the best of Semantic Kernel (type‑safe skills, state/threads, filters, telemetry) and AutoGen (simple multi‑agent patterns), providing a single SDK to define agents, tools, and explicit workflows for multi‑step tasks and human‑in‑the‑loop scenarios.


• Native support for Connected Agents (agents invoking agents as tools) and stateful, long‑running multi‑agent workflows with context persistence and recovery


• Protocols and connectors (e.g., MCP, A2A, OpenAPI 3)


• When paired with Azure AI Foundry Agent Service, you get a managed runtime to host agents, threads, tools, and connected multi‑agent workflows.

Code Migration: From Semantic Kernel / AutoGen to Agent Framework

As you’ve likely discovered in your work building cloud-scale agentic systems, frameworks matter. Semantic Kernel and AutoGen have each served distinct but complementary roles in Microsoft’s AI-agent ecosystem with Semantic Kernel providing enterprise-grade integration and stability, and AutoGen offering cutting-edge multi-agent orchestration abstractions. But juggling two frameworks has meant different patterns, disparate APIs, and sometimes duplicated porting effort. Microsoft’s new Agent Framework addresses that by unifying the capabilities of both, giving you a more consistent path from prototype through production. 

If you’ve already used SK or AutoGen, this is particularly relevant. Some of the key points:

• SK and AutoGen will continue to be supported


• The migration guides show the mapping: e.g., in SK you had kernels, plugins; in Agent Framework you have ChatAgent. In AutoGen you had AssistantAgent, FunctionTool etc, now unified under the Agent Framework abstractions. Below is an example on creating an Agent vs now in Agent Framework.# Using Semantic Kernel
  import asyncio
  from semantic_kernel import Kernel
  from semantic_kernel.connectors.ai.open_ai import AzureChatCompletion
  from semantic_kernel.agents import ChatCompletionAgent

  async def main():
  # Initialize the kernel + chat completion service
  kernel = Kernel()
  kernel.add_service(
  AzureChatCompletion(
  api_key=”YOUR_AZURE_API_KEY”,
  endpoint=”https://YOUR_ENDPOINT.openai.azure.com/”,
  deployment_name=”your-deployment”
  )
  )

  # Create an agent
  agent = ChatCompletionAgent(
  service=kernel.get_service(AzureChatCompletion),
  name=”PoemWriter”,
  instructions=”You are a helpful assistant that writes poems.”
  )

  # Run a single user prompt
  response = await agent.get_response(messages=”Write me a poem about autumn.”)
  print(response.content)

  asyncio.run(main())

  # Agent Framework
  import asyncio
  from agent_framework.azure import AzureOpenAIChatClient
  from azure.identity import AzureCliCredential

  async def main():
  # Create chat client
  chat_client = AzureOpenAIChatClient(credential=AzureCliCredential())

  # Create the agent (instructions + name)
  agent = chat_client.create_agent(
  instructions=”You are a helpful assistant that writes poems.”,
  name=”PoemWriter”
  )

  # Run the agent with a prompt
  result = await agent.run(“Write me a poem about autumn.”)
  print(result.text)

  asyncio.run(main())
  

Why this matters in your context:
As someone designing cloud-solution architectures the migration story becomes a decision point: do you continue current SK/AutoGen projects, or plan to transition them to Agent Framework now? If you do, you need to plan for potential refactoring of agent, thread, tool definitions and workflows. But the benefits (simpler unified SDK, stronger production readiness) may outweigh the migration cost.

Some tips for migration strategy:

• Inventory your current agent assets built on SK or AutoGen: which ones are simple chat assistants, which ones involve multi-agent workflows, which ones have long-running/workflow/approval logic.


• Prioritize migrating simpler agents first to validate the new pattern.


• Take advantage of the built-in migration guidance from Microsoft.


• Ensure your tool integrations, memory/context components are compatible with the new model (Agent Framework offers pluggable memory providers etc).


• Update your CI/CD pipelines, observability/telemetry to align with the Agent Framework’s patterns.


• Consider deployment environment: Agent Framework is built with production readiness (Azure AI Foundry integration, container/host support, etc). 

For more examples on Code Migration from Semantic Kernel / Autogen to Agent Framework refer to official repo https://github.com/microsoft/agent-framework/tree/main/python/samples

DevUI: Interactive Developer UI for Agent & Workflow Development

 

One of the developer experience (DX) highlights of the Agent Framework is the DevUI component, an interactive UI for developing, testing, and debugging agents and workflows. DevUI helps you visualize for Agentic Design Patterns and debug their flows. This is not a drag and drop feature. Instead Your agents flows get written with Code and then get translated visually. With Workflow Builder you can add edges to your nodes. The code below what generated the image above, all done locally in VS Code.

def create_complex_workflow():
“””Create the complex fan-in/fan-out workflow.”””
# Create all executors
data_ingestion = DataIngestion(id=”data_ingestion”)

# Validation stage (fan-out)
schema_validator = SchemaValidator(id=”schema_validator”)
quality_validator = DataQualityValidator(id=”quality_validator”)
security_validator = SecurityValidator(id=”security_validator”)
validation_aggregator = ValidationAggregator(id=”validation_aggregator”)

# Transformation stage (fan-out)
data_normalizer = DataNormalizer(id=”data_normalizer”)
data_enrichment = DataEnrichment(id=”data_enrichment”)
data_aggregator_exec = DataAggregator(id=”data_aggregator”)

# Quality assurance stage (fan-out)
performance_assessor = PerformanceAssessor(id=”performance_assessor”)
accuracy_assessor = AccuracyAssessor(id=”accuracy_assessor”)

# Final processing
final_processor = FinalProcessor(id=”final_processor”)

# Build the workflow with complex fan-in/fan-out patterns
return (
WorkflowBuilder()
.set_start_executor(data_ingestion)
# Fan-out to validation stage
.add_fan_out_edges(data_ingestion, [schema_validator, quality_validator, security_validator])
# Fan-in from validation to aggregator
.add_fan_in_edges([schema_validator, quality_validator, security_validator], validation_aggregator)
# Fan-out to transformation stage
.add_fan_out_edges(validation_aggregator, [data_normalizer, data_enrichment, data_aggregator_exec])
# Fan-in to quality assurance stage (both assessors receive all transformation results)
.add_fan_in_edges([data_normalizer, data_enrichment, data_aggregator_exec], performance_assessor)
.add_fan_in_edges([data_normalizer, data_enrichment, data_aggregator_exec], accuracy_assessor)
# Fan-in to final processor
.add_fan_in_edges([performance_assessor, accuracy_assessor], final_processor)
.build()
)

# Export the workflow for DevUI discovery
workflow = create_complex_workflow()

 

What DevUI offers

• Enables rapid local iteration by letting you spin-up agents/workflows in a browser interface without full deployment.


• Provides visualization of agent workflows and tool calls, giving insight into how messages flow, tools execute, and agents interact. 


• Improves debugging and traceability, showing real-time traces, tool invocation logs, and execution paths that help diagnose issues in complex multi-agent systems. 


• Supports observability alignment with production systems with the tracing/telemetry you explore in DevUI can mirror what you’ll deploy at scale. 


• Facilitates collaboration across teams (developers, architects, stakeholders) because a UI is more accessible than raw logs or CLI output.


• Accelerates prototyping: by allowing you to test agent definitions, workflows, tool integration and memory/state behavior in a sandbox-style UI before moving to production.


• Helps maintain consistency between dev and production by using the same underlying SDK/runtime as the Agent Framework


• Acts as a springboard for architecture review since you can visualize how agents and workflows are structured, identify bottlenecks or tool-dependencies early, which supports the solution architect role you carry.

Agent Framework running locally in VS Code

Why DevUI matters for your work

DevUI provides a developer-friendly interface for debugging and visualizing multi-agent workflows, making it easier to trace conversations, tool calls, and state transitions. This improves observability and accelerates development, reducing friction when building and testing complex agentic systems.

• Faster iteration: Rather than deploying to Azure every time you want to test an agent conversation or workflow path, you can run locally and visually inspect behavior.


• Traceability and debugging: In production-scale agent workflows, you’ll have tools calling APIs, state being passed across threads, human approvals etc. DevUI gives you a trace view that is helpful for identifying points of failure, tool mis-invoke, state mismatch.


• Stakeholder demos: When you need to show business stakeholders how an agent workflow will operate (e.g., for a migration, an onboarding assistant, a multi-agent orchestration for call center automation) a UI is more compelling than shell logs.


• Governance & compliance preparation: Seeing the event sequence, tool calls and state changes helps you design logs/traces/approval gates you’ll need when you shift into production.

Practical insights / tips

• Ensure that your agent definitions, tools, workflows are structured so that DevUI can discover them (e.g., using directory conventions).


• Use DevUI early in your development lifecycle (prototype stage) to validate conversation flows, tool integration, thread/memory behavior — this prevents nasty surprises when scaling.


• When you transition to production, ensure your observability/tracing patterns align with DevUI’s instrumentation so you maintain equivalent visibility (DevUI is good for dev; ops layer may need more enterprise-grade monitoring).


• Remember, DevUI does not replace the operational/governance layer but augments the developer layer.

Wrapping Up

Microsoft’s Agent Framework is a significant evolution for building AI-agent and multi-agent workflows at scale. This offers a unified platform to bridge prototyping and production readiness. The migration story from Semantic Kernel / AutoGen means you can plan a phased transition rather than a full rewrite. And DevUI gives you the developer feedback loop you’ll welcome as you integrate agents into larger systems.

 

Additional Resources

AutoGen to Microsoft Agent Framework Migration Guide | Microsoft Learn

Introducing Microsoft Agent Framework: The Open-Source Engine for Agentic AI Apps | Azure AI Foundry Blog

Semantic Kernel to Microsoft Agent Framework Migration Guide | Microsoft Learn

agent-framework/python/packages/devui at main · microsoft/agent-framework