DeepSeek Bot: Turning Multi-Agent Demos into Runnable Systems via Runtime Design

Demo vs. Runnable System: The Real Gap

Multi-agent demos are easy to build: assign role prompts, add avatars, and let agents speak in turn. The hard part is the second run — can yesterday's task resume? Does the system know where a failed agent stopped? Who should speak next? Must other agents reread the entire context? How are API keys given to tools without entering chat history? Will desktop and web clients overwrite each other's state?

These unglamorous questions determine whether agents are merely a showpiece or a continuously runnable system. This analysis of DeepSeek Bot (DS Bot) source code reveals how it addresses them.

TL;DR

DeepSeek Bot is a community plugin for DeepSeek Harness (DSH), version 0.1.2 (v0.1 preview), not an official DeepSeek product. Analysis based on commit 508ad823 (64 commits ahead of v0.1.2), targeting DSH 0.2.1-alpha.1.

It does not create a new agent runtime; each Bot lives on a long-lived DSH root Session, reusing model, tools, permissions, event log, and execution loop.

Group chat core is not multiple models speaking together, but message delivery semantics: normal collaboration queues to next turn, urgent correction inserts into current turn, dangerous actions can be cancelled.

Context splits into three mechanisms: current conversation (checkpoint/handoff), old chat retrieval (SQLite FTS5), and long-term memory (MEMORY.md + journal.jsonl).

The unglamorous parts make it runnable: write coordination, corrupted state protection, permission presets, secret isolation, task cleanup, usage stats, and explicit limitations.

Multi-agent is not inherently superior; when tasks cannot be split or context heavily overlaps, extra agents add coordination and token cost.

Boundary Clarification: Community Project, Early Version

DS Bot, by developer Fei2411, is an open-source DSH plugin under Apache 2.0. README states it is independent, no affiliation with DeepSeek. As of 2026-10-12, npm version is 0.1.2, marked v0.1 preview, validating DSH 0.2.1-alpha.1. The analyzed HEAD is 508ad823. It is not a stable production product, but early code shows clearly which problems the author puts into the system and what trade-offs are accepted.

The Demo–System Divide Is Not Agent Count

On first run, demo and system look alike: roles, messages, tools, answers. Differences appear on second run, first failure, or first concurrent write. The following dimensions contrast concerns:

Dimension Comparison

Participants : Demo cares about how many roles; runnable system must answer how identity persists and whether model can be swapped.

Collaboration : Demo cares if they can speak to each other; runnable system must answer who receives message, delivery under load, when to stop.

Context : Demo cares if current answer is coherent; runnable system must answer how to continue when window full, how to retrieve old records.

Execution : Demo cares if tools can be called; runnable system must answer who constrains permissions, secrets, side-effects, failures.

State : Demo cares what is visible on page; runnable system must answer if restart can recover, how to handle corruption and concurrent writes.

Cost : Demo cares if effect looks good; runnable system must answer how many extra calls and duplicate context per added agent.

DeepSeek Bot's source code systematically answers the right column. The earlier article "Multi-Agent Is Not a Virtual Company" framed multi-agent as information architecture: context boundaries, information flow, stop conditions. Here that methodology becomes concrete: Session, message queue, group turns, permissions, state files.

The main thread: long-term collaboration cannot rely only on role prompts; runtime must govern identity, process, messages, memory, and permissions.

Layer 1: Bot Lands on Session, No New Agent Runtime

The key line is in the plugin entry comment: Every Bot is one root Session. Each Bot is a normal DSH root Session. DS Bot does not build a parallel model-calling, tool-executing, session-storage stack. It adds name, role, instructions, model, avatar, team relations, but task execution still enters DSH's existing Agent Loop.

Bot handles "who it is"; Session handles "how it works".

In ds-bot/index.js the plugin loads storage, model, permissions, turns, message delivery, team roster, prompts, tools, group chat, memory, long-conversation segmentation, secrets, scheduled tasks, browser, and usage stats — all hooked onto existing DSH services and events, no separate kernel.

This matters for long-term evolution: today Writer uses DeepSeek, tomorrow can switch models; its name, duties, memory, history need not rebuild with the reasoning engine. Model is a replaceable part; Bot is the enduring identity users face.

DSH Session is not just chat text. Official docs define Session as an append-only, typed SessionEvent log. A Turn contains multiple Steps; user messages, system messages, model replies, failed attempts, tool calls, tool results, and turn boundaries all become events. Next turn's model input is re-derived from this log, not from a separate drift-prone "chat history".

Thus Bot's long-term existence has two pillars:

Name, role, model, team relations — answers "who is this";

Session Event Log — answers "what has it actually done".

These two layers must not be mixed. Only role without process leaves debugging to guesswork; only process without enduring identity makes multi-task and memory attribution unstable. Pinning Bot to Session connects identity model and execution fact.

Layer 2: Collaboration Becomes a Message Protocol

Multi-agent demos love round-robin speaking. Three common problems: every agent re-reads same context; agents tend to chime in even without new info; when task goes sideways, hard to classify a message as new task, supplemental info, or urgent correction.

DeepSeek Bot adds a thin message protocol.

Default to Admin, Avoid Everyone Rush

Each group has an admin. Default mode: ordinary messages go to admin first; admin judges if another capability needed, then @ s the member. User can also directly mention a Bot. An everyone mode exists for sequential replies, but admin still speaks first. When a member's turn comes, if it has nothing new, it returns [PASS] — this does not become another polite agreement.

This controls not just speaking order but context and cost spread. Default wakes only one Bot, converging the problem first; only when specialization needed is necessary information routed out. It does not guarantee effective collaboration, but avoids defaulting to "more people read, more people speak".

Normal, Urgent, Stop — Three Distinct Temporal Contracts

Source code's message_bot is telling. Sender must write a self-contained message because receiver cannot see sender's full session. It calls DSH's agent.followup: if target is busy, message queues after current Turn; if idle, starts next turn. Reply can return to sender or let target Bot reply directly to user.

Urgent messages take another path. Only Main Bot can call interrupt_bot, using agent.steer. It inserts a reminder into target Bot's current Turn's next Step, suitable for correction, direction change, or preventing a not-yet-happened dangerous action.

If reminder insufficient, Main Bot calls stop_bot via agent.cancel to end current Turn. Messages queued on that Turn are discarded; system then opens a new turn telling the Bot why it stopped.

These are not three similar buttons but three temporal contracts: message_bot: this matter queues after current work; interrupt_bot: this constraint must enter current work's next step; stop_bot: current work must not continue.

On 2026-10-01 we compared Pi vs DSH on steering, follow-up, next-step, next-turn — how Agent Loop decides continue and close. DeepSeek Bot lifts that same temporal semantics to inter-Bot level. Messages must not only "arrive" but declare whether they belong to now or to the next thing.

Code also limits Bot message chain max hops to avoid ping-pong delegation. Messages sent to a Bot's private Session do not automatically rewrite its concurrent group work. Control surface is small but boundaries are real.

Group Context and Private Context Separated

When a member joins a group, it uses an independent hidden Session for that group. Group chat can read group messages but does not automatically get that Bot's private chats with user. The group "room" maintains ordered log and turns; actual model calls happen in each member's Session; members speak in order, next starts after previous finishes or [PASS].

This is both context isolation and permission isolation. Same Bot can keep different working sets in different occasions, not dumping all experiences into every group. For long-term agents, this isolation is practical: share too little, collaboration fails; share too much, privacy, cost, and noise spiral.

Thus DeepSeek Bot's group chat resembles a moderated message router, not a round-table where everyone must opine. Members can @ next in reply, but per-turn and per-member limits exist; ordinary members cannot use @all to trigger unlimited "group chat storms".

Here, number of roles matters less. What matters is whether every message has explicit target, timing, visibility scope, and stop condition.

Layer 3: Context Gets Its Own Lifecycle

As agents run longer, the first bottleneck is usually not model capability but context management. In the 2026-10-08 Harness teardown we said context compression is not essay summarization but state saving. DeepSeek Bot gives a more daily-use implementation.

Three things are easily conflated: how current task continues, how past details are retrieved, what should be remembered long-term. DeepSeek Bot does not lump them all as "memory" but splits into three layers.

Current Task: Checkpoint or New Segment

Each model has its own context window. DS Bot calculates available capacity from model-reported contextWindow; when a turn ends and exceeds the checkpoint line (default 80% of available window), an independent small model acts as context steward.

It makes a single judgment:

Work still in progress → compress earlier content into checkpoint, continue in current Session;

Work reached a stage endpoint → let Bot write a handoff note, switch to new Session part.

Why not always summarize? Because "halfway through" and "this segment done" need different retained information. Former cares about current progress, dependencies, next step; latter suits handing off outcomes and unfinished items to next phase. Source even requires handoff to keep full paths, identifiers, error messages, and outstanding requests, avoiding vague topic summaries.

A detail worth noting: checkpoint does not only save model-generated summary. Recent user messages are appended verbatim after the summary. Summaries inevitably compress tone, constraints, exceptions. Carrying recent user original words forward leaves a fact zone untouched by re-interpretation.

Old Chats: Search When Needed, Don't Carry Always

Compressed content and earlier Session parts don't disappear. They enter local SQLite FTS5 full-text index; Bot can search its own old chats via read_own_chat when needed.

Logic resembles how we handle work files: desktop holds current files, old materials go to archive, retrieve when needed. Context window is a working set, not a warehouse.

This also explains why "infinite context window" cannot replace history management. Larger window means more repeated content, truly important info drowns. Searchable history and current context are fundamentally two different things.

Long-Term Memory: Keep Only What Next Session Still Needs

Cross-session user preferences, decisions, corrections, and facts enter Memory.

Each Bot has its own memory; team has a shared memory. MEMORY.md stores content needed in every conversation; longer details go into topic files; journal.jsonl records every addition, replacement, deletion.

Project defaults to a memory review each turn end, model judges if new content worth keeping. It sets caps on single memory item, main file, topic count, total size, and rejects content resembling keys, tokens, or ID numbers.

Another engineering trade-off: Memory freezes into system prompt at Session start. Mid-session memory updates do not repeatedly rewrite the already stable prompt prefix; new content takes effect at next segment or after checkpoint, while immediately queryable via recall.

This sacrifices a bit of "just-written instantly appears in system prompt" immediacy for more stable Prompt Cache and predictable session state.

Three layers together:

Context Lifecycle Layers

Current Working Set : Problem solved — how to continue the task at hand. Main mechanism — checkpoint / handoff / Session part.

Historical Archive : Problem solved — what exactly was said/done before. Main mechanism — SQLite FTS5 / read_own_chat.

Long-Term Memory : Problem solved — what is still worth knowing next time. Main mechanism — MEMORY.md / topic / journal.

This is one of the most endorsed designs in the project. It does not invent an omnipotent "super memory" but acknowledges information has different lifespans. An agent that can work long-term must not only remember, but know what stays in front, what goes to archive, what deserves to carry into the next session.

Layer 4: Capabilities Governed by Runtime, Not Bot's Conscience

When agents only chat, errors are bad answers. Once they read files, run commands, browse web, use API keys, errors become real side-effects. A prompt line "please be careful" is insufficient.

DeepSeek Bot pushes many capability boundaries back to runtime. Consistent with earlier Harness articles: model proposes next step; system decides what this step can see, modify, and how results persist.

Permissions Follow the Bot

Each Bot can choose DSH permission presets: read-only, workspace, full access. This permission applies to its own chats, group Sessions, and subsequently created conversation parts.

Thus "what Writer can do" is not just role description but actual tool boundary. Model can be induced, prompts can be polluted by web content, but runtime permission remains another constraint.

Browser Has Isolated Partition, Currently Read-Only

In DSH Desktop, each Bot gets its own browser storage partition; cookies and login states don't mix by default. read_browser reads structured DOM, not just a screenshot; password, credit-card, and one-time-code field values are not read.

Current read_browser tool is read-only: cannot click, input, scroll, or navigate for user. It also cannot read cross-origin iframes, Canvas, or closed Shadow Roots.

This looks less "automated", but from early-system risk control, clarifying read boundaries first, then gradually opening write operations, is a steadier sequence.

Secrets Stay Out of Chat, But Not an Absolute Vault

When Bot needs API Key or Token, it calls request_secret; UI shows a Secret card. User-entered value goes only into authorized Bot's Shell environment; model uses variable name; before tool results persist and before requests go to model, system replaces secret literal with placeholder.

Source and docs don't overstate this.

Secrets stored in local secrets.json with atomic write and 0600 file permissions, but currently unencrypted; masking relies on exact literal match — encoded, split, or reversed values may still leak; if DSH Web opens via LAN HTTP, secrets travel network in clear.

"Model cannot see input box value" and "key will never leak" are two different things. Project writing this distinction out is more credible than "runs locally, therefore secure".

Layer 5: System Must Face Restart, Corruption, Concurrent Writes

Previous layers answer how agents work. Deeper lies a set of traditional, easily overlooked engineering problems: what if state file corrupts? Two processes write together? Bot deleted but background tasks remain?

These details decide if system can run long-term unattended.

Team State and Session Facts Stored Separately

DS Bot's state.json saves Bots, groups, inter-Bot messages, preferences, pending questions; actual chat and execution history remain in DSH Session under default ~/.dsh/sessions/. Full-text index, usage, Memory, Secret, diagnostic logs each have own files.

Thus backup cannot just copy bot/ directory — team config remains but chat facts lost. Docs explicitly require backing up at least bot/, sessions/, and workspace storage.

This is not a flashy feature but reflects boundary: team orchestration state relates to execution facts but is not the same data.

Usually Single Writer, But Source Keeps Availability Fallback

DSH Web and Desktop default share ~/.dsh. If two processes write entire state.json simultaneously, later write likely overwrites earlier changes.

DeepSeek Bot uses state.lock to coordinate writes. Normally, first process loading team acquires lock; other instance becomes read-only and follows file changes; when lock holder exits, read-only instance can take over on next request. If lock acquired but later discovers ownership seized by another process, save fails with ELOCKLOST, no further overwrite.

Current main has a notable exception: if filesystem cannot create or use locks, system warns but still allows save. Comment is blunt — cannot let entire team halt because lock unavailable. Cost equally clear: if two DSH instances share same directory, they may still overwrite each other.

This is not strict distributed consistency; more like a local tool's trade-off between availability and data risk. Normal path tries to keep single writer; abnormal filesystem returns choice to user with explicit warning.

On Corruption, Stop Rather Than Overwrite with Empty Data

Current source on encountering malformed state.json first copies a timestamped broken backup, then adopts empty in-memory state; if backup fails, file unreadable, or data from newer version, system enters read-only state awaiting user repair or upgrade.

Save writes to temp file then atomic rename; if lock lost mid-write, write fails instead of continuing overwrite.

No simple "fail closed" slogan. When corrupted copy can be preserved, it prioritizes restoring system usability; when evidence cannot be kept, it refuses write. Pragmatic boundary: recovery must not silently erase original file.

Lifecycle End: Background Tasks Must End Too

Current main includes a fix not yet in 0.1.2: previously deleting a Bot or group left its early Session's scheduled tasks still running. Now deleting the entity calls stopActivity to archive related Sessions, stopping any pending scheduled tasks within.

This looks like a routine bug fix but reflects a crucial lifecycle question: When the executor no longer exists, who takes over the background obligations it created?

If system cannot answer, "long-term agent" easily becomes a pile of tasks nobody knows are still running.

It Solved "How to Collaborate", Not Yet "How to Jointly Deliver"

Easy to equate DeepSeek Bot with a complete multi-agent work platform. Need to temper.

From current source, it does solid information partitioning : each Bot has own identity, private chat, group Session, memory, browser partition, permissions; message timing, visibility, failure stop have clear semantics.

But work partitioning is another matter. No universal shared task ledger describing task dependencies, assignees, artifact versions, acceptance results, handoff status; no resolution for concurrent code/document edits, conflict merge, final release by multiple Bots. state.json mainly stores team orchestration state, not a project management system, let alone a transactional workflow engine.

This doesn't diminish its value, just positions it: DeepSeek Bot has outlined "how several long-term Bots on one Harness speak clearly, catch, and stop"; "how they work in parallel around same deliverable and finally merge back" still needs external repo, task system, verification pipeline, release mechanism.

In other words, it's closer to a runnable personal agent team foundation, not yet an unmanned software factory.

Multi-Agent Cost: Mostly Duplicate Context and Coordination

Back to an unglamorous reality: multi-agent is expensive.

DeepSeek Bot's own README warns group chat significantly increases token consumption. It provides Usage page to view tokens by time, Bot, model, but currently only counts tokens, no direct cost conversion.

Anthropic's multi-agent research system retrospective mentions their multi-agent system averaged ~15x tokens of normal chat, single agent ~4x. Number from another system, not directly applicable to DeepSeek Bot, but reveals cost sources starkly: parallel agents not only each reason, but also repeat context reads, handovers, summaries, verifications.

Not all tasks suit parallelism.

Open-ended research can split into relatively independent search directions, agents share few intermediate results. Code tasks usually share same state, modifications have dependencies; blindly adding agents creates conflicts and duplicate work.

When evaluating multi-agent, I first check for truly independent workstreams:

Can different Bots use different contexts, models, or tools?

Can subtasks advance independently most of the time?

Is aggregation cost lower than single agent serial completion?

Is there explicit handoff artifact, not copying entire chat back and forth?

If these conditions don't hold, a single more capable, cleaner-context agent is often cheaper.

DeepSeek Bot's default — admin receives ordinary messages, others join on demand — plus [PASS], message hop limits, usage stats, can be seen as a direct response to cost. It doesn't prove more Bots are better; it builds infrastructure for "when multiple are truly needed, how to waste less".

From Source Code Review: It Patched Five Runtime Chains, Not Avatars

Strip the UI, DeepSeek Bot's work converges to a plain chain:

Define Bot → Enter Session → Route Collaboration → Extend Context → Constrain Side-Effects

Along this chain, four long-term ledgers emerge:

Four Ledgers

Identity Ledger : Question answered — who is acting, still same if model swapped. Main code landing — Bot config, team roster, group relations.

Process Ledger : Question answered — what was done, evidence for failure/recovery. Main code landing — DSH Session Event Log.

Memory Ledger : Question answered — what stays current, what archives, what persists long-term. Main code landing — checkpoint, FTS5, Memory.

Permission Ledger : Question answered — what can be seen, changed, executed on whose behalf. Main code landing — permission presets, browser partition, Secrets, state lock.

Message routing runs through all four ledgers; cost and observability wrap a reality constraint around them.

Putting this code together, final judgment:

Multi-agent moving from demo to runnable system is not about increasing from 3 roles to 10, but from "model chats however it wants" to "runtime explicitly manages every state change".

Who creates identity, who receives message, when context compresses, how memory updates, what permissions govern tool execution, who writes state, how tasks clean up after entity deletion — the fewer these rely on model's improvisation, the closer to runnable.

Conclusion

DeepSeek Bot is still very early. DSH is alpha, plugin is v0.1 preview; browser read-only, secrets unencrypted, group chat token overhead high, data formats and tools may change. Treating it as a mature Personal Agent platform is premature.

But as an open-source sample of "how to ground multi-agent on Harness", it is worth reading.

It didn't wrap DSH in a massive new framework; instead on existing Session, Agent Loop, tools, plugin mechanism, it added identity, routing, context lifecycle, local state management. Many designs are inconspicuous: a lock, a journal, a [PASS], an atomic rename, cleaning background tasks when deleting entity.

These details won't make demo more dazzling, but make system less ambiguous.

Looking back, this year we wrote Harness, Loop, Context, State, Memory — the theme was never making agents look smarter, but making what they did unambiguous. DeepSeek Bot adds another piece: when agents are more than one, identity, messages, and stop semantics must also enter the system.

The true watershed for Personal Agent may not be whether it answers a complex question today, but whether tomorrow it can still clearly say:

Who am I, where did the task reach, is the evidence still there, what can I do next, and what must I not do.

DeepSeek Bot hasn't solved all these completely, but at least stopped leaving them to prompts and model improvisation.

That's more interesting than a few more moving avatars.

References

DeepSeek Bot project (https://github.com/Fei2411/DeepSeek-Bot)

@Zhuangxg: Discussion on group chat default admin and effective collaboration (https://x.com/Zhuangxg/status/2108981572657701067)

DeepSeek: DeepSeek Harness Sessions documentation (https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/subsystems/session.md)

DeepSeek: DeepSeek Harness Architecture (https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/architecture.md)

Anthropic: Building Effective AI Agents (https://www.anthropic.com/engineering/building-effective-agents)

Anthropic: How we built our multi-agent research system (https://www.anthropic.com/engineering/multi-agent-research-system)

Previous articles by author on Harness, Loop, Context, State, Memory, Pi vs DSH, Coding Agent Harness