The frameworks, and what the exam expects

The syllabus names four frameworks, and the audience profile names them again —
which is unusually explicit for a Microsoft exam, and worth taking at face value.

The four

Microsoft Agent Framework. The direct successor to Semantic Kernel and
AutoGen, built by the same teams. Microsoft's own description: it "combines
AutoGen's simple abstractions for single- and multi-agent patterns with Semantic
Kernel's enterprise-grade features such as session-based state management, type
safety, filters, telemetry, and extensive model and embedding support", and adds
graph-based workflows on top. Migration guides exist from both predecessors.

LangChain and LangGraph. Named in the syllabus and in the audience profile.
They run on Foundry as hosted agents, and Foundry's tracing supports them
natively — so choosing them does not put you outside the platform's observability.

Hugging Face Transformers. Named explicitly for "advanced multi-agent
capabilities" — open-weight models and local pipelines.

The framing worth carrying: the framework you write in does not change the
deployment shape. All of this runs as a hosted agent.

Agent Framework's four primary areas

Agents. Individual agents that use models, call tools and MCP servers, and
generate responses. Supported providers include Microsoft Foundry, Anthropic, Azure
OpenAI, OpenAI and Ollama.

Harness Agent. An opinionated agent with batteries-included capabilities for
long, multi-step tasks — planning and todo tracking, context compaction, file
access and memory, don't-ask-again tool approval, and observability.

That one deserves attention. It is the framework packaging up several things this
guide treats as separate problems — compaction, memory, approval — into one
component aimed at exactly the long-running case where they all bite at once.

Workflows. Functional and graph-based, connecting agents and functions through
explicit execution paths.

Integrations. Model providers, agent services, tools, context providers,
middleware, evaluation services, UI frameworks.

Language parity is not equal, and it is testable

Python has the most complete surface. FIDES, the information-flow control
system, is Python-only.

C# / .NET has full framework support.

Go is in public preview, and Microsoft names what is missing: "Declarative
agents, RAG, CodeAct, and functional workflows are not yet available."

So "which language" is a capability question here, not a preference. If a scenario
needs declarative agents or RAG in Go today, the honest answer is that it is not
there yet.

When to use an agent at all

Agent Framework's own guidance is refreshingly blunt, and it is the same argument as
card 1:

"If you can write a function to handle the task, do that instead of using an AI
agent."

Use an agent when the task is open-ended or conversational and needs autonomous tool
use. Use a workflow when the process has well-defined steps and you need explicit
control over execution order.

The trap

Semantic Kernel and AutoGen still appear all over current documentation, and both
are perfectly real technologies that work.

They are wrong answers not because they are broken but because Agent Framework is
the successor. Which sets up a specific kind of question: if two options are the
same concept under two names, neither can be the answer, and you are being asked
whether you know they are the same thing.