Complete Guide to AI Agent Architecture Patterns: From Three Pillars to Multi-Agent Systematic Navigation

🌏 中文版

You open the third Agent tutorial and realize it is talking about something on a completely different level from the previous two.

One covers how to write prompts, another covers the JSON schema for tool calling, and a third discusses multi-agent topological structures. They are all titled “AI Agent Tutorial,” yet they have almost no overlap. After reading all three, your understanding of AI Agents is actually more fragmented than before.

This is the state of the AI Agent field in 2026: the tech stack is too deep, there are too many concepts, too many layers, and it is easy to get lost.

From Prompt Engineering to Context Engineering to Harness Engineering, from RAG to Agent Memory, from Tool Calling to MCP, from Single Agent to Multi-Agent — each one is a major topic with its own frameworks, best practices, and pitfalls. What makes it worse is that they have complex interdependencies, yet few people have drawn this dependency graph.

This article is not another deep-dive tutorial. It is a map — a panoramic view of the entire AI Agent tech stack, showing you what each topic is, why it matters, how it relates to the others, and where to go deeper.

How to Use This Guide

Each section gives you a high-level understanding of a topic in 2-4 paragraphs — enough to know what it is, why it matters, and how it relates to other topics. Then it links to a dedicated deep-dive article for you to explore further as needed.

You do not need to read from top to bottom. Jump to the section you need based on your goals. At the end, there are four recommended reading paths for different backgrounds and objectives.

This guide covers 12 topics, links to 14 dedicated articles, and takes about 15 minutes to read. Each deep-dive article requires 10-20 minutes.

Start with the big picture:

                        ┌─────────────────────────────┐
                        │   AI Agent Architecture      │
                        │       Panoramic View         │
                        └──────────────┬──────────────┘
                                       │
              ┌────────────────────────┼────────────────────────┐
              │                        │                        │
    ┌─────────▼─────────┐   ┌─────────▼─────────┐   ┌─────────▼─────────┐
    │  Context Pillar    │   │  Cognition Pillar  │   │  Action Pillar    │
    │                    │   │                    │   │                    │
    │  • Context Eng.    │   │  • Prompt Eng.     │   │  • Tool Calling    │
    │  • RAG / Memory    │   │  • Reasoning       │   │  • MCP Protocol    │
    │  • State Mgmt      │   │  • Planning        │   │  • Code Execution  │
    └─────────┬──────────┘   └─────────┬──────────┘   └─────────┬──────────┘
              │                        │                        │
              └────────────────────────┼────────────────────────┘
                                       │
                        ┌──────────────▼──────────────┐
                        │      Harness Control Layer   │
                        │                              │
                        │  • Tool Registry             │
                        │  • Guard System              │
                        │  • Checkpoint-Resume         │
                        │  • Observability             │
                        └──────────────┬───────────────┘
                                       │
              ┌────────────────────────┼────────────────────────┐
              │                        │                        │
    ┌─────────▼─────────┐   ┌─────────▼─────────┐   ┌─────────▼─────────┐
    │  Single Agent      │   │  Multi-Agent      │   │  Production       │
    │                    │   │                    │   │                    │
    │  • ReAct Loop      │   │  • 8 Patterns     │   │  • Chatbot Dev    │
    │  • LangGraph       │   │  • Coordinator    │   │  • Guardrails     │
    │  • Plan-Execute    │   │  • Hierarchical   │   │  • Observability  │
    └────────────────────┘   └────────────────────┘   └────────────────────┘

    Evolution Path: Prompt Engineering → Context Engineering → Harness Engineering

The core message of this diagram: the Agent’s Three Pillars (Context/Cognition/Action) form the foundation, the Harness is the middle control layer, and the upper layer contains various architecture patterns and production requirements. Every dedicated article maps to a position on this diagram.

Quick Navigation:

Let us walk through them one by one.

1. Agent Three Pillars: Context, Cognition, Action

Every AI Agent can be decomposed into three core capabilities:

• Context: What information is available to the Agent when making decisions. This includes the system prompt, conversation history, RAG retrieval results, tool return values, and memory systems.
• Cognition: How the Agent thinks and reasons. This includes the LLM’s reasoning capabilities, chain-of-thought, planning, and self-reflection.
• Action: What the Agent can do to the external world. This includes tool calling, code execution, API calls, and file operations.

The value of the Three Pillars model is this: when your Agent performs poorly, you can precisely locate which layer the problem is in. If the Agent calls the wrong tool, the problem might be in Context (it was not given enough information to choose the right tool) rather than Action (the tool itself works fine). If the Agent’s reasoning process is correct but it gives the wrong final answer, the problem might be in Context (it retrieved the wrong documents) rather than Cognition.

The three pillars are interdependent: good Context makes Cognition more accurate, good Cognition makes Action more precise, and Action results feed back to enrich Context. Understanding this cycle is the foundation for understanding all subsequent topics.

Context ──→ Cognition ──→ Action
   ▲                         │
   └─────────────────────────┘
        Action results feed back as new Context

Every subsequent topic in this guide maps to one of the pillars: Context Engineering and Agent Memory strengthen the Context pillar, Prompt Engineering strengthens the Cognition pillar, and MCP and Tool Calling strengthen the Action pillar. Harness Engineering is the control layer spanning all three.

-> Deep-dive article: The Three Core Pillars of AI Agents: Context, Cognition, Action

2. Three-Stage Evolution of AI Engineering: Prompt -> Context -> Harness

The methodology for AI application development has undergone three fundamental shifts in three years:

Stage One: Prompt Engineering (2023). The focus was on writing good instructions. Few-shot, Chain-of-Thought, role-playing — all techniques revolved around “a single prompt.” The mental model of this era: the model is fixed, and the only thing you can adjust is the input text.

Stage Two: Context Engineering (2025). Shopify’s CEO and Andrej Karpathy coined this term simultaneously, and the industry instantly resonated. The focus shifted from “how to write instructions” to “dynamically assembling the right information environment at runtime.” RAG, memory, and state management are all means of context engineering. What you are designing is no longer a single prompt, but a system.

Stage Three: Harness Engineering (2026). A concept driven by Anthropic and Phil Schmid: there needs to be a control layer (harness) between the LLM and the application, responsible for tool registration, permission management, state persistence, error recovery, and observability. What you are building is no longer a chatbot, but reliable infrastructure.

Each stage does not replace the previous one — it subsumes it. Prompt engineering is now a subset of context engineering, and context engineering is now a subset of harness engineering.

2023                  2025                  2026
┌──────────┐    ┌──────────────┐    ┌────────────────────┐
│  Prompt  │ ⊂  │   Context    │ ⊂  │     Harness        │
│  Eng.    │    │   Eng.       │    │     Eng.           │
│          │    │              │    │                    │
│ Tune     │    │ Design the   │    │ Build control      │
│ wording  │    │ info env.    │    │ infrastructure     │
└──────────┘    └──────────────┘    └────────────────────┘

Understanding the evolution of these three stages is crucial because it determines your mental model. If you are still at Stage One, you will think “the Agent is not working because the prompt is poorly written.” At Stage Two, you will realize “most problems are in the context.” At Stage Three, you will discover “even with correct context, an Agent without a harness is still unreliable in production.”

-> Deep-dive article: From Prompt to Harness: The Three Evolutions of AI Engineering

3. Context Engineering

If you had to pick one topic in this guide to understand first, it would be Context Engineering.

The core insight is simple: most Agent failures are context failures, not model failures. Your Agent is not dumb — it is blind. It does not have enough information at the moment of decision. Switching to a stronger model will not solve the problem; giving it the right information will.

Context Engineering has four core strategies:

• Write: Write information into the context (system prompt, few-shot examples, scratchpad)
• Select: Dynamically choose what to put into the context (RAG retrieval, tool selection, memory recall)
• Compress: Compress information to fit the context window (summarization, truncation, importance ranking)
• Isolate: Isolate context for different tasks (sub-agents, parallel processing, scoped context)

LangChain CEO Harrison Chase’s diagnostic principle: “If your agent is performing inconsistently, ask one question — does the LLM have enough information and tools at the moment of this decision? Nine times out of ten, the answer is no.”

Master these four strategies and you have the biggest lever for Agent quality. Before you go researching fancier architectures, make sure your context is right.

-> Deep-dive article: Context Engineering: Why Your AI Agent’s Problem Is Information, Not the Model

4. Prompt Engineering

Has Context Engineering replaced Prompt Engineering? No. It has merely repositioned Prompt Engineering’s role: it is no longer “everything,” but it is still foundational.

A good system prompt structure typically includes: role definition, task description, output format, constraints, and a few examples. But in production systems, the system prompt is just a small part of the context window — the rest is occupied by RAG results, tool return values, and conversation history.

The value of Prompt Engineering in 2026 lies mainly in two areas: first, iteration methodology (how to systematically improve prompts rather than randomly tweaking wording), and second, prompt design for RAG scenarios (how to write system prompts that properly guide the model to use retrieved context).

An often-overlooked point: Prompt Engineering plays a different role in Agent systems than in chatbots. A chatbot’s system prompt is “set once, used long-term.” But an Agent’s prompt is often dynamically assembled — based on the current task phase, available tools, and already-gathered context, the system prompt content changes. This is where Prompt Engineering and Context Engineering intersect.

Another common mistake is putting too many instructions in the prompt. When your system prompt exceeds 2000 words, the LLM’s compliance with later instructions drops noticeably. At that point, you do not need a longer prompt but a better context architecture — move some instructions into tool descriptions, into few-shot examples, or load them dynamically based on the task phase.

-> Deep-dive articles:

• Prompt Engineering in Practice: Iteration Methodology, Common Mistakes, and Few-shot Optimization
• RAG Prompt Engineering: How to Design System Prompts and Context

5. Harness Engineering

If the LLM is the engine, the Harness is the entire car — the chassis, brakes, dashboard, and airbags.

The Harness is the control layer between the LLM and the application. It is responsible for:

• Tool Registry: Managing which tools the Agent can use, including permissions and rate limits for each tool
• Guard System: Adding a validation layer between LLM output and tool execution to prevent hallucinations or dangerous operations
• Checkpoint-Resume: State persistence and breakpoint recovery for long-running tasks
• Error Recovery: Fallback strategies and retry mechanisms when tool calls fail

Anthropic’s Claude Code is one of the most mature harness implementations today — it demonstrates how an Agent can work like an engineer: read code, make plans, execute, verify, and roll back. Phil Schmid (formerly of Hugging Face) defined harness design principles and standard components at a more abstract level.

Harness Engineering is the most important AI engineering topic of 2026 because it directly determines whether an Agent is reliable in production. An Agent without a harness is like a car without brakes — it can drive happily in an empty parking lot, but it is a disaster on the road.

A good harness design principle: the LLM decides what to do; the harness decides how to do it safely. The LLM says “I want to delete this file,” and the harness checks whether this operation is within the allowed scope, whether human review is required, and whether there is a rollback mechanism. This separation allows you to upgrade the LLM without rewriting the safety logic.

-> Deep-dive articles:

• Anthropic’s Harness Design: Making AI Agents Work Like Engineers
• Phil Schmid: Why Agent Harness Is the Most Important Thing in 2026
• Harness Engineering Advanced Patterns: Tool Registry, Guard System, and Checkpoint-Resume

6. Multi-Agent Design Patterns

When a single Agent is not enough, you need multiple Agents to collaborate. Google systematically organized eight Multi-Agent design patterns in their 2025 Agent white paper:

Which pattern to choose depends on your task structure. Most production systems use Coordinator or Sequential because they are the easiest to understand and debug. Hierarchical and Composite are only worth introducing when task complexity is genuinely high.

A common mistake is introducing multi-agent too early: if your single Agent is not yet well-tuned, adding more Agents will only make problems harder to debug. Get your single Agent stable first, then consider splitting.

When should you split into multi-agent? There are several signals:

1. Context window is not large enough: A single Agent needs too much background information to fit in one context window
2. Different expertise is needed: One Agent expected to be proficient in both writing code and UI design is better split into two specialized Agents
3. Parallel processing is needed: Multiple independent subtasks can be processed simultaneously
4. Checks and balances are needed: The Generator-Critic pattern lets one Agent check another Agent’s work

If none of the above apply, a single agent is usually the better choice — simpler, easier to debug, lower latency.

-> Deep-dive article: Google’s Eight Multi-Agent Design Patterns

7. LangGraph Workflows

LangGraph is an Agent workflow framework from the LangChain team, with a core philosophy: use graph structures to define Agent control flow.

Traditional Agent frameworks (like LangChain’s AgentExecutor) wrap the Agent in a while loop, letting the LLM decide what to do at each step. LangGraph is different — it requires you to explicitly define nodes and edges, turning the Agent’s behavior into a directed graph.

This brings several benefits:

• Predictability: You can see the Agent’s control flow rather than relying entirely on the LLM’s improvisation
• Typed State: Every node shares a typed state object, preventing information loss during transitions
• Human-in-the-Loop: Human review breakpoints can be added at any node in the graph
• Persistence: Built-in checkpointing enables pausing and resuming long-running tasks

LangGraph is particularly suited for scenarios requiring “structured freedom” — the Agent follows a fixed process in some steps and makes autonomous decisions in others.

              ┌─────────┐
              │  Start  │
              └────┬────┘
                   │
              ┌────▼────┐     ┌───────────┐
              │ Retrieve │────▶│  Grade    │
              └─────────┘     └─────┬─────┘
                                    │
                        ┌───────────┼───────────┐
                        │ relevant  │           │ not relevant
                   ┌────▼────┐           ┌─────▼─────┐
                   │ Generate │           │ Re-query  │
                   └────┬────┘           └───────────┘
                        │
                   ┌────▼────┐
                   │  End    │
                   └─────────┘

Above is a simplified Corrective RAG graph — a typical LangGraph use case. Each box is a node, arrows are edges, and branching logic is determined by conditional edges. The overall flow is a deterministic framework, but each node internally can contain non-deterministic LLM calls.

LangGraph and the Multi-Agent design patterns mentioned earlier are not mutually exclusive — LangGraph is an implementation-level framework, while Multi-Agent patterns are design-level concepts. You can use LangGraph to implement Sequential, Coordinator, or Hierarchical patterns.

-> Deep-dive article: LangGraph: Managing Agent Workflows with Graph Structures

8. MCP (Model Context Protocol)

MCP is an open standard released by Anthropic in late 2024, aiming to become the USB-C of AI tool calling.

Before MCP, every AI application had to write its own integration logic for each tool. Your Agent needs to use Slack, GitHub, and Jira? Three API integrations, three different authentication methods, three sets of error handling.

MCP defines a standardized protocol: tool providers implement an MCP Server, AI applications implement an MCP Client, and the two communicate via standard JSON-RPC. This means:

• Any AI application that supports MCP can directly use any tool provided by any MCP Server
• Tool developers only need to write one MCP Server to be usable by all MCP Clients
• Permissions, authentication, and capability negotiation all have standardized mechanisms

MCP is already supported by mainstream AI applications including Claude Desktop, Cursor, Windsurf, and Claude Code. The ecosystem is growing rapidly, with more and more tools gaining MCP Servers — from database queries to browser automation to cloud service management.

How does MCP relate to the other topics in this guide?

• Relationship with Harness: MCP is the standardized implementation of the Tool Registry in the Harness. The Harness defines “Agents need a tool management layer,” and MCP defines “what the protocol for this management layer looks like.”
• Relationship with Context Engineering: MCP Servers provide not only tools but also Resources (contextual information) and Prompts (preset interaction templates). Resources are essentially an implementation of Context Engineering’s Select strategy.
• Relationship with Multi-Agent: In multi-agent architectures, different Agents can connect to different MCP Servers, achieving separation of responsibilities.

-> Deep-dive article: MCP (Model Context Protocol): The Standardized Protocol for AI Agent Tool Calling

9. Agent Memory

Traditional RAG is read-only: you have a set of documents, the Agent retrieves and answers. Agent Memory upgrades this model to read-write: the Agent can not only read memories but also write new ones.

Three types of memory:

• Procedural Memory: Knowledge about how the Agent does things (equivalent to muscle memory). For example: “Last time the user requested responses in Traditional Chinese” or “This codebase uses pnpm, not npm.”
• Episodic Memory: Specific events the Agent has experienced in the past. For example: “Last time the user asked this question, I solved it using method X.”
• Semantic Memory: The Agent’s general knowledge about the world. For example: domain knowledge learned from a document library.

The design challenge of memory systems is not “how to store” but “how to selectively recall.” An Agent with a hundred thousand memories is no better than one with no memory if it cannot recall the right memory at the right time. This brings us back to the core problem of Context Engineering: Select.

A concrete example: Claude Code’s CLAUDE.md is a form of procedural memory — it tells the Agent “in this project, you should use pnpm instead of npm” or “commit messages should be in Chinese.” This information is not inferred from conversation but read from persistent memory.

Memory is also one of the biggest differences between Agents and chatbots. Chatbots typically only have short-term memory within a session (conversation history), while Agents need cross-session long-term memory to become more useful over time.

-> Deep-dive article: Agent Memory Systems: The Evolution from RAG to Read-Write Memory

10. Chatbot Development

Chatbots are the most common form of Agent applications, but the gap between “works in a demo” and “ready for production” is enormous.

A production-grade chatbot needs to solve far more problems than just “calling the LLM API”:

• State management: How do you maintain context in multi-turn conversations? How do you truncate when the conversation gets too long?
• Memory strategy: How do you store and retrieve cross-session user memories?
• Streaming responses: How do you achieve token-by-token streaming output rather than waiting for the entire generation to complete?
• Guardrails: How do you prevent prompt injection? How do you filter unsafe output?
• Tech stack selection: Vercel AI SDK vs LangChain vs building from scratch? What are the trade-offs of each?

Each of these problems has pitfalls, and they interact with each other. For example, streaming responses and guardrails have a natural conflict — you want to start streaming before the output is complete, but guardrails need to see the full output to make a judgment.

Chatbot development can be considered the “comprehensive exam” of all topics in this guide:

• You need Context Engineering to manage the context window in multi-turn conversations
• You need Prompt Engineering to design system prompts and conversation guidance
• You need Harness Engineering to handle error recovery and state persistence
• You need Agent Memory to implement cross-session memory
• You need Observability to trace every conversation in production

If you can build a stable production-grade chatbot, your understanding of Agent architecture is already solid.

-> Deep-dive article: Complete Guide to Chatbot Development: State Management, Memory Strategy, and Tech Stack Selection

11. Observability

You would not deploy a backend service without logging and monitoring. AI Agents are no different.

Observability is even more important for LLM applications than traditional applications because LLM behavior is inherently non-deterministic. The same input can produce different outputs, and you need to see the full trace of every call to debug effectively.

Langfuse is currently the most popular open-source LLM observability platform, offering:

• Traces: Complete request tracing from user input to final response at every step
• Prompt Management: Version-controlled management of your prompts, tracking which version performs best
• Evaluation: Automated and manual evaluation to establish quality baselines
• Cost Tracking: How much each call costs, which users or features are the most expensive

Observability is not nice-to-have — it is a mandatory requirement for production-grade Agents. Without it, you are flying blind.

A practical scenario: your Agent suddenly starts giving low-quality answers in production. Without observability, all you can see is “users are complaining.” With observability, you can see:

1. The low-quality answers are concentrated in a specific time window
2. RAG retrieval quality dropped during that window
3. The cause was a failed embedding index update
4. Quality recovered after fixing the index

From “users are complaining” to “root cause found,” observability shortens this process from days to minutes.

Beyond debugging, observability has two often-overlooked benefits:

• Cost control: LLM calls are not cheap. Without cost tracking, you will not know how much a feature costs per day, nor will you know that a user’s prompt injection attempts are wasting your tokens.
• Continuous improvement: With evaluation data, you can quantify the effect of every prompt modification or architecture adjustment rather than relying on gut feeling.

-> Deep-dive article: Langfuse Complete Guide: LLM Application Observability from Scratch

12. Agent Design Principles

Across all topics, five design principles appear repeatedly. No matter what type of Agent you are building, these principles apply:

Principle 1: Minimal Tool Set

Give the Agent the fewest tools, not the most. Every additional tool increases the probability of the Agent choosing the wrong one. If a tool is not used in 90% of scenarios, do not load it by default — use dynamic tool selection to provide it on demand.

Real-world data: when available tools increase from 5 to 20, the Agent’s accuracy in selecting the right tool drops noticeably. This is not a model problem — it is an information overload problem, which brings us back to the core thesis of Context Engineering.

Principle 2: Explicit Stopping Conditions

The Agent must know when to stop. An Agent without explicit stopping conditions will fall into infinite loops or continue doing unnecessary work after the task is already complete. Explicitly define in the system prompt: “When condition X is met, stop and report the result.”

Principle 3: Observability First

Integrate observability on the first day of building the Agent — do not wait until after launch to add it. Every LLM call, every tool execution, every decision branch should be recorded and traced. This is the same as logging in traditional software development: retrofitting is always more painful than building it in from the start.

Principle 4: Graceful Degradation

Tool calls will fail, APIs will timeout, and LLMs will hallucinate. Your Agent must have fallback strategies: use fallback methods when tools fail, retry when LLM responses do not match the expected format, and have timeout mechanisms when the entire flow gets stuck.

Principle 5: State Persistence

Any Agent task that takes more than 30 seconds should have a checkpoint mechanism. Users will not thank you if your Agent crashes after running for 5 minutes — but if you can recover from the last checkpoint, users will consider you professional.

These five principles do not require specific frameworks or tools; they are design-level thinking. Before you write the first line of Agent code, think through these five principles clearly, and you will save a massive amount of refactoring time.

Condensed into one sentence: Make the Agent do less, know when to stop, see what it is doing, be fixable when broken, and resumable when interrupted.

Recommended Reading Paths

Not sure where to start? Here are four suggested paths based on your role and goals. The articles within each path have logical progression, so reading in order is recommended:

Beginner Path: Understanding What an Agent Is

Agent Three Pillars → Prompt Engineering → Context Engineering → Chatbot Development

Start from the most fundamental conceptual model and understand the three dimensions of an Agent. Then learn how to write good prompts (this is still a fundamental skill), then understand the broader Context Engineering framework. Finally, ground the theory with chatbot development. This path takes approximately 1.5 hours.

Advanced Path: Building Complex Systems

Harness Engineering → Multi-Agent Design Patterns → LangGraph → MCP

When your Agent can already function at a basic level, this path helps you build more complex and reliable systems. Harness gives you the control layer, Multi-Agent gives you architecture patterns, LangGraph gives you the execution framework, and MCP gives you standardized tool integration. This path takes approximately 1.5 hours.

Production Path: Making Systems Reliable for Launch

Agent Design Principles → Observability → Harness Engineering (Guard System) → Chatbot Development

Your Agent has successfully demoed, and your boss wants you to ship it. This path focuses on production environment essentials: design principles help you avoid common pitfalls, observability lets you debug, the Guard System keeps you safe, and the chatbot guide gives you a complete production checklist. This path takes approximately 1 hour.

Full-Stack Path: End to End

Three Pillars → Three-Stage Evolution → Prompt Eng. → Context Eng. → Harness Eng.
→ Multi-Agent → LangGraph → MCP → Memory → Chatbot → Observability

Follow the chapter order of this article, from concepts to implementation, for a complete walkthrough. Suitable for those who want a systematic understanding of the entire AI Agent architecture system. Estimated reading time: all articles combined, approximately 3-4 hours.

Quick Reference: I Have This Problem — Which Article Should I Read?

Conclusion

The AI Agent tech stack in 2026 has developed into a complete engineering system. It is no longer just about “knowing how to write prompts” — you need to understand context management, harness design, tool standardization, memory systems, and observability to build reliable Agents.

But the good news is: these technologies have clear logical relationships and a learning order. You do not need to learn everything at once — just know where you are on the map and where to go next.

Back to the panoramic view from the beginning:

• The foundation is the Agent Three Pillars (Context/Cognition/Action) — your conceptual base
• The middle layer is the Harness control layer — your engineering base
• The upper layer is various architecture patterns and production requirements — your practical domain

No matter how AI technology evolves, this three-layer structure will not change. Models will keep getting stronger, but context management, control flow, and observability — these engineering concerns will only become more important. The stronger the model, the more complex the tasks you can delegate to it, and the higher the demands on engineering infrastructure.

This is the purpose of this guide: to give you a map so you do not get lost in this rapidly evolving field.

If you find a particular topic especially interesting while reading this article, do not hesitate — click through immediately. A theoretical “optimal learning path” is less effective than your own curiosity.

One final reminder: AI Agent technology iterates extremely fast. This guide and all linked articles are based on the technical landscape of early 2026. Specific frameworks and tools will change, but the underlying architectural thinking — the Three Pillars model, control layer design, observability — these are stable. Master them, and you will have the ability to judge for yourself whether new technologies are worth adopting.

Pick a reading path and get started.

References

• ReAct: Synergizing Reasoning and Acting in Language Models — Yao et al. (2023, ICLR), the Agent framework interleaving reasoning and action, the theoretical foundation of modern Agentic RAG
• Tree of Thoughts: Deliberate Problem Solving with Large Language Models — Yao et al. (2023, NeurIPS), a multi-path search cognitive framework for Agents, going beyond linear Chain-of-Thought
• Anthropic — Effective Context Engineering for AI Agents — Anthropic engineering blog, complete implementation principles for Context Engineering and Harness Design
• LangChain — Context Engineering for Agents — LangChain, Write/Select/Compress/Isolate four major context management strategies
• Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG — Singh et al. (2025), comprehensive survey of Agentic RAG system evolution and Multi-Agent architectures
• AgentVerse: Facilitating Multi-Agent Collaboration and Exploring Emergent Behaviors — Chen et al. (2023), Multi-Agent collaboration framework and emergent behavior experiments
• HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face — Shen et al. (2023), an early example of LLM as controller coordinating multiple models in a Hierarchical Agent architecture
• Model Context Protocol (MCP) Official Specification — The MCP standard specification published by Anthropic, the core protocol for Agent tool standardization