Five AI Agent Patterns—and When Not to Use Them

This analysis organizes five AI Agent Patterns—and When Not to Use Them into a practical comparison of evidence, decisions and current limits.

Read the evidence below as a decision trail: what changed, why it matters, which trade-offs shaped the result, and where the conclusion still depends on context.

There are 5 chapters in the Microsoft AI Agents 18 course that are design-level textbooks on "How to build an agent" - Design Principles, Tool Use, Planning, Multi-Agent, and Metacognition. Rather than reading them one by one, it is more worthwhile to compare them together: the failure mode of each pattern, when not to use it, and how to match it with other patterns. This article will do just that.

Why these 5 lessons should be read together

Just by looking at each pattern, you will learn "how to use function calling to write tools", "how to use Pydantic for structured planning", and "how to design multi-agent hand-off". But in practice, the more expensive question is not "how to do it" but "should it be done". How tight should the safety boundaries of Tool use be? When is Planning worth spending tokens on re-planning? When is multi-agent overengineering? How deeply reflective is Metacognition? There is no single answer to these true-false questions, and the choice can only be found by comparing the five patterns with each other.

So this article is not about translating the official courses into Chinese - it is about making a selection table of the "applicable/inapplicable/failure modes" of the 5 patterns, and pointing out the Microsoft coursesNo explicit explanationtrade-off.

5 design selection comparison tables

Design	core issues	When to use	When not to use	Main failure modes
Design Principles（L3）	How should Agent interact with people?	This should be done every time when designing agent UX	—(meta-frame, always applicable)	Lack of transparency → User distrust
Tool Use（L4）	Let LLM interact with external systems	Requires dynamic data, execution of programs, and operation of external services	Pure reasoning/text conversion tasks	SQL injection, schema description is unclear → LLM selected the wrong tool
Planning（L7）	Break complex goals into subtasks	Multiple steps and subtasks have dependencies or require routing	Single-step tasks and subtasks can be independently parallelized (just use multi-agent)	The decomposition granularity is too fine and the re-plan token cost is out of control.
Multi-Agent（L8）	Collaboration with multiple professional agents	Large workload, requiring expertise in different fields, requiring fault tolerance	Simple tasks that a single agent can handle	Coordination overhead, state synchronization between agents crashes
Metacognition（L9）	Agent reflects on his decision-making	Scenarios where costly decisions are made and where feedback is available	Low cost/one-time decision (reflect on costs > benefits)	"Reflection" is just a choice of strategies, not a true re-evaluation.

Pattern 2 — Planning: The cost of dismantling and re-planning

The core of Planning is "breaking complex goals into subtasks." The official Travel Agent example is split into 5 subtasks: FlightBooking / HotelBooking / CarRental / ActivitiesBooking / DestinationInfo, each subtask has one assigned_agent Fields, using Pydantic BaseModel Force LLM to output structured JSON, and then route it to the corresponding agent for execution.

The implicit design decision in this example is "structured output for reliability" - rather than letting LLM freely generate natural language such as "I recommend booking flights first and then booking hotels", forcing JSON schema allows the downstream agent to parse directly without having to do another round of NLU. The cost is that LLM has to remember the schema structure and the prompt becomes longer. This price is worth it when the number of subtasks is stable, but it will get stuck when the subtasks change dynamically (different every time).

The more expensive judgment question is Iterative Planning — When the result returned by the first sub-task (such as booking a flight ticket) is not as expected, should the entire set be re-planned? The official example directly demonstrates re-calling the planner and passing in the previous plan as context. But the courseDidn't say it clearlyThe problem is: every time you re-plan, you have to re-run a planner LLM call, which is not cheap. In practice, "re-plan trigger conditions" should be set - for example, re-planning will only be triggered when a subtask fails more than N times or the budget exceeds X%; otherwise, just stick to the original plan and the results will be easy to handle.

When not to use Planning? Single-step tasks (solved in one tool call), subtasks are independent and can be parallelized (just throw multi-agent group chat, no planner required). The value of Planning is "there are dependencies or sequences between subtasks" - a rigid planner without dependencies is over-designed.

Pattern 3 — Multi-Agent: Coordination mechanism determines success or failure

The official description of Multi-Agent is that there are three benefits: specialization (each agent does one thing, so there is no confusion), scalability (you don’t have to change the existing ones if you want to expand and add agents), and fault tolerance (if one agent fails, the others will continue). But what’s more worth stopping to watch in the course isList of 16 agents for chargeback scenarios — 5 ones specific to the refund process (Customer / Seller / Payment / Resolution / Compliance) + 11 common across processes (Shipping / Feedback / Escalation / Notification / Analytics / Audit / Reporting / Knowledge / Security / Quality).

The implicit message of this list:The number of agents in a real multi-agent system is much greater than intuitively imagined.. When designing for the first time, it is easy to only see the "core 5" and miss the 11 that are common across processes - and those 11 are the real source of maintenance cost for multi-agent.

3 common patterns:

Group Chat: All agents take turns speaking in the same conversation, suitable for scenarios that require negotiation and discussion (such as collaborative recommendation). Cost: Long dialogue and high token.
Hand-off: Clear handover between agents, suitable for scenarios with clear order such as workflow / customer support. Cost: The handover rules must be clearly defined, otherwise they will get stuck.
Collaborative Filtering: Multiple professional agents evaluate individually and summarize the results to the user. Suitable for decisions that require different perspectives (for example, stock recommendation combining industry/technology/fundamental agents).

Judgment criteria for which pattern to choose:Watch the information flow. Linear order → hand-off; divergent discussion → group chat; independent evaluation and then consolidation → collaborative filtering. Mixed use will make visibility extremely poor - and visibility itself is a hard indicator of multi-agent (the official text requires logging, monitoring, visualization, and performance metrics to be done).

When not to use Multi-Agent? When a single agent + multiple tools can solve the problem, don't dismantle the multi-agent. The cost of adding an agent is not just code writing, but also coordination overhead, state synchronization, and debugging complexity, all of which increase exponentially.

Pattern 4 — Metacognition: Reflection on Truth and Falsehood

This lesson is most easily misunderstood. At first glance, "agent reflects on its own decision-making" sounds very sophisticated, but the official HotelRecommendationAgent exemplary reflect_on_choice What the method does is:

use cheapest The strategy recommended a hotel
Check user feedback (price < 100 or quality < 7 → “bad”)
If bad, change the strategy from cheapest switch to highest_quality, Recommend again

Is this a reflection? Forget it - butReflection on "Choose one between two hardcoded strategies". It will not generate new strategies, it will not question "why only these two strategies are available", and it will not reconsider whether the criterion of "quality < 7" is correct. Microsoft's original text also said "simple form of metacognition" - the word "simple" is worthy of being circled.

Really in-depth reflection (freely generating new strategies, questioning meta assumptions, re-evaluating evaluation criteria) requires re-running LLM calls every time, and the token cost is high. Therefore, the practical judgment is not "whether to do metacognition", but "reflection on which level to achieve":

Layer 0: No reflection — One-time decision-making, low-cost scenarios
Layer 1: Choose one of two strategies(Such as official example) - medium decision-making, predefined strategy pool
Layer 2: feedback reordering(Corrective RAG) - Knowledge retrieval scenario, requiring continuous correction
Layer 3: Freely generate new strategies — High-cost decisions, only used in a few important scenarios

When not to use Metacognition? Low-cost or one-time decisions (token cost of reflection > improved benefits), scenarios without reliable feedback signals (there is no way to judge "whether the last choice was good or not" and there is no way to reflect).

The role of Design Principles over the 4 patterns

The Design Principles of Lesson 3 is not the fifth pattern, it isUX constraints applied to the previous 4 patterns. 3 guidelines:

Transparency: Tell the user this is AI, what it has done, and how to give feedback
Control: Allows users to customize, delete history, and control agent switches
Consistency: Consistent UX across devices/modalities, using standard icons, and reducing cognitive load

The impact of these three items on the four patterns: Tool Use needs to be transparent (let users know which APIs are called); Planning needs transparency (allowing users to see the disassembly results and intervene); Multi-Agent needs visibility (not only internal debugging, users should know which agent is interacting with him); Metacognition needs control (allowing users to override or turn off the reflection loop).

A more core principle:"Embrace uncertainty but establish trust" — Uncertainty is a characteristic of the agent, not a bug; but trust must be established through transparency + user control. This principle corresponds to "Don't try to package the agent as "100% reliable"". That direction is a dead end (LLM is essentially probabilistic); what should be done is to let users clearly know what the agent is doing and can intervene at any time.

My selection judgment framework

Integrate the 5 patterns into a judgment process:

First question: Does this task really require an agent? Pure reasoning/text conversion → Direct LLM call, no agent/tool required.
Need → Tool Use is the basis. When designing, first classify Knowledge tool vs Action tool, Action tool adopts read-only role / strict schema.
The task is complex (multiple steps with dependencies) → Add Planning. However, the re-plan trigger conditions must be clearly defined and do not allow LLM to freely re-plan and burn tokens.
Requires expertise in different areas or a large amount of parallel work → Add Multi-Agent. First use the three patterns of hand-off / group chat / collaborative filtering to match the information flow type, and then decide. At the same time, logging/monitoring is designed in, not as an afterthought.
The decision-making cost is high and there is feedback signal → Add Metacognition. But start with layer 1 (choose one of two strategies), and don’t go to layer 3 right away.
Full set of Design Principles：Transparency allows users to see, control allows users to intervene, and consistency prevents users from having to relearn the interface.

The reverse application of this process is more worth looking at:"I already have multi-agent + planner + metacognition, but the agent is still not easy to use." There is a high probability that I missed Step 1. — The task does not require this architecture at all and can be solved directly by calling LLM. The most common over-engineering in the AI field is to shoehorn tasks that do not require an agent into the agent framework.

Pattern 1 — Tool Use: Choice of Security Boundary and Framework Abstraction

The core of Tool Use is to throw the schema description (name, purpose, parameters) of the function to LLM, let it choose which tool to call, return the tool name + arguments, execute it by your program code, and then throw the result back to LLM to generate the final answer. This loop can be written by hand, but each time it has to deal with message splicing, tool_call_id correspondence, error handling, and state accumulation - so Microsoft Agent Framework uses @tool The decorator removes this layer and writes a Python function to automatically generate the schema and take over the entire loop.

The most worthwhile point in the course to stop at is Azure AI Agent Service divides tools into two categories: Knowledge Tools (Bing Grounding, File Search, Azure AI Search) vs Action Tools (Function Calling, Code Interpreter, OpenAPI, Azure Functions). This division is not just an organizational convenience - it implies a design judgment: the security model of "expanding the boundaries of knowledge" is completely different from that of "performing external actions". Even if the Knowledge tool is misused by LLM, it will at most return irrelevant information; if the Action tool is misused, it may actually send an email. By pre-classifying the tool into these two categories during design, the workload of security review will be reduced by half.

The security trade-off clearly stated by the official: LLM dynamically generating SQL has the risk of injection, but an effective mitigation is to set the database role to read-only (PostgreSQL/Azure SQL to SELECT role). This discipline is easier to implement than imagined, but many teams skip it - especially in the early prototype stage with the mentality of "let it run first".

whenDon'tTool Use? Pure reasoning tasks (such as classifying a paragraph into 5 categories), pure text conversion (translation, summarization) - these tasks do not require external interaction, adding tools will only increase schema overhead and LLM selection anxiety. Tool is the "agent's hand", not the "agent's brain".

Practical questions and boundaries

Do you have to use all 5 patterns?

Absolutely not. Most practical agents only need Tool Use (the most basic) + Design Principles (UX constraints). Planning / Multi-Agent / Metacognition are advanced - adding them when the task is not complex is over-engineering. Judgment criteria: Each time you add a pattern, can you tell a specific scenario where "it will break without it"? If you can't tell, don't add it.

What is the division of labor between Microsoft Agent Framework and Azure AI Agent Service?

MAF is an SDK that allows developers to quickly prototype and iterate, including @tool decorator and other abstractions. Azure AI Agent Service is a managed runtime, tool calling loop, conversation state, security model server-side hosting, and suitable for production deployment. The corresponding workflow is MAF development → Azure AI Agent Service deployment. If you only need prototype but not production, you can use MAF without opening an Azure subscription.

Are these 5 patterns consistent with the concept of the same name in LangChain/CrewAI?

The conceptual level is roughly the same - LangChain also has tool use, planning, and multi-agent; CrewAI is strong in multi-agent orchestration. The difference lies in the implementation layer: Microsoft's set is fully tied to the Azure stack and structured output uses Pydantic + AzureAIProjectAgentProvider; LangChain uses LangChain expression language; CrewAI uses Role/Task/Crew abstraction. Concepts are transferable, but code is not.

Original source: Microsoft AI Agents for Beginners — Lesson 3、Lesson 4、Lesson 7、Lesson 8、Lesson 9

What to take away

The article's value is in the evidence and trade-offs behind five AI Agent Patterns—and When Not to Use Them, not in treating the conclusion as universal.