DeepBot: a TypeScript and Electron agent harness with Feishu as its front door

The gap DeepBot targets: agents that live inside an existing enterprise chat client

Most agent frameworks assume you will build a web UI or call an API. DeepBot inverts that. Its external communication surface is Feishu, with the README also listing WeChat and WeCom messaging tools, so the assistant appears where employees already are instead of asking them to open another tab. The stated audience is enterprise productivity: document processing, data analysis, system monitoring and cross-department coordination. The repository description adds personal productivity as a second use case. That pairing is worth noting because the two audiences want different things from the same binary. A personal user wants a desktop app that starts with pnpm run dev. An enterprise user wants a deployment story, an access model, and an upgrade path. The README serves the first audience well and the second audience unevenly. The homepage at glint-mvt.com/deepbot is referenced but its contents are not part of this material, so anything hosted there is outside what can be assessed here.

One agent runtime per tab, coordinated by a gateway

The architecture diagram shows a four-layer stack. At the top is an Electron UI with Feishu as the external channel. Below it sits a Gateway that owns session management, a message queue, connector management and cross-tab message routing. The Gateway fans out to N sessions, each bound to a tab. Each session gets its own Agent Runtime, and each runtime holds independent memory and context. The runtime handles orchestration, an auto-continue loop that the diagram caps at 100 iterations, and operation tracking with a maximum of 3 retries. That retry ceiling is the most concrete reliability statement in the README, and it is a design decision rather than a guarantee: a tool that fails three times stops failing and starts reporting a failure to the agent. The cross-tab calling tool is what makes the isolation useful rather than merely tidy. A session handling document analysis can hand a task to a session that owns a browser tool, without either session sharing memory. The cost is that cross-tab coordination is a message-passing problem, and the README does not describe ordering, delivery guarantees or what happens when the target tab is closed.

System prompts assembled from markdown files at runtime

The prompt assembly layer is the part of DeepBot most worth copying. Rather than hardcoding a prompt string, the runtime composes it from AGENT.md for the base agent behaviour, TOOLS.md for tool instructions, custom tool instructions, MEMORY.md for global memory, memory-<tab>.md for per-tab memory, and SKILL.md for skills instructions. The diagram labels this dynamic loading with live updates, which means editing a markdown file changes agent behaviour without a rebuild. This is a real operational advantage: a support team can adjust tone or add a constraint in MEMORY.md and see the effect in the next turn. It is also a real risk. Six files contribute to one prompt, and nothing in the README describes precedence when they conflict, how large the assembled prompt grows, or whether a malformed SKILL.md fails loudly or is silently skipped. If you adopt DeepBot, the first thing to inspect in the source is the assembly order, because that determines which file wins.

Getting it running: pnpm scripts, platform builds and the .env keys for signing

The README gives a short path from clone to running app. You need Python 3.11 or later. Node.js 20.0.0 or later and pnpm 10.23.0 or later are marked optional and are used for running JS scripts. The commands are git clone https://github.com/kevinluosl/deepbot.git, cd deepbot, pnpm install, then pnpm run dev. For a distributable desktop build the scripts are pnpm run dist for all platforms, pnpm run dist:mac, pnpm run dist:mac:local, and pnpm run dist:win. The distinction between dist:mac and dist:mac:local is documented in a table: the signed variant uses an Apple Developer ID, passes notarization and clears Gatekeeper, while the local variant does none of that and triggers security warnings. The signed build reads APPLE_ID, APPLE_ID_PASSWORD, APPLE_APP_SPECIFIC_PASSWORD and APPLE_TEAM_ID from a .env file. The README also gives the escape hatch for unsigned builds, sudo xattr -rd com.apple.quarantine /Applications/DeepBot.app, plus the right-click-to-open and Privacy & Security routes. Note the redundancy in the signing block: APPLE_ID_PASSWORD and APPLE_APP_SPECIFIC_PASSWORD are documented as holding the same value, which suggests the config accepts either name rather than requiring both.

Docker exists but is gated behind a conversation with the author

The README says Docker deployment is available for Linux servers, then adds that if you need the Docker version you should contact the author. That is the single largest adoption constraint in the material. Linux and Docker are listed as supported operating systems in the requirements, yet the artifact is not in the repository and there is no published image name, no compose file and no environment variable reference for a server deployment. An enterprise evaluating DeepBot for a Linux fleet cannot complete that evaluation from the repository alone. This is not a reason to dismiss the project, but it does mean the deployment decision and the technical decision are coupled in a way they usually are not. If your target is a Linux server, the first step is an email, not a git clone.

The path whitelist is the security model, and the README stops there

Security controls are described as a strict path whitelist protecting system access, with workspace isolation noted in the architecture diagram. That is the whole description. There is no list of default allowed paths, no explanation of whether the whitelist is configured in a file or through the UI, and no statement about what happens when an agent requests a path outside it. For a tool that ships command execution, file operations and browser control, the whitelist is the control that matters most, and its documentation is the thinnest part of the README. Treat this as a source-reading task, not a documentation-reading task. The related ambiguity is the tool count. The features list advertises 20+ built-in tools and names file operations, command execution, browser control, image generation, image and video analysis, document analysis, AI chat, cross-session messaging, web fetching, Feishu, WeChat and WeCom messaging, and Feishu document operations. The architecture diagram labels the bottom layer as 14 Tools plus security check. Both numbers may be correct if some named capabilities are skills composed from tools, but the README does not reconcile them, and a security review needs the exact list.

Where a different harness fits better

DeepBot's distinguishing choice is that the agent lives inside an Electron desktop app and talks to the world through Feishu. If your team does not use Feishu, that choice buys you nothing and costs you the Electron runtime, the macOS signing setup and the Node and Python prerequisites. A headless agent framework that runs as a long-lived process on a server and exposes an HTTP API would fit a non-Feishu team better, because deployment becomes a container or a systemd unit rather than a signed desktop bundle. The trade is that you lose the per-tab session model and the markdown prompt assembly, and you would rebuild both. The honest framing is that DeepBot is not competing on model quality or tool breadth. It is competing on integration surface and on the readability of its harness, which is why the Feishu dependency is the deciding factor rather than a detail.

Maintenance, upgrade cost and what the MIT licence does and does not cover

The repository is not archived and the last push is dated 2026-05-23, with v0.7.2 released on 2026-05-07. The version number places the project before 1.0, so expect breaking changes between minor releases and read the release notes before upgrading. TypeScript 5.3 or later and Electron 28 or later are the stated floors, and Electron major upgrades are the expensive kind: they touch the desktop shell, the packaging scripts and the signing configuration at once. If you fork DeepBot, the MIT licence permits modification and redistribution provided the copyright notice and permission notice are preserved. It does not give you rights to the DeepBot name or logo, and it does not cover the third-party model providers you connect through the multi-model support for Qwen, OpenAI and Claude, each of which carries its own terms. The .env file holding APPLE_ID and APPLE_TEAM_ID is your credential material; keep it out of any fork you publish, and note that the README's signing instructions assume a personal Apple Developer account rather than an organisation one. This is a description of the licence text, not legal advice.

Editorial conclusion

Adopt DeepBot if you already run Feishu and want an agent harness you can read and modify in TypeScript, with per-tab isolation and a path whitelist you can audit. Do not adopt it if you need a documented Docker image, a signed desktop build without an Apple Developer account, or a published security model. Verify three things before committing: that the Docker version is obtainable from the author, that the 14-tool list and the 20+ feature list resolve to the same set of capabilities, and that the path whitelist covers every directory your agents will touch. The MIT licence lets you fork and modify, but the signing credentials in your .env never belong in that fork.

Official sources

1. kevinluosl/deepbot on GitHub
2. License: MIT
3. Project website
4. README
5. Releases