Microsoft's AI Agents for Beginners: of 18 lessons, FDEs should study five closely

The September 2025 version of Microsoft’s AI Agents for Beginners course had 12 lessons; the repo now lists 18. The repo’s README also says plainly that each lesson stands alone, so you can start wherever you like. For an FDE that detail matters more than the number 18: you do not have time to work through all of it, and you do not need to.

If you are about to take on an agent project at a customer, or want to move from software engineering into FDE work, the course can give you the vocabulary and a checklist in a few evenings. The quality is uneven, though. Some lessons teach skills that transfer to any stack; others are, in effect, Microsoft product documentation.

The course is not the one you may have heard about

The course lives in the microsoft/ai-agents-for-beginners repo on GitHub and is MIT-licensed. KDnuggets covered the September 2025 version: 12 lessons, free, running on Azure AI Foundry, GitHub Models, Semantic Kernel and AutoGen. The current version has moved to Microsoft Agent Framework and added a number of new lessons.

The new lessons sit at the end of the course: agent protocols, context engineering, memory, computer-use agents, deployment, local agents and security. One thing to know up front: running the sample code requires a Microsoft Foundry (Azure) account. If your customer runs a different stack, learn the ideas and rewrite the code yourself.

Lesson 1 teaches you when not to use an agent

Lesson 1 defines an agent as a system that lets an LLM actually get things done by giving it tools and knowledge. The more valuable part for an FDE is the selection criterion: according to the lesson, agents suit open-ended problems where the steps to a solution cannot be programmed in advance.

Picture a customer who wants “an AI agent to process invoices”. If the process is always to read the PDF, extract four fields, match them against the purchase order and write the result into the ERP, the steps are fixed. A pipeline with a single LLM call will be cheaper and easier to debug. An agent earns its cost only when each faulty invoice needs a different line of investigation.

So in the first discovery session, ask the customer: “Can these steps be programmed in advance?” The answer settles the project’s scope before you promise anything.

Lesson 10 is the main reason to open the repo

The production lesson is the part FDEs will use most. It treats observability as a required capability rather than a nice extra, and covers traces and spans via OpenTelemetry, offline and online evaluation, and cost control. The lesson explains why evaluation must be continuous: agents are often non-deterministic.

The practical consequence is that five successful test runs prove nothing. You need a fixed set of questions, rerun after every prompt change or model swap, with scores compared across runs. Customers will trust that number more than any demo.

The lesson also recommends routing by model size: send simple queries to a small, fast model and reserve the large model for complex reasoning tasks.

Picture 1,000 requests a day, 800 of which are order-status lookups. Route those 800 to a small model and you pay large-model prices only for the 200 requests that really need it.

Three lessons for your days on site

Lesson 6, on trustworthy agents, lists the threats: instruction hijacking, access to critical systems, overloading systems, knowledge-base poisoning and cascading errors.

The core principle is that an agent should have access to a system only when it truly needs it. In an enterprise setting, a customer-support agent, for example, should be able to read the CRM but not write to it.

Lesson 11 explains MCP, an open standard for applications to supply context and tools to LLMs, along with A2A and NLWeb. For an FDE, MCP offers a standard way to bring context and tools from the customer’s systems into the agent.

Lesson 12 separates context engineering from prompt engineering: the goal is to make sure the agent has exactly the information it needs. The lesson names four failure modes, poisoning, distraction, confusion and clash, with ways to mitigate each. When an agent gives a wrong answer, having a precise name for the failure makes diagnosis much faster.

What to skim, and in what order to study

Lesson 2 compares Microsoft Agent Framework, a code-first SDK, with Foundry Agent Service, the platform for deploying agents on Microsoft Foundry. If your customer is on Azure, this lesson is essential. If not, a skim to grasp how an SDK differs from a deployment platform is enough.

A sensible order for FDEs is 1, 10, 6, 11, 12. It runs from scoping to operations, security and integration, and only then to answer quality. Leave the remaining lessons, such as memory or computer-use agents, until a project actually needs them.

As for job hunting, understanding the concepts will not make your CV stand out. What will is a small agent with tracing, a rerunnable eval suite and documentation that spells out its access rights.

When reading job descriptions, look for the words “observability”, “evaluation” and “MCP”. If they appear, lessons 10 and 11 are where to revise before the interview.

Most of the course teaches you how to make an agent work. The five lessons above teach you how to build an agent a customer will dare to put into production.