DeepSeek's Open-Source Agent Framework Drops Two Versions in Two Days — Sub-Agent Communication Goes from One-Way Reporting to Two-Way Dialogue

Same open-source Agent framework, two pre-release versions in two days, 17 changes total — 16 are fixes and optimizations, but the one new feature quietly upgrades sub-agents from "one-way reporting" to "two-way dialogue." This seemingly lightweight interface change may be quietly making room for the next stage of multi-agent collaborative architecture.

DeepSeek Harness: An Agent Framework Where Everything is a Plugin

This is DeepSeek's officially open-sourced DeepSeek Harness, built around the core philosophy of "Everything is a Plugin," powered under the hood by Quad Ease. So far, it has accumulated 208,000 Stars and over 24,000 Forks, commanding significant attention in the open-source community.

Agent frameworks are among the most active development paradigms in today's AI application layer. Unlike the traditional "prompt + API call" model, Agent frameworks give large language models the ability to plan autonomously, call tools, and perform multi-step reasoning — enabling them to complete complex tasks like an "intelligent agent." The "Everything is a Plugin" design philosophy draws from microkernel architecture thinking: the framework itself provides only minimal scheduling and communication capabilities, while all concrete functionality (search, code execution, file operations, image generation, etc.) is mounted as plugins. The benefit of this loosely coupled design is that developers can compose capability modules on demand, avoiding the bloat of monolithic architectures while dramatically lowering the barrier for community contributions.

Interestingly, the team is refreshingly candid about where the project stands: it's still in Developer Preview, and breaking changes will keep coming. In the lifecycle of an open-source project, Developer Preview typically sits before or in the early stages of Alpha, meaning core APIs aren't frozen yet — the team reserves the right to adjust interface signatures, data structures, or even the overall architecture at any time. This kind of frequent breaking iteration was commonplace in the early stages of well-known open-source projects like Kubernetes and React. For developers, this represents a "high-risk, high-reward" window: stay close and you can influence the framework's design direction before it solidifies; fall behind and you may face large-scale code migrations when the stable release lands.

The takeaway: rather than waiting indefinitely for a stable version, developers who want to build their own Agent workflows should track the version numbers closely — watching exactly which direction each step takes. This "fast iteration" cadence is precisely the best window for observing a project's true architectural intentions.

Alpha 3: Polishing the Experience, Proactively Trimming Persistence Fallbacks

First, Alpha 3, released August 31 — all 9 changes are about refinement and cleanup.

Rendering and Interaction Improvements

The right-side navigation in the painting interface can now preview and jump to rounds that haven't loaded yet, rendering is more memory-efficient, and code highlighting is more responsive. Pressing Tab in the command menu auto-completes the currently highlighted slash command; backend lag no longer gets misidentified as a network disconnect; and the scheduled task display in the title bar no longer breaks on narrow screens. These are all meaningful quality-of-life improvements for daily use.

Image Handling Fixes

The fixes this round are particularly solid: images that are resent or queued while a painting is running are now correctly written back and reliably delivered; subsequent messages sent to persistent sub-agents now support images; and even images without file extensions (Raw Images) are now recognized correctly.

Removing a Redundant Persistence Path

On the engineering side, one thing was cut: the optional CQ Lite painting storage backend has been removed. One fewer persistence path means one fewer compatibility burden.

Persistence refers to writing runtime state data to disk or a database so it can be recovered after a restart, crash, or migration. In Agent frameworks, the objects typically persisted include conversation history, task queues, tool call logs, and intermediate reasoning results. Supporting multiple persistence backends (e.g., SQLite, CQ Lite, PostgreSQL simultaneously) means maintaining multiple serialization/deserialization logic paths, multiple sets of integration test cases, and multiple potential data consistency risk points. Removing the CQ Lite storage backend superficially reduces deployment options for users, but in substance it's clearing the foundation for a more complex session state model down the line — the lighter the historical baggage, the greater the freedom to evolve the architecture.

This move is worth noting: it's not about adding features, it's about proactively trimming persistence fallbacks to lighten the architectural load for future Agent development.

Alpha 4: Replacing the "Heart" of Sub-Agent Communication

Just one day later, Alpha 4 is the real headline of this update cycle. It has only one new feature — but it carries serious weight.

From "One-Way Reporting" to "Two-Way Dialogue"

The main Agent and persistent sub-Agents can now use Send Message to exchange follow-up messages bidirectionally, replacing the original one-way Report tool.

Don't underestimate this change. In both academic research and engineering practice on multi-agent systems, inter-agent communication patterns generally fall into three categories: one-way message passing (fire-and-forget), request-response, and full-duplex bidirectional conversation. The original Report was a sub-agent unilaterally reporting results back to the main agent after completing work — a classic fire-and-forget pattern where the main Agent passively receives output with no ability to follow up, correct course, or provide incremental guidance mid-task. This pattern works well enough for simple "distribute-and-aggregate" scenarios, but once a task requires multi-round negotiation (for example, the main Agent noticing that the sub-agent's intermediate results are drifting off course and needing real-time correction), the one-way channel becomes a bottleneck.

Send Message, by contrast, enables genuine back-and-forth exchange. It fundamentally upgrades the relationship between Agents from a "top-down command chain" to "equal collaborative partners." This is also the direction that mainstream multi-agent frameworks like AutoGen and CrewAI are converging toward — true multi-agent collaboration requires Agents to engage in sustained contextual exchange, not merely single handoffs of task results.

In short, multi-agent collaboration is evolving from "assign tasks, collect deliverables" toward genuine conversational collaboration. This is often a signal that a product is making room for the next architectural stage — the interface changes first, capabilities follow.

It's worth noting that AutoGen and CrewAI took different approaches to implementing bidirectional Agent communication. AutoGen uses a "conversational programming" model where each Agent is essentially a node that can initiate and respond to conversations, with communication state managed centrally by the framework. CrewAI introduced an explicit "Task Delegation" mechanism, allowing sub-Agents to reverse-query the main Agent for clarification during execution. What both share in common is this: bidirectional communication isn't as simple as "adding a callback" — it requires corresponding architectural support at the event loop, context window management, and concurrent scheduling layers. DeepSeek Harness replacing Report with Send Message is precisely reserving semantic space at the interface layer for this more complex underlying mechanism — once the interface contract changes, the scheduler and state management layer have good reason to evolve accordingly.

Web Connectivity Out of the Box

The accompanying changes are equally telling. The Python SDK, Headless, ACP, and several associated definition Profiles now include WebFetch by default — web connectivity works out of the box.

WebFetch means Agents are no longer limited to local knowledge and pre-training data — they can retrieve real-time information, call third-party APIs, and interact with remote services. However, this also introduces significant security risks: Prompt Injection attacks could manipulate Agent behavior through malicious web content; unrestricted network requests could be exploited for SSRF (Server-Side Request Forgery) attacks; and autonomous web access by Agents could lead to accidental leakage of sensitive data.

At the same time, the web's PTC mode no longer exposes general Workflow tools directly to the model by default — the gatekeeping on which tools get handed to the model has tightened. This reflects a balance between "capability openness" and "security control," a classic implementation of the principle of least privilege: default off for non-essential capabilities, authorization only when explicitly needed.

Breaking Changes Developers Must Watch

For developers currently building Agent integrations, several renames will hit your code directly:

• Session Events has been split into the on-demand SqlEvented and SnapshotEvents
• SessionSkill and SessionLogOffset now have strong type distinctions

Splitting Session Events into SqlEvented (an on-demand SQL event stream) and SnapshotEvents (snapshot events) reflects a pursuit of finer-grained session state management. In multi-agent scenarios, a single "session" may simultaneously contain heterogeneous data: interaction history between the main Agent and multiple sub-Agents, tool call records, intermediate state snapshots, and more. Using a flat event stream to carry all this information means query efficiency and type safety both degrade sharply as session complexity grows. After the split, the SQL event stream is well-suited for persistent storage and historical replay queries, while snapshot events are better for real-time state restoration and checkpoint resumption. Strong typing means type errors are caught at compile time, avoiding the hard-to-trace state confusion that can occur at runtime — especially critical in concurrent multi-Agent collaboration scenarios, where a single type error could cause the entire Agent collaboration chain to fail silently.

These seemingly minor refactors are in fact laying the groundwork for cleaner session state management. If you're building your own Agent integration, make sure to align with these interface changes early.

The Architectural Evolution Logic Behind Two Versions in Two Days

Looking at both versions together: two versions in two days, 17 changes. Alpha 3 locked down the experience and trimmed the persistence fallbacks; Alpha 4 replaced the heart of sub-agent communication.

In rapid iteration, the most valuable step is often not how many features were added, but this kind of seemingly lightweight interface change — first remove it (cut the one-way Report), then make room for a longer-term multi-Agent architecture. This also explains why, among 16 optimizations, the one single new addition carries so much weight.

From a broader perspective, the rhythm of these two versions follows a classic architectural evolution path: first subtract (remove CQ Lite, tighten tool exposure), then make the key replacement (Report → Send Message), then build new capabilities on a cleaner foundation. This "clear the field before building" strategy is common in mature infrastructure projects, and it suggests that the DeepSeek Harness architecture team has a clear long-term vision for multi-agent collaboration.

Risk Boundaries and Quick Start Guide

The boundaries need to be stated clearly: both versions are pre-releases. The team explicitly confirms that no security audit has been completed, sandbox and permission isolation cannot be guaranteed, and interfaces may change at any time. As such, these versions are better suited for exploration and learning than for direct production use.

It's especially worth noting that in the pre-release phase of an Agent framework, security risks come not only from traditional software vulnerabilities, but also from Agent-specific attack surfaces: out-of-bounds tool call permissions, forgery or tampering of messages between Agents, and unexpected model behavior under complex instructions. With sandbox isolation still incomplete, developers should run in isolated test environments and avoid granting Agents access to sensitive data or critical systems.

If you want to run alongside this version, getting started is actually straightforward: a single command spins it up — use NPX to install DS, launch the web interface, and it runs locally on port 3080 by default.

For developers tracking Agent architecture evolution, DeepSeek Harness is an excellent observation sample — publicly demonstrating through each version iteration how a multi-agent framework progresses from "one-way reporting" toward "bidirectional collaboration." Keep a close eye on its version numbers, and you may be able to anticipate the shape of next-generation Agent workflows.

---

Prompt Injection is currently one of the most closely watched attack surfaces in Agent security. The principle is to hide malicious instructions inside external content that an Agent will read (web pages, documents, API responses), tricking the model into deviating from its original task or even leaking the system prompt. Similar to traditional SQL injection, the root cause is that "data" and "instructions" travel over the same channel, making it difficult for the model to distinguish between them. With WebFetch enabled by default, every network request potentially introduces untrusted content. Current industry mitigation approaches include: explicitly "sandboxing" external content (signaling to the model that this is untrusted input), restricting the tool set available to Agents when processing external content, and adding an output inspection layer at the Agent pipeline's exit point. Until DeepSeek Harness completes its security audit, developers should restrict WebFetch access to a whitelist of domains, and avoid mixing high-privilege tools with untrusted external content within the same Agent session.