One Open Source Project a Day (No. 237): DeepSeek Bot — Turning DeepSeek Harness Into a Team of Bots With Memory, Group Chat, and Task Handoff

Introduction

"DS Bot turns DSH into bots. You create your own bots, then talk and work with them."

This is the 237th article in the "One Open Source Project a Day" series. Today's project is DeepSeek Bot (DS Bot for short).

Working with a single long-running AI session eventually hits a common problem: the context window fills up, memory disappears the moment you close the session, and if you want a dedicated "specialist" role for a certain kind of task, you have to rebuild its context from scratch every time. Worse, if you want multiple "specialists" to collaborate on a complex task, most tools today simply don't offer a ready-made mechanism for several long-lived roles to talk to each other and hand off work.

DeepSeek Bot, as a plugin for DeepSeek Harness (DSH), productizes exactly this idea. Each bot is really an independent DSH session, but with memory that persists across sessions. Multiple bots can form a group chat and delegate tasks to each other via @-mentions. There's also a privileged Main Bot ("Chief") that oversees other bots and group chats, and can even walk a new user through the entire setup process.

1.9k Stars, Apache-2.0 License, 280 commits. The project is notably candid in its acknowledgments section, listing multiple sources of design inspiration — including OpenAI Codex, OpenCode, and Hermes Agent — explicitly clarifying it borrowed ideas, not code.

What You Will Learn

• How the Bot / Main Bot / Group Chat three-layer architecture collaborates to solve the "specialist roles working in isolation" problem
• The cross-session persistent memory mechanism, and how it fundamentally differs from a temporary context window
• The admin bot's default-response pattern in group chats, and how @-mentions bypass it to delegate directly
• The Capabilities shared library: how MCP servers, Skills, and Packs get reused across multiple bots
• How the project candidly credits design inspiration from multiple external projects instead of hiding its influences

Prerequisites

• Basic understanding of the DeepSeek Harness (DSH) plugin system
• Familiarity with how an AI agent session works
• Optional: having used group-chat-style collaboration tools (like a Slack bot) will make the group chat section easier to follow

Project Background

What It Is

DeepSeek Bot's official positioning: "a bot plugin for DeepSeek Harness (DSH). It turns DSH into bots. You create your own bots, then talk and work with them." The repo description is even more direct: "A team of long-lived bots for DeepSeek Harness, with main bots, bot-to-bot messages and group chats."

The project explicitly states it is an independent community project: "DS Bot is an independent community project. It is not an official DeepSeek product, and it is not affiliated with, endorsed by or sponsored by DeepSeek."

Team and Background

• Package name: ds-bot
• License: Apache License 2.0
• Current status: v0.1_preview, targeting DSH 0.2.0-rc.2
• Build tool: esbuild (used to bundle the plugin's interface code)
• Supported platforms: DSH Desktop (Windows, macOS), DSH Web (Windows, macOS, Linux, requires Node.js 22.19+ and pnpm)

Project Stats

• ⭐ GitHub Stars: 1,900+
• 🍴 Forks: 180
• 👀 Watchers: 7
• 🐛 Open Issues: 45
• 🔀 Open PRs: 3
• 📊 Commits: 280
• 📄 License: Apache-2.0

What It Does

The Problem It Solves

The pain points of long-term use of a single AI session:
  Limited context window → the longer the session, the more it
  "forgets" earlier information
  Close the session → all accumulated preferences/habits are lost
  Want multiple "specialist roles" to collaborate → no existing
  mechanism for them to talk to and hand off work to each other
 
DeepSeek Bot's approach:
  Each bot = an independent DSH session + persistent cross-session
  memory
  ↓ memory retains user preferences, applied to future tasks
  ↓ multiple bots form a group chat, delegating tasks to each other
    via @-mentions
  ↓ a Main Bot holds administrative privileges, overseeing other bots
    and group chats
  ↑ "specialist roles" are no longer one-off context — they become
    long-lived, collaborative team members

Use Cases

1. A long-lived assistant dedicated to a specific type of task

   • E.g., a bot dedicated to copywriting, a bot dedicated to coding — each retaining memory of preferences specific to its domain

2. Multiple "specialists" collaborating on a complex task

   • Use group chat to let different bots each handle part of a task, delegating subtasks to each other via @-mentions

3. New users who want to quickly set up a multi-bot configuration

   • Talk directly to the Main Bot, which walks through the initial setup of bots and group chats, instead of reading through documentation

4. Users who want to share tool capabilities across multiple bots

   • Use the Capabilities shared library to attach the same set of MCP servers and Skills to different bots for reuse

5. Users who need to track token consumption across multiple bots

   • View token consumption broken down by time, bot, and model in Settings → Usage

Quick Start

Prerequisite: DSH installed and configured with at least one model.

DSH Desktop installation (Windows, macOS):

1. Sidebar → Plugins → Add plugin
2. Enter the package name ds-bot (mainland China users can select the
   mirror registry)
3. Select Install, then Enable now (restart DSH if prompted)

Also supports installing via a downloaded .tgz release package or a GitHub path reference (requires Git).

DSH Web installation (Windows, macOS, Linux, requires Node.js 22.19+ and pnpm):

npx @deepseek-ai/dsh@0.2.0-rc.2 plugin --profile web add ds-bot
npx @deepseek-ai/dsh@0.2.0-rc.2 web

Core Features

1. Bot

Each bot corresponds to its own chat/work window, with its own independently selectable and switchable model. Under the hood, "every bot is actually a DSH session, using DSH's tools and models" — users don't need to worry about the underlying session details; they just interact with a fixed bot window.

2. Main Bot ("Chief")

A privileged administrative bot, pre-installed on first launch, responsible for managing other bots and group chats, and guiding new users through the setup process. The official guidance: "have a question? Ask the main bot."

3. Group Chats

Multiple bots collaborating within the same conversation. Each group chat has an admin bot that handles messages by default and can delegate tasks to other bots; users can also directly @-mention a specific bot to bypass the admin and talk to it directly.

4. The Handoff Mechanism

Any bot can delegate a task to another bot using @-mention syntax. The receiving bot works independently while the group conversation continues; progress is surfaced in the group chat, the sidebar, and the bot's own chat window. Once the task is complete, the result posts back to the group chat, and the originating bot responds. Users can halt a task mid-way via the group's details panel.

5. Persistent Memory System

Bots retain memory of user preferences across sessions, applying them to future tasks. Memory can be edited through the bot's details page, or by directly asking the bot in conversation to update it.

6. The Capabilities Shared Library

Located at Settings → Capabilities, a shared repository of MCP servers, Skills, and Packs. Capabilities are attached to a specific bot via settings and take effect starting from that bot's next message (in both solo and group chats). Local MCP commands require explicit user approval before execution. Editing or deleting a capability currently in use by other bots is restricted to the user or a Main Bot.

7. Usage Tracking

Settings → Usage displays token consumption broken down by time, bot, and model.

8. Local Data Storage

All data is stored locally in bot/ and sessions/ within the DSH home directory (default ~/.dsh), and persists even if the plugin is uninstalled.

A Deeper Look

What Problem the "Bot = Session + Memory" Combination Actually Solves

The core statement in DeepSeek Bot's architecture is: "every bot is actually a DSH session, using DSH's tools and models." But if that were all there was to it, a bot would be no different from an ordinary session — the real difference is a persistent memory layer stacked on top of the session mechanism.

Ordinary session model:
  Session = temporary context + tool-calling capability
  ↑ closing the session = context wiped
  ↑ to keep a "specialist role" persistent, the user has to manually
    re-explain background info every single time
 
DS Bot's bot model:
  Bot = DSH session (temporary context + tool-calling capability) +
  cross-session persistent memory
  ↓ memory exists independently of a single session's context window
  ↓ user preferences and historical habits get recorded and applied
    to future tasks
  ↑ a "specialist role" is upgraded from one-off context to a
    long-lived team member

The key to this design choice: it doesn't try to solve the "forgetting" problem by enlarging the context window — instead, it peels "memory" out of "part of the context window" and turns it into an independent, persistent data layer. This is a more pragmatic engineering choice — a context window is inherently finite, but a structured memory file can grow essentially without bound (limited only by disk space), and its retrieval efficiency is far more controllable.

The "Admin Default-Response" Pattern in Group Chats Lowers the Cognitive Load of Multi-Bot Collaboration

One detail worth noting in the group chat design: each group chat has an admin bot that responds by default — messages a user sends are handled by it by default, and it decides on its own whether to delegate to other bots. Only when the user actively @-mentions a specific bot does this default flow get bypassed.

Without a default admin, every message in a group chat would need the
user to explicitly specify a recipient:
  The user has to figure out "who should this message go to" every
  single time
  ↑ cognitive load grows linearly with the number of bots
 
DS Bot's admin default-response pattern:
  The user sends a message normally → the admin bot receives it and
  decides whether delegation is needed
  ↓ the user doesn't need to figure out which bot to approach every
    time
  ↑ only when the user clearly knows who to approach do they use
    @-mention to bypass the admin

This design compresses the default complexity of "multi-bot collaboration" down to something close to the level of "a single-bot conversation" — most of the time, the user just talks normally and the admin handles routing; only when precise control is needed does the user explicitly specify a target via @-mention. The project's documentation also candidly notes that group chats cost more overhead than solo bot conversations — which is precisely the motivation behind the admin-delegation pattern: using delegation to manage the extra cost that multi-bot collaboration brings, rather than requiring the user to manually orchestrate every bot by hand.

Completing Configuration Through Conversation, Not Documentation

The design philosophy section includes a direct piece of advice: "I strongly recommend that you set up your other bots and group chats by just talking to a bot." This means the Main Bot itself takes on the role of a "configuration interface" — users don't need to dig through complex configuration documentation; instead, they complete setup through natural-language conversation, guided by the Main Bot.

What's notable about this design choice: it turns "configuring a complex multi-bot system" into a concrete application of the system's own core capability — since the bot system itself exists for conversational collaboration, "configuring the bot system" should also happen through conversation, rather than dropping into a traditional form-based configuration screen. It's a design consistency that "eats its own dog food."

A Candid Acknowledgment: Borrowed Ideas, Not Copied Code

DeepSeek Bot's acknowledgments section lists a fairly detailed breakdown of which design ideas were borrowed from which projects, explicitly stressing that these are "ideas," not code:

This kind of practice deserves credit in the open-source community — many projects are clearly inspired by other projects' designs, yet rarely systematically document "whose idea this borrowed from" in their documentation. DeepSeek Bot puts this "intellectual lineage" out in the open, which is both a form of respect toward the original creators and makes it easier for users to understand where exactly this project sits within the broader design space of multi-agent collaboration — it isn't invented from nowhere, but a synthesis built on top of multiple already-validated design patterns.

An Explicit Disclaimer: Your Own Model Quota, Verify Important Actions Yourself

The project's documentation also directly reminds users: bot actions consume the user's own model quota, and bots can read/write files or execute commands upon request — "check important actions yourself." This kind of plain, direct risk disclosure, paired with the statement that it's "an independent community project, not an official DeepSeek product," reflects a form of transparency that takes user responsibility seriously, rather than using vague language to downplay potential risk.

Project Links and Resources

Official Resources

• 🌟 GitHub: https://github.com/Fei2411/DeepSeek-Bot
• 📄 License: Apache License 2.0
• 📝 Changelog: CHANGELOG.md in the repo
• 🤝 Contributing Guide: CONTRIBUTING.md / CONTRIBUTING.zh.md in the repo

Related Resources

• DeepSeek Harness (DSH) — the underlying plugin system and session/tool/model framework DeepSeek Bot depends on
• esbuild — the bundling tool used for the plugin's interface code

Summary

Key Takeaways

1. "Bot = session + persistent memory" is the core innovation: memory is peeled out of the finite context window and turned into an independent, persistent data layer
2. The group chat admin default-response pattern lowers the cognitive load of multi-bot collaboration: as simple as a single-bot conversation most of the time, with @-mention available for precise control
3. System configuration happens through conversation, not a traditional form interface: the Main Bot itself takes on the role of guiding setup, reflecting design consistency
4. It candidly lists multiple sources of design inspiration: from OpenAI Codex to Hermes Agent, explicitly distinguishing "borrowed ideas" from "copied code"
5. A plain-spoken risk disclosure and community-project statement: it doesn't hide the two key facts that it "consumes your own quota" and is "not an official product"

Who This Is For

• DeepSeek Harness users who want long-lived specialist roles: instead of one-off sessions that need their context rebuilt every time
• Users who need multiple AI roles to collaborate on complex tasks: achieving division of labor through group chats and the task-handoff mechanism
• Users who want to complete system setup through conversation rather than config files: the Main Bot's guided setup experience is more approachable
• Developers interested in multi-agent collaboration architecture: can reference its specific design patterns around admin delegation, persistent memory, and shared capabilities

One-Line Verdict

DeepSeek Bot doesn't try to make a single AI session smarter — through persistent memory and group chat collaboration, it upgrades a "one-off conversation" into a "long-lived team that can hand off work to each other," which might be a solution closer to real collaborative needs than simply making the context window bigger.

Check out PrimeSkills — a curated marketplace of AI agents and skills that have been validated in real-world, enterprise-grade workflows. No fluff, just what actually works.

Find more useful knowledge and interesting products on my Homepage