Five Stages of Agent Evolution: From Model Calls to DeepAgents — A Deep Dive

Five Evolutionary Stages of Agent Development

In just the past two to three years, the development paradigm for AI Agents has undergone rapid iteration. From simple question-and-answer interactions to today's multi-agent collaboration, the field sees weekly changes and monthly breakthroughs. Understanding this evolutionary path is a prerequisite for mastering new frameworks like DeepAgents.

From a macro perspective, agent development can be summarized in three major trends: Direct model calls → Semi-autonomous Agents → Deeply autonomous intelligent agents. But from a micro technical practice standpoint, there are five distinct stages worth dissecting. Let's walk through them one by one.

Stage 1: Pure Network Interaction Between Programs and Models

This is the "ancient era" of agent architecture. In essence, it simply replaced the "human" in human-machine dialogue with a "program." Developers only needed to master one skill — HTTP network requests.

Early interaction with large language models was fundamentally RESTful API calling. Developers sent prompts to model service endpoints via HTTP POST requests, and the server returned generated results in JSON format. Technically, this was almost no different from traditional Web API calls (like calling a weather API or payment API). The only distinction: LLM output is non-deterministic — the same input may produce different outputs, and output format is difficult to control precisely. This meant developers spent enormous effort on "post-processing": regex matching, string extraction, JSON parsing with error tolerance, etc.

A typical scenario would be an "intelligent exam system": the program packages prompts, sends them to a model (like Kimi) via network requests, then manually parses the JSON response, validates and extracts data, and stores it in a database. Intelligent question generation, automated grading, and intelligent evaluation — all accomplished through back-and-forth exchanges between program and model.

Two major pain points at this stage were glaringly obvious: No context memory — every interaction was one-shot, requiring all information to be stuffed back into the prompt during grading; and Extremely tedious data parsing — requiring manual format agreements, extraction, compliance verification, and JSON conversion.

Stage 2: Development Convenience Through Framework Abstraction

As frameworks like SpringAI, LangChain, and LangChain4J emerged, development entered its second phase. However, it's important to clarify that frameworks at this stage didn't yet have a true Agent concept.

LangChain (Python ecosystem) and SpringAI/LangChain4J (Java ecosystem) are middleware frameworks for LLM application development. Their core contribution was abstracting away the differences in interacting with various LLMs, providing a unified interface layer. The message type system (SystemMessage for role setting, AIMessage for model responses, HumanMessage for user input, ToolMessage for tool return results) is a standardized wrapper around OpenAI's Chat Completions API message format. The conversation memory mechanism simulates "memory" by automatically attaching historical dialogue records to each request — essentially concatenating history messages into the context window, which is why context length limits (4K, 8K, 128K tokens) become critical constraints.

They primarily provided three things: Multi-turn conversation memory, Structured prompt encapsulation (AIMessage, SystemMessage, ToolMessage), and Convenient output parsers. Combined with existing code, interacting with models did become significantly simpler.

But in essence, Stage 2 was just a wrapper around Stage 1. Programs were still "somewhat dumb" — they did exactly what you coded, lacking any autonomy.

From Graph Structures to True Agents

Stage 3: LangGraph Enables Semi-Autonomous Agents

The core of Stage 3 is LangGraph (graph structure). Understanding it requires distinguishing two concepts: LangChain is a "Chain" — like a toy train moving forward in fixed steps 1-2-3-4; LangGraph is a "Graph" — a multi-node networked structure.

LangGraph borrows from Directed Graph and State Machine concepts. In this graph structure, each "Node" represents a processing unit — which could be an LLM call, a tool execution, or a piece of business logic; "Edges" define execution flow between nodes; "Conditional Edges" dynamically determine the next step based on runtime state. This design pattern was already mature in workflow engines (like BPMN) and dataflow programming. LangGraph's innovation lies in combining it with LLM reasoning capabilities — conditional decisions can be driven by model output rather than solely by hardcoded rules. Compared to traditional chain-based calling, graph structures support Loops, Branches, and Parallel execution, significantly enhancing expressiveness.

At this stage, developers can set fixed nodes, design specific workflows, then connect nodes through "edges" and even set "conditional edges" — jumping to specified nodes when certain conditions are met. The result is a semi-autonomous Agent: it has a complete workflow while incorporating conditional control for partially intelligent processing.

Stage 4: create_agent and Autonomous Tool Invocation

Stage 4 brought the first truly intelligent agents. LangChain's create_agent function creates Agents configured with a model and various tools, capable of autonomously planning which tools to invoke based on the input prompt.

The underlying technical foundation for this capability is the LLM's Function Calling mechanism. This technology was first introduced by OpenAI in June 2023: developers declare available function names and parameter schemas (in JSON Schema format) in the request. When the model determines it needs to call a function during generation, it outputs a structured function call instruction (containing the function name and parameter values) rather than a direct text answer. The program captures this instruction, executes the corresponding function, and feeds the result back to the model for continued reasoning. This mechanism is the technical foundation of Agent "autonomous decision-making" — the model isn't executing tools, it's "deciding" which tool to call and what parameters to pass.

Here's an intuitive example: An Agent configured with four tools — when the prompt is "hunt a tiger tonight," it might automatically invoke tools 1 and 4; with a different prompt, it triggers tools 1, 3, and 4. This "dynamic decision-making based on prompts" is precisely what makes Agents intelligent.

A key insight: The underlying implementation of create_agent is still a LangGraph graph. Each tool is a node, and the Agent decides through model planning which nodes to invoke and in what order, ultimately dynamically assembling a graph for execution. The difference is that LangGraph's graph is hardcoded, while an Agent's graph is dynamically generated from prompts.

But Stage 4's shortcomings are equally prominent: Uncontrollable results. Many people using AI coding tools have encountered this — once the model commits to an approach, it goes "all in," falling into infinite loops, repeatedly calling a tool without getting results. The only mitigation is through middleware monitoring, HITL (Human-In-The-Loop) interventions, and similar measures — for instance, forcing an exit after detecting eight unsuccessful calls to the same tool.

HITL (Human-In-The-Loop) is a safety paradigm in AI system design. In Agent scenarios, it means inserting human review or intervention checkpoints at critical nodes in the autonomous execution flow. Typical implementations include: requesting human confirmation before high-risk operations, pausing and requesting human guidance when abnormal loops are detected, and periodically reporting progress to humans for feedback. This mechanism is a pragmatic compromise on "full autonomy" — at the current stage where model capabilities aren't yet perfect, HITL preserves the Agent's automation advantages while reducing runaway risks through human oversight.

DeepAgents: Multi-Agent Architecture for Autonomous Decision-Making

Stage 5: Deep Multi-Agent Collaboration

The final stage is this article's protagonist — DeepAgents. The name says it all: Deep + Agents, meaning "deep multi-agents."

Its core pattern: A Main Agent coordinates multiple Sub Agents, which can further nest sub-agents beneath them, while each agent can still be configured with tools and even skills. The Main Agent can not only decide which tools to invoke but also autonomously decide which sub-agent to call. This is precisely the multi-agent philosophy proposed by Anthropic — divide and conquer.

The Essential Difference Between DeepAgents and Regular Agents

Many wonder: A regular Agent can also be configured with thousands of tools — what's the difference with DeepAgents? The key lies in context isolation.

No matter how many tools a regular Agent has, they all belong to the same agent, sharing the same context and the same model. This creates serious problems: suppose an Agent handles both a medical knowledge base and a legal knowledge base — dumping different domains into one context causes the model to suffer from "attention deficiency." Processing a single domain works fine, but mixing multiple domains actually weakens its capabilities.

From a technical perspective, this "attention deficiency" corresponds to the dilution effect of the Attention Mechanism in Transformer architecture. The model computes attention weights between every input token and all other tokens. When the context is filled with information from diverse domains, the model's attention becomes scattered by irrelevant information when processing domain-specific questions, degrading reasoning quality. Research shows that even when context window capacity permits, excessively long or heterogeneous contexts lead to the "Lost in the Middle" phenomenon — the model's ability to extract information from the middle of the context is significantly weaker than from the beginning and end.

In DeepAgents, each sub-agent's context and prompts are isolated. One sub-agent can specialize in medical topics, another in legal, another in entertainment — the main agent only handles dispatch and result refinement. This is essentially a decoupling behavior.

There's another important advantage: Different sub-agents can be configured with different models. A regular Agent can only choose one model — if it needs to handle both text and images simultaneously, it's forced to pick a multimodal model, which may not be optimal for pure text processing. DeepAgents allows the image-specialized agent to use one model and the text-specialized agent to use another, each excelling in their role, making every individual unit strong.

Regarding its relationship with A2A and MCP: DeepAgents' sub-agent invocation is a form of A2A (Agent to Agent), but it's an internal method call within the framework, not an external protocol call; it's similar to MCP (a remote tool invocation protocol), but MCP is an external protocol while DeepAgents uses internal invocation.

A2A (Agent-to-Agent) is an open protocol proposed by Google in 2025, designed to enable AI Agents built by different vendors and frameworks to discover, communicate, and collaborate with each other — similar to service discovery and RPC calls in microservice architecture. MCP (Model Context Protocol) is an open standard released by Anthropic in late 2024, defining standardized connections between LLM applications and external tools/data sources — analogous to a "USB port" for AI, letting any MCP-compatible tool be called by any MCP-compatible Agent. While DeepAgents' internal sub-agent calling is conceptually similar to A2A, it's an in-process method call with no network communication overhead or protocol negotiation — more efficient but also more tightly coupled. For now, think of it as inter-Agent calling within a framework.

Two Driving Forces Behind Autonomous Agents

To truly build an autonomous multi-agent system, two core driving forces are needed.

Driving Force 1: Deep Agent Frameworks

The first is the framework that "assembles" agents together — namely DeepAgents. Its biggest change is that execution is no longer a one-shot output but possesses a complete closed loop of "plan, execute, feedback, iterate."

This closed-loop execution model originates from classical Cybernetics feedback loops and the OODA loop (Observe-Orient-Decide-Act) from cognitive science. In AI Agent research, this pattern is called an advanced version of the ReAct (Reasoning + Acting) paradigm. ReAct has models alternate between "thinking" and "acting," while DeepAgents further introduces explicit Plan and Reflect layers. This aligns with numerous research findings since 2023, such as Stanford's Generative Agents using "reflection" mechanisms and Princeton's Tree of Thoughts using "search" strategies. The core idea: let Agents not just "execute" but also "plan" and "self-correct," exhibiting problem-solving abilities closer to human cognition in complex tasks.

For example, when processing a task, the framework first plans a route (e.g., "use only tools 1, 3, 4"). If tool 3 throws an error during execution, it feeds the error back to the model, which iterates on a new plan (e.g., switching to "1, 4"). The entire process dynamically adjusts based on each prompt and execution outcome — highly similar to the experience of AI coding tools generating a to-do list and executing step by step.

Driving Force 2: Higher-Order Prompt Strategies (HOPS)

The second is the evolution of prompt writing. Traditional prompts tell the model "what to do" (e.g., "write me some code"); Higher-order prompts tell the model "what you have" — what tools are available, what models exist, and what the general processing rules and workflow look like.

An analogy: Traditional prompts are like an employee mindset — doing whatever the boss says; higher-order prompts are like strategic planning — you only need to clarify the goal, available resources, and process rules, leaving the specific tool invocations to the DeepAgents framework to decide autonomously based on the actual problem.

However, it should be honestly noted that higher-order prompts are not easy to write — even experienced developers need continuous refinement.

A Rational View of the Agent Framework Hype

A final reminder: The agent field produces a constant stream of technical jargon — nearly one new concept per day and one trending framework per month. But many concepts are essentially "old wine in new bottles" — different names for similar ideas. Don't be misled by the dizzying array of terminology.

At the same time, while DeepAgents is powerful, it's not a silver bullet — it has clear applicable scenarios and its own limitations. Reaching Stage 5 doesn't mean all previous approaches are obsolete; LangGraph and others will continue serving RAG knowledge base projects and similar use cases. Understanding the applicable boundaries of each stage is the true path to mastery.

Key Takeaways