A developer’s guide to the Microsoft Agent Framework

By Arafat Tehsin

If you’ve been building with LLMs for more than a few weeks, you’ve probably discovered there’s a big gap between a demo that impresses in a meeting and a system that quietly runs every day in production. The difference is not a bigger prompt. It’s orchestration, guardrails, approvals, observability and an opinionated way to compose tools with model reasoning. That’s exactly the problem space these agent frameworks are designed to solve.

But Microsoft has a problem. A problem of too many useful, enterprise-ready offerings for creating agents. From Semantic Kernel to AutoGen, Microsoft 365 Agent Framework, Microsoft AI Extensions, Teams AI Toolkit and Copilot Studio, it has already been a challenge for many architects to decide which product is suited for which task. And let’s not forget the classic Bot Framework. Just as we were tangled in this web of frameworks, another one popped up, Agent Framework.

This time (well, for now) the product group has not added a new confusion rather a consolidation point. Agent Framework is that point. At its core, the Agent Framework brings together the best of Semantic Kernel and AutoGen into one consistent developer experience. You get Semantic Kernel’s orchestration patterns and production-minded tooling, plus AutoGen’s multi-agent chat ergonomics and streaming transparency, without having to choose or stitch them yourself.

I know you must be thinking as, what about our existing implementation? Do not worry, I have addressed this concern at the end of this post.

Semantic Kernel + AutoGen, together

Practically, this means that you’ve got one mental model for agents and tools across languages. It delivers a single contract for agents and tools and bakes in guardrails from day zero. One runway from prototype to production.

Here are some of the benefits you will start seeing immediately:

Typed tool calls: Functions map to tools with explicit inputs/outputs you own. Safer than free-form text and friendly for unit tests.
Planning + execution loops: Built-in patterns for think → act → observe that you can keep simple or extend with planners.
Guardrails + approvals: First-class approval flows for sensitive actions (e.g., “release payment” > threshold). Deny/approve becomes a standard path, not a bolt-on.
Memory + grounding: Add retrieval, vectors, or structured data when needed; keep it lean when not.
Observability: Hooks and traces for “what did the agent do and why”, essential for debugging and postmortems.
Developer experience: Sample-rich, works in Visual Studio (and Code) and consistent across .NET and Python. Swap models/providers without re-architecting.

Out of the box you get orchestration primitives, tool adapters, approval workflows and alignment with Semantic Kernel concepts. The intention isn’t lock-in. You can ship quickly, then customise resilience, telemetry and providers as you harden.

Examples

1) Getting Started – Single Agent + Tool

Goal: check an invoice status and report it.

				
					var openAiClient = new AzureOpenAIClient(new Uri(endpoint), new AzureCliCredential());
var chatClient = openAiClient.GetChatClient("gpt-4o");

// Optional: register a typed tool the agent can call
static string GetInvoiceStatus(string invoiceId) =>
    System.Text.Json.JsonSerializer.Serialize(new { invoiceId, status = "Pending" });

var agent = chatClient.CreateAIAgent(
    instructions: "You are a spend-control assistant. Use tools when helpful.",
    name: "SpendAgent",
    tools: new[] { AIFunctionFactory.Create((Func<string, string>)GetInvoiceStatus) }
);

var result = await agent.RespondAsync("What is the status of INV-1002?");
Console.WriteLine(result);

That’s it, no custom wrapper required.

				
					# Python sketch: same idea (pseudo)
agent = chat_client.create_ai_agent(
  instructions="You are a spend-control assistant. Use tools when helpful.",
  name="SpendAgent",
  tools=[get_invoice_status]
)
result = agent.respond("What is the status of INV-1002?")
print(result)

2) Advanced Orchestration – Planner + Guardrails + Multi-Tools

Goal: if the amount > threshold, request approval; else pay. Denials flip status to Rejected, approvals flip to Paid.

				
					// .NET sketch: declarative policy + functions
var plan = new PaymentPlan(threshold: 1000)
    .WithTools(GetInvoiceStatus, RequestApproval, ReleasePayment);
var outcome = await agent.RunAsync(plan, invoiceId: "INV-1002");

I’ve got a complete post with a sample planned for Human in the Loop scenario so above will be easier for you to understand at some later stage.

The framework makes it straightforward to inject approval requirements, capture the user decision, and resume execution without a custom state machine. Observability hooks let you trace each function call and decision, which is gold when you’re debugging that one stubborn production case.

Basic Architecture (at a glance)

The orchestrator brokers prompts, plans, and tool calls; the planner decomposes goals; tools do real work (APIs, DB, retrieval). The feedback path models iterative refinement. You can dial this loop down to a single step for deterministic flows or let it reason over multiple hops for harder tasks.

Think of it as a relay. Orchestrator brokers, Planner decomposes, Tools do the real work. Simple enough for a single step, flexible enough for multi-hop reasoning.

Introducing AgentFramework 101 notebook

I’m a firm believer in learning by doing; therefore, I have created a comprehensive notebook for you to try it out. This notebook encompasses everything from agent creation to tool integration, structured output, persistent conversation, MCP, and more. It’s now published to my repo!

What You’ll Learn in the Notebook

This hands-on notebook guides you through building and experimenting with Microsoft Agent Framework from scratch. It covers;

Key concepts

Single-agent and multi-agent workflows with the context across multiple conversations
Tool calling and function integration including the external API calls
Human in the loop, approval mechanisms for sensitive operations (that’s my favorite)
Structured output with type safety necessary for the complex analysis
State persistence and restoration including the loop-based conversations
Multimodal input processing for parking analysis
Agent composition patterns and using them as a MCP or function tool
Custom memory providers including the memory isolation
Multi-user personalisation at scale

Real-world applications use-cases

Social media content generation
Flight tracking and travel planning
Budget management and trip planning
Medical appointment scheduling
Parking regulation interpretation
Visa requirement checking
Personalised meal planning with dietary restrictions

Practical notes (what I watch for)

Keep tools small and composable. It’s easier to reason about three tiny tools than one “super function”.
Separate policy from capability. Thresholds, approvals, and constraints should be easy to tweak without changing tool code.
Favor typed arguments and results. It speeds up adoption and reduces hidden prompt failures.
Log every tool call. You’ll thank yourself when a user asks, “why did this get paid?”
Start with a simple loop; add planners / reasoning loop when the task genuinely needs them.

The existing state

Like many others, I also asked the team what’s happening with Semantic Kernel. Will it continue to be supported and what should we use for new agent workflows?

The answer we received is that while Semantic Kernel will remain supported, all new investments are being directed toward the latest Agent Framework. This means if you already have production workloads built on Semantic Kernel, you’re safe. But if you’re starting something new today, even though Agent Framework is still in public preview, I’d strongly recommend looking at it.

The good news is that the learning curve isn’t steep. If you go through the docs and check out the samples in the repo, you’ll find it straightforward. That also suggests migration from existing Semantic Kernel and AutoGen systems is relatively smooth. Check out the solid migration guides on Semantic Kernel and AutoGen to ensure your teams don’t run into unnecessary roadblocks.

To sum it up, modern apps need autonomous help, but not a black box. The Agent Framework offers a structured way to combine model reasoning (think), planning (decide), and tool use (act) so assistants behave predictably under real-world constraints. Where an SDK exposes raw building blocks, a framework encodes the proven practices teams keep re-creating: clear capability boundaries, typed tools, controlled invocation, and traceable decisions.

Until next time.