Model or dataset
proinsight-io/crewmeld avatar
proinsight-io/crewmeld

CrewMeld: Enterprise AI Digital Employee Platform with Visual SOP Orchestration

CrewMeld — Enterprise AI Digital Workforce Platform. Manage AI employees like real team members. Visual SOP orchestration, 13 LLM providers (including China-native models), 8+ messaging channels(WeCom/DingTalk/Feishu/Telegram), knowledge base with RAG, and full private deployment support. Built with Next.js, React, TypeScript & Bun.

847 stars12 forksTypeScriptNOASSERTION

At a glance

What is it?
CrewMeld is a self-hosted TypeScript platform that manages AI agents as persistent digital employees, orchestrated through a visual canvas of multi-role SOPs, with RAG knowledge bases, 13 LLM providers, and integration into 8 messaging channels including WeCom, DingTalk, Feishu, and Telegram.
Who is it for?
CrewMeld fits teams that need to run AI agents as long-lived employees across enterprise messaging platforms, particularly those already using WeCom, DingTalk, or Feishu. The private deployment story is solid: a Docker Compose stack, a Helm chart, and documented environment variables make on-premise deployment straightforward.
Can I use it commercially?
Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
Is it still maintained?
Yes. The repository last received commits 33 days ago.
What is it written in?
Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 22, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What CrewMeld Is and Who It Is For

CrewMeld treats AI agents as digital employees: persistent identities with names, avatars, roles, tool bindings, knowledge base associations, and runtime statuses (standby, active, paused, or error). The platform is aimed at enterprise teams that want to integrate AI into existing operational workflows, particularly those that use Chinese enterprise messaging platforms such as WeCom, DingTalk, and Feishu alongside international platforms like Telegram and Discord.

The three asset categories the platform organizes around are digital employees, SOPs, and tools. Digital employees are the task-executing entities. SOPs are multi-role collaboration flows that can run for hours or days, pausing at human approval nodes and resuming from a persisted state snapshot. Tools are atomic capabilities, running in milliseconds to seconds, isolated in OpenSandbox containers. This three-layer model lets teams compose complex, long-running workflows from small, reusable pieces.

The platform is self-hostable by design. A Docker Compose file is provided for local and production deployment, and a Helm chart is included for Kubernetes environments. The start scripts (start.sh, start.bat, start.ps1) and reset scripts handle initialization, and the .env.example file documents all required environment variables, including the canonical public URL and optional webhook base URL for inbound channel callbacks.

SOP State Machine and Breakpoint Resume

The SOP engine implements an 8-state state machine: pending, running, completed, human-waiting (breakpoint resume), timeout, error, failed, and cancelled. State transitions are validated; illegal transitions are rejected by the engine.

The step types available in an SOP are: Digital Employee (invokes an agent with its tools and knowledge base), Human Employee (performed by a person), Human Approval (the flow pauses until an approver acts), and Conditional Branch (multi-way routing). Trigger types include scheduled (cron expression plus queue scheduling), event-driven (channel messages or webhook callbacks), and manual (via the admin console run button or the Open API).

Breakpoint resume for human approval works as follows: when the flow reaches an approval node, the engine pauses and persists a full state snapshot to the database. Notifications go out through the approver's configured channels, using approval cards for Feishu, WeCom, and DingTalk, or HTML email cards for email recipients. Approvers respond through login-free links. Concurrency is controlled with first-come-first-served logic to prevent double-approvals.

Timeout is configurable at two levels: each step has a step-level timeout, and the SOP-level maximum execution duration defaults to 24 hours and can be overridden. The visual canvas editor supports drag-and-drop node orchestration, with versioning on every save.

Installing and Starting CrewMeld

CrewMeld uses Bun 1.3.9 as the package manager and Turbo for monorepo task orchestration. The setup flow begins with copying the environment file and filling in the required fields:

bash
cp .env.example .env

The only required field is NEXT_PUBLIC_APP_URL, which sets the canonical public URL. Secret fields in .env are auto-generated by the setup container on first start; the README warns not to manually edit ENCRYPTION_KEY after it is generated. For production, launch with Docker Compose:

bash
docker compose --profile init up setup
docker compose up -d

The init profile runs the setup container to generate secrets and apply database migrations before the main services start. The primary services are the Next.js application (port 6100 by default), a PostgreSQL 17 database with the pgvector extension, and a Redis instance for session management and the service gateway load balancer. The OpenSandbox server runs in a separate container that manages Docker or Kubernetes runtimes for tool code isolation.

For development, the monorepo provides a single dev command:

bash
bun run dev

Tool System and OpenSandbox Isolation

The tool system separates template definition from instance deployment. A single tool template can produce multiple instances, each with its own parameters and credentials. This lets teams run, say, separate instances of a Slack notification tool with different authentication tokens, all from the same template.

Template sources are official presets bundled with the platform, user-created templates, and ZIP imports. ZIP import/export is designed for cross-environment migration: environment variables marked as secret are cleared on export to prevent credential leakage and must be filled in manually after import.

Tool instance code runs in OpenSandbox containers, isolated from the main platform process. Supported runtimes are JavaScript and Python. The Dev Studio supports three service types declared via service.type in the tool manifest: json (structured API, invoked via the tool API), http (web pages or general HTTP services, with interactive HTML preview), and sse (streaming HTTP services with event-stream preview). Service publishing includes options for API key or anonymous access, internal or public-origin exposure, and horizontal scaling between 1 and 20 OpenSandbox replicas with Redis-backed round-robin load balancing.

Messaging Channel Integration

CrewMeld integrates 8 messaging platforms: WeCom (with rich approval cards), DingTalk (with AI card streaming), Feishu (with AES encryption and per-employee routing), WeChat Official Account, Email (SMTP send and IMAP receive), SMS, Telegram (with bot polling), and Discord (bot gateway). New channels can be added through a three-part adapter, card-builder, and sender pattern documented in the README.

Each channel has different capability coverage. WeCom and Feishu support message encryption. DingTalk and Feishu support streaming card replies. WeChat and WhatsApp use QR code login. Telegram supports proxy configuration for restricted network environments.

Approval notifications are delivered through channel-specific formats: Feishu and WeCom send approval cards, email sends HTML cards, and all approver responses come through login-free links. The channel system routes messages to specific sessions or workspaces rather than broadcasting to all users, and connecting an account to a channel does not automatically start responding to messages; binding must be explicit.

LLM Configuration and Knowledge Bases

CrewMeld connects to 13 LLM providers, explicitly including China-native models alongside international providers. The README mentions providers accessible without a VPN as part of its China deployment support, though the exact list of all 13 is not enumerated in the README.

Knowledge bases use RAG (retrieval-augmented generation) and support many-to-many relationships with digital employees: one employee can bind multiple knowledge bases, and one knowledge base can be bound to multiple employees. During onboarding, the knowledge base binding step is step 4 of the 6-step onboarding flow, following tool binding and before model configuration.

The LLM configuration per digital employee selects vendor and model. The platform level provides a 5-step digital employee onboarding wizard: role selection (from a preset library or from scratch), basic info (name, description, persona), tool binding, knowledge base binding, model configuration, and confirmation. Initial status after onboarding is standby.

Limitations and Alternatives

CrewMeld has no GitHub releases and carries version 0.0.0 in its package.json. The last push was on 2026-08-28. There is no public changelog or documented API stability commitment in the README, which is a genuine risk for teams considering a production adoption.

The license in the repository's package.json is Apache-2.0, but the LICENSE file is marked as NOASSERTION by the metadata, meaning the license terms should be verified directly from the LICENSE and NOTICE.md files in the repository before commercial use.

A natural alternative is Dify, a self-hosted AI application platform that also supports knowledge bases, agent orchestration, and messaging channel integration. Dify uses a visual workflow builder that is broadly similar to CrewMeld's SOP canvas, but its agent model is flow-based rather than employee-identity-based, and it does not have CrewMeld's explicit multi-role SOP state machine with human approval breakpoints. CrewMeld's China-native LLM support and deep WeCom/DingTalk/Feishu integration are specific to the enterprise Chinese communication environment that Dify also addresses, but CrewMeld's onboarding flow and employee identity model are more opinionated.

Editorial conclusion

CrewMeld fits teams that need to run AI agents as long-lived employees across enterprise messaging platforms, particularly those already using WeCom, DingTalk, or Feishu. The private deployment story is solid: a Docker Compose stack, a Helm chart, and documented environment variables make on-premise deployment straightforward. The main risk is the absent versioned release: there are no GitHub releases, the version in package.json is 0.0.0, and stability guarantees are unclear. Teams should evaluate on a staging environment before committing, verify that their chosen LLM provider is among the 13 supported, and budget time for tool instance setup, since tool code runs in OpenSandbox containers that require Docker or Kubernetes.

Frequently asked questions

How does CrewMeld differ from a simple LLM API wrapper?

CrewMeld runs agents as persistent digital employees with identity, tool bindings, and knowledge base associations. It manages multi-step SOP workflows that span hours or days, including human approval pauses with state persistence and breakpoint resume, which a simple API wrapper does not provide.

What messaging platforms does CrewMeld integrate with?

CrewMeld integrates with WeCom, DingTalk, Feishu, WeChat Official Account, Email, SMS, Telegram, and Discord. Each has different capability coverage: Feishu and WeCom support approval cards and message encryption, while Telegram supports proxy configuration.

How does tool code isolation work in CrewMeld?

Tool instance code runs in OpenSandbox containers, isolated from the main platform process, using Docker or Kubernetes as the container runtime. JavaScript and Python runtimes are supported. A sandbox failure does not affect platform stability. Scaling between 1 and 20 replicas is configurable per instance.

Official sources

  1. Issues
  2. proinsight-io/crewmeld on GitHub
  3. README
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/proinsight-io-crewmeld.svg)](https://hysenlabs.com/projects/proinsight-io-crewmeld)