CrewMeld: AI employees, SOP canvases, and tool code that runs in a sandbox

Three asset kinds, and only one of them executes code

The platform's organising idea is a three-way split with an explicit dependency direction. A digital employee is the task execution entity, created through an onboarding wizard, and it carries the granularity of nothing at all because an agent is not a unit of orchestration. An SOP is a multi-role collaboration flow that supports execution across hours and across days, orchestrated at step level and created on a visual canvas. A tool is an atomic capability measured in milliseconds to seconds, orchestrated at operation level and created by template instantiation or OpenAPI import.

Tools are bound to digital employees and invoked on demand by them. Digital employees and human employees are then orchestrated together by SOPs. The granularity column is the load-bearing one: a tool is an operation, an SOP operates at step level, and flows can run across hours or across days. A digital employee is not created from a canvas but from a six-step onboarding wizard that ends in a standby state, and only tools that are already deployed can be bound to it, so nothing can be attached to an employee that would fail on first use.

Eight execution states, and an illegal transition is rejected rather than logged

The SOP execution engine has eight states: pending, running, completed, human-waiting with resume from a breakpoint, timeout, error, failed, and cancelled. The documentation states plainly that all state transitions are validated and illegal ones are rejected, which is a stronger claim than most workflow engines make. Four step types exist. A digital employee step invokes an agent with its tools and knowledge base. A human employee step is performed by a person. A human approval step pauses the flow until approval is granted and then resumes. A conditional branch routes several ways. Timeouts are handled at two levels: a step-level timeout automatically adds a timeout exit to the step it guards, and the SOP as a whole has a maximum execution duration defaulting to 24 hours that you can change. The canvas itself does drag-and-drop nodes, edges for flow, a property panel for executor, timeout and retry, and versioning where every save creates a new version.

An approval persists a snapshot and resumes first-come-first-served

The human-approval path is the most carefully specified part of the platform. When a flow reaches an approval node the engine pauses and writes a full state snapshot to the database, which is what makes a resume across a day possible. Notifications go out through whichever channels the approver configured, with Feishu, WeCom and DingTalk approval cards and HTML email cards named as the options. Approvers decide through links that require no login, so the flow does not stall on an account they may not have. When the decision arrives the engine resumes from the breakpoint, and concurrency control is first-come-first-served: the first decision wins and later ones are discarded rather than raced. That choice trades fairness between approvers for determinism in the state machine, which is the right trade for an audit trail.

One environment variable governs both CORS and the login origin gate

The deployment configuration has a comment block explaining a single allowed-origins setting, and it is the security detail worth reading twice. One variable governs both the API's CORS layer and the authentication library's origin check, described as the login and cross-site-request-forgery gate. Three modes are offered. A wildcard permits any origin, and the comment says that mode runs CORS without cookies while the authentication layer trusts any origin. A comma-separated list permits only those origins, with cookies enabled. Leaving it empty permits only the canonical application URL. Anything exposed beyond a trusted network should use the second or third mode. Two related settings sit beside it: a public service base URL for published tool endpoints, and a webhook base URL for inbound callbacks from Feishu, WeCom and Telegram, which falls back to the application URL when unset. The application URL itself is read at runtime, so changing it needs a restart rather than a rebuild.

ZIP export clears secrets, and tool code runs outside the main process

Tools use a two-tier model that separates code from configuration: one template can spawn many instances, each with its own parameters and credentials, deployed and run independently. Templates come from an official preset set bundled with the platform or from user-installed sources created locally or imported as a ZIP. The ZIP path is where the design earns trust. Exporting clears any environment variable marked as secret, and those values must be re-entered by hand after import, explicitly to stop credentials travelling between environments inside a package file. Execution is separated the same way. Tool instance code runs in isolated sandbox containers on either a Docker or a Kubernetes runtime, supports JavaScript and Python, and a sandbox failure is stated not to affect platform stability. The sandbox server's own configuration sits in the repository, so self-hosting means running that service too.

The formatter is a beta and the lint script rewrites files unsafely

The toolchain is a Bun monorepo on a task runner, with Playwright for end-to-end tests and a Helm chart alongside the Compose files. Two script definitions deserve attention. The linter and formatter is a beta release of Biome, pinned to a two-point-zero beta. More importantly, the two lint scripts differ in a way that matters: the checking mode does not write, while the fixing mode runs with an unsafe-fix flag applied across the whole tree, meaning it will apply code changes the tool itself considers risky. A separate Helm lint runs in strict mode against a test values file, and an aggregate target chains both. There is also a schema-drift check with its own script, which is the guard you want in a project whose database holds agent state and execution history.

Six script families in three dialects, and two init services that fix permissions

The root directory is wide, and the pattern in it is more informative than any single file. Six operational tasks, starting, building, resetting, server start, mini start and k3s start, each exist as a shell script, a batch file and a PowerShell script, so the same instructions are maintained three times over. Deployment is likewise four-layered: a default Compose file, plus development, local and production variants, plus a Helm chart, plus the bundled sandbox server configuration. The default Compose file is assembled from two anchors. One declares a shared image and build context for every service baked from the monorepo, with a registry mirror and an npm registry passed as build arguments so an air-gapped install has a hook. The other sets log rotation of a 50 megabyte file and five files for every service at once. Two short-lived init services do the unusual work. One runs a script that ensures secrets exist, mounts the environment file, never restarts and belongs to an init profile. The configuration file says empty secret fields are generated on first start, that this is idempotent, and that secrets must not be edited afterwards, with the encryption key named specifically. The second init service exists only to fix permissions, applying a recursive mode of 1777 to the sandbox deploy volume root from a minimal BusyBox image, because on Windows and macOS the bind source is created root-owned inside the virtual machine and cannot be chmodded from the host. That mode is world-writable with a sticky bit: one container cannot delete another's files, but any container on the volume can create new ones, and the same service exists so that Dev Studio can make per-session directories. If your threat model includes mutually untrusted tool instances, that assumption is worth challenging rather than inheriting.

Version zero, private, Apache-licensed, with bilingual notices

Several naming details in this repository do not line up, and each is traceable. The manifest declares version zero with zero point zero and marks the package private, and there are no GitHub releases, so the release script in the scripts directory is the only publishing path. GitHub reports the licence as unrecognised while the manifest says Apache-2.0 and the root holds a licence file plus two notice files, one in English and one in Chinese, with a dedicated script to regenerate them. That bilingual pairing matches the bilingual readme and is the correct handling for an Apache-licensed redistribution. The database service in the base Compose file is a Postgres 17 image with the vector extension, which is the substrate the retrieval-augmented knowledge base sits on. A synchronisation script pushes the source to a public distribution while the application image resolves to a registry under the vendor's own namespace with a moving latest tag by default.

Editorial conclusion

CrewMeld fits an organisation that wants agent behaviour governed by an auditable process rather than left to a single long-running prompt, and that needs its agents to be reachable from the chat tools staff already use. Four things to settle first. Decide who gets administrator rights, because manual SOP triggers and system-level tool instances sit behind that role. Read the allowed-origins configuration carefully, since one variable drives both the API's CORS layer and the authentication origin gate, and the wildcard mode is documented as trusting any origin. Plan around secret management rather than around it, because the deployment generates secrets on first start and tells you not to edit them afterwards. And note the package is marked private at version zero with no GitHub releases, so pin a commit rather than a tag.

Frequently asked questions

Official sources

1. Issues
2. proinsight-io/crewmeld on GitHub
3. README