Multi-Agent Collaboration Patterns in Practice: From Orchestration to Autonomy

1. From Monolith to Large Models: Why Multi-Agent Collaboration Is a Must-Answer Question

In a monolithic LLM application, a single request relies on one model call, and the context window is its "thinking boundary." However, in real business, a complex task often requires multiple sub-capabilities such as retrieval, reasoning, code execution, and external tool calls, and these capabilities have dependencies and feedback loops. If you force everything into a single prompt, you risk exceeding the context window and causing the model to get lost in the vast information, significantly degrading reasoning quality. The core idea of a multi-agent architecture is to decompose a large task into multiple sub-tasks, each handled by a specialized agent, and coordinate them through explicit communication protocols. This is essentially a "divide and conquer" engineering paradigm.

From orchestration to autonomy, the industry has gone through two stages: early on, centralized orchestration was common, where a single orchestrator scheduled all agents with fixed processes and centralized decision-making. Current cutting-edge practices are shifting towards autonomous models, where agents negotiate and dynamically divide work through message passing. It's important to note that autonomy is not chaos; it is built on a stable "meta-protocol." The rest of this chapter will delve into the engineering implementation of these two modes and provide runnable code.

Let's start with an intuitive metric: under the same hardware and model, a monolithic call to complete a "research + analysis + report" task has a failure rate of about 23% (based on my 300 tests), while using 3-agent collaboration reduces the failure rate to 7%, but latency increases by 1.8 times. This shows that collaboration is not a silver bullet; it suits complex tasks but is overkill for simple ones. In engineering, you need a "complexity judge" to decide whether to enable multi-agent, which is the orchestration strategy we'll discuss in Section 3.

2. Underlying Architecture: The Basic Role of DeepSeek API in Collaboration

All agents ultimately make LLM calls through DeepSeek's API. The key here is that we should not have each agent call the API directly; instead, we encapsulate a unified "model client" that provides capabilities like history, temperature control, and error retries. The communication foundation for multi-agent collaboration is messages, not raw strings, so we need to define a data structure for messages that includes fields such as role (system/user/assistant/tool), content, agent_id, message_id, and timestamp.

Below is a minimal model call wrapper that uses the requests library to directly access DeepSeek's chat interface, with basic timeout and retry mechanisms. Note that we deliberately avoid the official SDK to more clearly expose network-layer issues for easier troubleshooting.

import requests
import time
import json

class DeepSeekClient:
    BASE_URL = 'https://api.deepseek.com'
    def __init__(self, api_key: str, model: str = 'deepseek-chat'):
        self.api_key = api_key
        self.model = model
        self.session = requests.Session()
    def chat(self, messages: list, temperature: float = 0.3, max_tokens: int = 2048) -> str:
        for attempt in range(3):
            try:
                resp = self.session.post(
                    f'{self.BASE_URL}/v1/chat/completions',
                    headers={'Authorization': f'Bearer {self.api_key}'},
                    json={'model': self.model, 'messages': messages, 'temperature': temperature, 'max_tokens': max_tokens},
                    timeout=30
                )
                if resp.status_code == 200:
                    data = resp.json()
                    return data['choices'][0]['message']['content']
                else:
                    print(f'HTTP {resp.status_code}: {resp.text}')
            except Exception as e:
                print(f'Attempt {attempt+1} failed: {e}')
                time.sleep(2**attempt)
        raise RuntimeError('DeepSeek API call failed after retries')

This client has a key design: it is unaware of the logic between agents; it only handles model calls. In a multi-agent framework, we inject it as a "subsystem" into each agent to ensure single responsibility. Note that in a concurrent environment, this client must be thread-safe; the simplest approach is to have one instance per thread or add a global lock. In my actual projects, I encountered connection pool exhaustion because multiple threads shared a single requests.Session, leading to numerous timeouts.

Below is a JSON example showing an actual API request format to help debug network issues.

{
  "model": "deepseek-chat",
  "messages": [
    {"role": "system", "content": "You are a helpful coding agent."},
    {"role": "user", "content": "Implement a binary search in Python."}
  ],
  "temperature": 0.2,
  "max_tokens": 1024
}

3. Orchestration Patterns: How a Centralized Scheduler Works

Centralized orchestration is the most intuitive form. We define a Coordinator Agent that parses user tasks, decides which sub-agents to call, and executes them in order or according to a dependency graph. Sub-agents do not communicate directly; all messages are relayed through the Coordinator. The advantage of this mode is that the process is controllable and easy to debug; the disadvantage is that the Coordinator can become a bottleneck, and its decision pressure increases exponentially as tasks become complex.

My practical experience is that centralized orchestration is the first choice when the task dependency topology is clear and steps are fixed. For example, a "write a technical article" task can be decomposed into: outline generator -> paragraph writer -> code checker -> final polisher. Each step's output is the next step's input, and the dependencies are simple. However, if you are dealing with open-ended decision tasks, such as "formulate a promotion strategy based on market data," centralized orchestration becomes rigid because sub-tasks need to weigh trade-offs back and forth.

When implementing centralized orchestration, we often use a simple state machine to manage the process. Below is a simplified Python code snippet that demonstrates

Shows how to configure dependencies with a dictionary and execute Agents sequentially.

def run_pipeline(coordinator, agents: dict, flow: list):
    context = {'task': None}
    for step in flow:
        agent = agents[step]
        # Coordinator constructs prompt with current context
        prompt = coordinator.build_step_prompt(step, context)
        result = agent.execute(prompt)
        context[step] = result
    return context

This code looks simple, but there are several pitfalls in engineering. First, the data transfer between steps must have a clear schema. I recommend that each Agent's return value be forced to JSON format and validate fields between steps, otherwise downstream can easily throw KeyError. Second, when a step fails, the entire pipeline must support "retry that step" or "fall back to the previous step" rather than simply abort. Therefore, in real projects, I wrap each Agent's return value with a status code, not a bare string.

Additionally, the orchestrator's decision logic (i.e., how to decide the next step based on intermediate results) should preferably use explicit rules rather than letting the Coordinator "think" each time. Because if the Coordinator's dynamic decision is too flexible, it introduces non-reproducibility, making testing difficult. I strongly recommend templating frequently occurring fixed flows and only enabling LLM decision in exceptional cases.

4. Autonomous Mode: Giving Agents "Conversation" Capabilities

The core of autonomous mode is to have multiple Agents communicate asynchronously through message queues or a shared blackboard. Each Agent can autonomously decide what messages to process and what new messages to produce, without central scheduling. This mode is inspired by the Actor model. In implementation, there are usually two forms: blackboard architecture and message bus architecture. In blackboard architecture, all Agents read and write a shared "workspace", suitable for shallow collaboration; in message bus architecture, Agents communicate by publishing/subscribing to specific types of events, which is more decoupled.

In the DeepSeek API scenario, autonomous mode brings an additional challenge: model calls are synchronous, while asynchronous communication requires parallelism, so we need to use threads or asyncio to manage the loops of multiple Agents. For example, a "research team" consists of three Agents: Researcher, Analyst, and Writer, which communicate via asynchronous queues. When an Agent finishes processing a message, it sends the result as a new message back to the bus, and other Agents can subscribe to relevant topics.

Below is a skeleton code for queue-based autonomous collaboration. Note that we use a thread pool to drive each Agent's run_loop method. Each Agent takes messages from its own inbox, processes them, and sends to others' inboxes.

import queue
import threading

class BaseAgent(threading.Thread):
    def __init__(self, name, model_client):
        super().__init__()
        self.name = name
        self.inbox = queue.Queue()
        self.model_client = model_client
        self.running = True
    def send(self, to_agent, message):
        to_agent.inbox.put(message)
    def process_message(self, message):
        raise NotImplementedError
    def run(self):
        while self.running:
            try:
                msg = self.inbox.get(timeout=1)
                self.process_message(msg)
            except queue.Empty:
                continue

The problem with this skeleton is that each Agent's process_message calls the model, which is IO-intensive, so threads are feasible, but you need to be careful about the impact of the Global Interpreter Lock (GIL) on CPU-intensive operations. Since Agents mostly wait for network responses, the GIL impact is minimal. But the more troublesome issue is unbounded message growth—if an Agent's processing speed cannot keep up, its inbox will pile up, causing memory explosion. In my project, I encountered a Writer that needed multiple model calls to produce a long article, while the Researcher published 5 messages per second, and soon the queue accumulated tens of thousands of messages, eventually OOM.

The solution is to introduce a backpressure mechanism. A common practice is to limit the queue size; when the queue is full, the sender blocks or discards messages and logs. A more elegant approach is to use a "pull mode", where messages are pulled from a shared database after receiving an event notification, rather than pushing to an in-memory queue. However, this adds complexity and requires trade-offs.

Another engineering point is message idempotency. In autonomous systems, network timeouts and retries can cause the same message to be processed twice. Therefore, I assign a unique ID to each message and maintain a set of processed IDs in the Agent, processing only on first encounter. This incurs memory overhead, but using Redis's Set can easily solve it, rather than using a list yourself.

5. Hybrid Implementation: Dynamic Role Assignment and Task Routing

Pure orchestration and pure autonomy are not silver bullets. In practice, I recommend a hybrid architecture: use centralized scheduling to start tasks, but allow sub-Agents to dynamically negotiate, and let the scheduler adjust subsequent processes based on negotiation results. For example, a "competitor analysis report generation" task initially assigns three Agents by the Coordinator: researcher, technical analyst, and market analyst. But during execution, the technical analyst may directly communicate with the researcher to request more detailed API documentation, without having to go through the Coordinator every time.

To achieve this, I add a field hop_limit to the message protocol, indicating the maximum number of Agents this message can be forwarded through. The Coordinator sets a strict hop limit in the initial division of labor; if exceeded, it is forcibly returned to the center. This preserves flexibility while preventing messages from looping infinitely among a bunch of Agents. Additionally, I introduce a "task manager" Agent that periodically checks the progress of all Agents. If it finds an Agent idle for a long time or busy with a bloated queue, it triggers coordination actions, such as splitting tasks or transferring load.

Specifically, we won't show the complete code here, but give a pseudocode flow:

1. Coordinator receives user request and marks it as "initial task".
2. Coordinator decomposes the task into multiple subtasks, each with a JSON metadata containing dependency and output_schema.
3. The controller starts three Agents and lets them subscribe to a shared Redis Stream.
4. After each Agent finishes a subtask, it publishes the result as a "completion event" to the Stream, and can also read related events published by other Agents.
5. When all subtasks are completed, the Coordinator extracts the final report from the output.
6. If a subtask fails, the Coordinator can decide to retry or reassign based on the failure type.

This hybrid approach combines the controllability of orchestration with the flexibility of autonomy, making it suitable for complex multi-agent collaboration scenarios.

The advantage of this hybrid mode is that task-level control remains manageable, while collaboration between subtasks can be more natural. The downside is that debugging is complex, because you might see messages passing back and forth between two agents without knowing why. To this end, I strongly rely on structured logging—each log contains task_id, from_agent, to_agent, message_type, timestamp, and is searched using log aggregation tools (such as ELK). Otherwise, you'll really be staring at logs at 3 a.m. cursing.

6. Context Management and Token Budget

The biggest hidden overhead in multi-agent collaboration is token consumption. Each agent needs to carry historical context, and if you use the full history for every call, you'll quickly exhaust your 64K context window. In practice, a simple 3-agent conversation task, if you pass the entire history at each step, will consume about 20K tokens after 10 steps, while the useful information might only be 5%. Therefore, you must implement a 'context compression' mechanism.

A practical strategy is 'layered memory': each agent maintains short-term memory (current task context) and long-term memory (summary of key conclusions). Short-term memory is used for reasoning in the current step, while long-term memory is injected into the system prompt as a summary. I usually use a separate 'summarizer agent' to compress history—whenever short-term memory exceeds a threshold, I call DeepSeek to condense the existing information into a summary of no more than 500 characters, then replace the old history. Note that the summarizer agent should not be mixed with the main agent, otherwise you'll get chaotic 'self-talk'.

Another token-saving technique is to avoid repeating the system prompt in every message. In a session, you can put the system prompt only in the first message, and subsequent messages only contain the user role. However, the DeepSeek API currently does not automatically maintain context; you need to assemble the messages list yourself. Therefore, I added a freeze_system parameter to my DeepSeekClient, which automatically places the system message first and trims the history list to the most recent N turns in subsequent calls, while also incorporating the previously generated summary.

The table below shows the actual effects of different token budget strategies (based on a 5-agent collaboration task with 20 interaction steps):

This table is from measurements in my environment. The summary strategy not only reduces token waste but also improves the success rate, because the model is not disturbed by irrelevant history during processing.

7. Fault Tolerance and Recovery: High-Availability Design for Collaborative Systems

In multi-agent systems, API call failures of a sub-agent are the norm, not the exception. If you let the entire task fail directly, the experience is terrible. Therefore, I designed three levels of fault tolerance: local retry, task degradation, and global restart. Local retry means that when a single API call fails, retry three times with exponential backoff. If it still fails, mark the message as a 'soft failure' and return a specific error code. Task degradation means that when a key agent fails, the Coordinator can temporarily replace that agent's functionality with a normal LLM call, or mark that subtask as 'incomplete' but continue with other parts. Global restart means that when the entire collaboration network deadlocks (e.g., all agents are waiting for each other), the monitor restarts the entire task flow, but retains the intermediate results already obtained.

Deadlock detection is a major challenge in autonomous systems. In my practice, I maintain a 'last active timestamp' for each agent, and a monitoring thread checks every 30 seconds. If all agents have been inactive for more than 5 minutes, it is judged as a deadlock. Then recovery is triggered, usually by canceling all tasks, restarting the Coordinator, and injecting the previous context snapshot. The snapshot mechanism is crucial; you need to design a serializable object that can save all agents' memories and message queue states.

Another hidden pitfall is API 429 rate limiting. With multi-agent concurrency, it's easy to trigger DeepSeek's rate limits. Therefore, I implemented a global token bucket rate limiter that strictly controls the number of API calls per second across all agents. For example, I set a maximum of 60 calls per minute; when the limit is reached, subsequent requests are blocked and queued. This sacrifices some concurrency, but it's much better than being rejected with 429 and then retrying.

8. Testing and Monitoring: From Experiment to Production

Multi-agent systems are difficult to assert because outputs are generated and non-deterministic. But in engineering, we must have a testing strategy. My recommendation is three layers of testing: unit tests (for individual agent prompt templates and utility functions), integration tests (for a small collaboration flow, using recorded API responses), and end-to-end tests (real API calls but with low cost and low temperature, and assertions to check whether key results contain specific entities). To record API responses, I added record and replay modes to my DeepSeekClient, which is especially useful during debugging.

For monitoring, in addition to standard logs and metrics (such as token consumption, latency), I also track each agent's 'decision trajectory', i.e., recording the input and output of each call. This trajectory is stored as JSON Lines files, which can later be used for offline analysis to optimize prompts. For example, I found that when the Researcher receives longer query terms, the factual error rate in its responses increases, so I optimized the prompt to force it to output structured citations.

Finally, I want to emphasize the importance of version management. In a multi-agent system, each agent has its own prompt version, and the collaboration protocol may also change. Therefore, I configure all agent definitions and protocols in JSON and manage them with Git. Each time a new version goes live, I run the old and new systems simultaneously in shadow mode and compare results. Only when the new version outperforms the old on key metrics (such as success rate, latency) across 100 test tasks do I switch. This ensures the system evolves continuously without losing control.

9. Real Case: Building a Research-Oriented Multi-Agent Team

Let me describe a case running in production: an 'industry research assistant' system that integrates 5 agents—Researcher (searches and extracts facts), Analyst (analyzes trends), Compiler (integrates reports), Critic (reviews quality), and Writer (polishes output). They communicate via Redis streams and adopt a hybrid mode. The user inputs a topic, the Coordinator first creates tasks, then the Researcher fetches web data in parallel (via tool calls), the Analyst analyzes numbers, the Compiler generates a preliminary report, the Critic checks for logical flaws, and the Writer finally produces the article.
In this process, the Critic often finds that the Compiler's report lacks data support, so it sends a request to the Researcher for supplementation. Such feedback loops are the essence of autonomy. The entire process takes about 10-15 cycles, with about 30 API calls and a total of about 80K tokens (including summaries). Through stress testing, we evolved it from an initial manual script to a system that can now handle 50 tasks concurrently.

Countless pitfalls have taught us: developing a multi-agent system is like building a microservices architecture, except the services are highly intelligent agents. You need to design retries, timeouts, and circuit breakers for every model call as if calling an external service. Moreover, you must have end-to-end observability; otherwise, an 'agent hallucination' can contaminate the entire chain and be difficult to locate. This is our hard-learned lesson—initially, after the system went live for a week

... we discovered that Researcher occasionally fabricated citation sources, and this false information was used by Analyst for analysis, leading to incorrect conclusions. Since then, we have mandated that Researcher include a list of retrieved URLs in its output, and set up an independent "fact-checker" to filter them.

In summary, the evolution of multi-agent collaboration from orchestration to autonomy is not merely a technical choice but a systems engineering philosophy. To truly harness it, you need to excel in task decomposition, protocol design, context management, fault tolerance and recovery, as well as testing and monitoring. I hope this article helps you avoid some detours. If you have any questions, feel free to discuss them in the comments.