DeepAgents in Practice: The Five Evolutionary Stages of Multi-Agent Architecture

From Model Calls to Deep Multi-Agent Systems

In just a few years, the AI landscape has been transforming at a breathtaking pace — and Agent technology in particular has been iterating on a weekly basis. To truly appreciate the value of multi-agent frameworks like DeepAgents, we first need to map out the complete evolutionary arc of agent technology.

According to a developer who has been deeply involved in agent development since the first half of 2024, the evolution of agents can be summarized at a macro level by three major trends: from one-shot model calls, to agents with autonomous planning capabilities, to deep agents (DeepAgents) capable of self-directed decision-making and coordinating multiple sub-agents. Zoom in further, and this journey actually spans five distinct technical cycles.

This article traces those five cycles — charting how agent technology evolved step by step from "manually hand-crafting API calls" to "divide-and-conquer multi-agent collaboration" — with a focused look at the core design philosophy behind the DeepAgents framework.

Cycles One Through Three: From Manual Calls to Semi-Autonomous Graphs

Cycle One: Raw Interaction Between Programs and LLMs

The earliest agents were, in essence, nothing more than replacing the human in a "person chatting with an LLM" scenario with a program. What developers needed to do was simple — just know how to make HTTP requests. A program would wrap a prompt, send it to an LLM (like Kimi) via a network request, receive the response, parse the JSON, and store it in a database.

This pattern was once used to build an "intelligent exam system" covering both automated question generation and automated grading. But the downsides of this archaic approach were glaring: no contextual memory — all conversation information was lost the moment an interaction ended; and parsing was a nightmare — return formats had to be manually agreed upon, extracted, validated, and converted, making the whole pipeline brittle and tedious.

Cycle Two: The Convenience of LangChain and Other Frameworks

As frameworks like LangChain (Python), LangChain4j, and Spring AI (Java) began to emerge, development entered the second cycle. In their early days, these frameworks didn't yet have a true "agent" concept — they primarily provided capabilities like multi-turn conversation memory, message wrapping (AIMessage, SystemMessage, ToolMessage), and output parsers.

Calling models, assembling prompts, and parsing results all became much easier. But at its core, a program was still just a more polished wrapper around what Cycle One already did — you told it what to do, and it did exactly that. There was nothing truly intelligent about it.

Cycle Three: LangGraph and Semi-Autonomous Agents

The defining technology of the third cycle is LangGraph. Understanding how it differs from LangChain comes down to two words: Chain means a "chain" (a linear, forward-moving process), while Graph means a "graph" (a structure of interconnected nodes).

LangGraph lets developers define fixed nodes, design specific workflows, and control node transitions through regular edges and conditional edges (virtual edges), enabling a semi-autonomous agent. At this point, you had a complete workflow with conditional logic enabling autonomous handling — but the overall flow graph was still relatively hardcoded.

LangGraph's "graph" structure draws conceptually from both directed acyclic graphs (DAGs) and state machines. Each node represents a processing unit (a model call, a tool execution, or a custom function), while edges define the data flow between nodes. A "conditional edge" is essentially a decision function — it takes the current node's output and returns the name of the next node to jump to, enabling branching and looping. This design makes it possible to express logic like "retry when a condition is met" or "fall back to an alternative path on failure" using graph structures. Compared to LangChain's linear Chain structure, a Graph can model far more complex workflows — but developers still have to pre-define all possible nodes and transition rules. The agent itself cannot "conjure" new nodes at runtime. That's precisely why it's called "semi-autonomous."

Cycle Four: create_agent and Truly Autonomous Planning

The hallmark of the fourth cycle is the create_agent function in LangChain. This is what actually creates a genuine "agent."

A key insight here: create_agent is still powered by LangGraph's graph under the hood. Dig into the source code and you'll find it ultimately relies on the same graph structure.

So where does the intelligence actually live? An Agent can be configured with one model and a set of tools. When executed, it autonomously plans which tools to call and in what order based on the incoming prompt. For example, given the same set of tools, a prompt saying "Tonight, fight the tiger" might trigger tools 1 and 4, while "Today, fight Qin Qiong" might trigger tools 1, 3, and 4. Each tool is essentially a LangGraph node, and the Agent uses the model's feedback to decide which nodes to invoke, in what sequence, and how to connect them — dynamically assembling a graph at runtime for execution.

This is the stage where most developers currently operate. But it comes with an unavoidable problem — unpredictable outcomes. Drawing from real-world experience with heavy use of AI coding tools, agents sometimes get "stuck in a rut": they lock onto a solution and grind away relentlessly, falling into infinite loops, calling the same tool over and over, or repeatedly modifying the same file. The current remedy is HITL (Human-in-the-Loop) combined with middleware — for instance, if a tool has been called eight times with no result, the system forcibly exits.

HITL (Human-in-the-Loop) is an engineering pattern that inserts human intervention points into automated workflows. In the context of agents, it's typically implemented as "checkpoints": the framework pauses execution under certain conditions (e.g., a tool fails N times consecutively, confidence drops below a threshold, or a sensitive operation is detected), serializes the current state, and waits for human confirmation or correction before resuming. LangGraph natively supports persistent state and breakpoint recovery, making HITL practically viable. Middleware-based intervention, on the other hand, is more of a passive monitoring approach — intercepting tool call logs and counting repeated invocations to trigger a circuit breaker. It's essentially a protective shell wrapped around the Agent's execution loop, designed to guard against the "infinite loop" problem caused by insufficient model planning capabilities.

Cycle Five: DeepAgents and the Divide-and-Conquer Multi-Agent Architecture

From Single Agent to Multi-Agent Collaboration

The final cycle is called DeepAgent — and notice the subtle shift in the name: from agent to agents, from singular to plural. It represents a deep multi-agent architecture.

The typical pattern looks like this: a main agent can be configured with several sub-agents, which can themselves nest further sub-agents, and each agent can also be configured with tools and even skills. The main agent doesn't just decide which tools to invoke — it autonomously decides which sub-agents to call as well.

Many developers who see this will immediately think of microservices in Java, or the A2A (Agent-to-Agent) protocol. The analogy is apt — DeepAgent is fundamentally about agents calling other agents. But it's more powerful than microservices: it can autonomously decide which sub-agents to invoke. And unlike the external protocol-based A2A, it operates as an internal framework call — more like a method invocation. The multi-agent philosophy Anthropic has championed is, at its core, precisely "divide and conquer."

A2A (Agent-to-Agent) is an open standard proposed by Google in 2025, designed to allow agents built by different vendors and frameworks to call each other through standardized interfaces — similar to OpenAPI specifications in the microservices world. It uses "Agent Cards" to describe an agent's capability metadata; callers use these to discover and delegate tasks to target agents, with communication based on HTTP/SSE. In contrast, sub-agent calls within the DeepAgents framework are direct in-process method calls — no network serialization overhead, no service discovery needed. The two approaches aren't mutually exclusive: A2A suits cross-organization, cross-system agent collaboration, while built-in multi-agent calls are better suited for highly cohesive scenarios within a single application, offering lower latency and easier state sharing.

The Core Advantages of DeepAgents Over a Single Agent with Many Tools

Some might ask: if a single Agent can already be configured with many tools, why do we need DeepAgent? The difference boils down to two key points:

First, context isolation. No matter how many tools you give a single Agent, they all belong to the same agent, sharing the same context and the same model. When you need to handle both a medical knowledge base and a legal knowledge base, cramming knowledge from different domains into one context causes the model to "lose focus" — the more directions it has to handle and the more cluttered the context becomes, the weaker its performance. In DeepAgent, however, each sub-agent's context and system prompt are fully isolated from one another — a form of genuine decoupling.

Second, model heterogeneity. A single Agent can only be configured with one model. If your functionality involves both text processing and image processing, you're forced to pick a multimodal model — but multimodal models aren't always best-in-class for text. DeepAgent lets you configure different models for different sub-agents, achieving a setup where "different agents have different system prompts, different models, handle different capabilities, and each one excels at what it does."

Two Core Drivers Behind Truly Autonomous Agent Systems

Building a genuinely autonomous multi-agent system requires two core drivers working in tandem.

Driver One: The Closed-Loop Capability of a Deep Agent Framework

Frameworks like DeepAgents are responsible for "knitting" multiple agents together. Unlike traditional single-pass outputs, they possess the complete closed-loop capability of plan, execute, receive feedback, and iterate.

Concretely: when faced with a task, the framework first plans a route (e.g., "use only tools 1, 3, and 4"). If tool 3 throws an error during execution, it feeds that failure back to the model; the model then re-iterates its plan (e.g., switching to "tools 1 and 4"). The entire execution process is no longer a fixed, hardcoded flow — it dynamically adjusts based on each prompt. This is exactly what you see when using AI coding tools: a to-do list being executed step by step through autonomous planning.

Driver Two: High-Order Prompt Strategy (HOPS)

Once you have framework capabilities, the way you write prompts also needs to level up.

Traditional prompts tell the model "what to do" — for example, "Write me a piece of Java code" — simply stating a clear objective. High-Order Prompt Strategy (HOPS) doesn't directly say what to do. Instead, it tells the model "what you have" and "the general process" — which tools and models are available, what rules to follow — and then lets the framework decide on its own how to plan and execute.

Here's an analogy to illustrate the difference: a traditional prompt reflects an employee mindset — do whatever you're told, no autonomous decision-making. HOPS reflects a CEO mindset — laying out the big picture (e.g., "The company is currently worth $1 billion, the target is $2 billion, here are the resources and levers we have"), describing only the high-level process, and leaving the specific execution to the deep agent framework to dynamically orchestrate.

That said, HOPS isn't something you can master in a day or two — it requires developers to have a deep understanding of the agent framework.

In engineering practice, HOPS typically includes several standard modules: Role & Objective (the agent's positioning and end goal), Available Resources (a catalog of all callable tools, sub-agents, and their capability boundaries), Decision Rules (which tool types to prioritize in specific situations, when to escalate to a parent agent), and Output Constraints (format, language, safety guardrails). Compared to traditional prompts, HOPS is more like a "job description" than a "task checklist." This approach requires developers to have a clear understanding of the entire system's capability topology — inaccurate resource descriptions will lead the model to plan incorrect execution paths. That's why the author emphasizes that "a deep understanding of the agent framework" is a prerequisite for wielding HOPS effectively.

A Final Word: Viewing the Evolution of Agent Technology with Nuance

You may not have noticed — don't be misled by the blizzard of new concepts: in the agent space, "a new term every day, a new technology every week" is par for the course, but many of these concepts are simply existing technologies wearing a new label.

More importantly, DeepAgent is not a silver bullet, and the earlier technical cycles won't be entirely abandoned. When building a RAG knowledge base project, for instance, LangGraph may still be the more appropriate choice rather than DeepAgents — because DeepAgent has its own applicable boundaries, and in some scenarios a simpler approach is actually better.

Technological evolution is about layering, not replacement. Understanding the full context behind these five cycles is far more valuable than blindly chasing the latest framework.