MindsHub Cowork puts agents, data, and artifacts in one workspace
MindsHub Cowork is meant for delegating a whole piece of work rather than sending one prompt. The README names research, analysis, reporting, scheduled operations, apps, websites, documents, dashboards, and decks as outputs. A model router can switch between hosted and open models, while agents, memory, reusable skills, schedules, and connected data stay in the surrounding workspace. Finished artifacts can be shared through a published URL.
That is a broad promise, but the product shape is understandable. A knowledge worker chooses data and a model, delegates a project, then returns to an artifact rather than a chat transcript. The workspace is available as a hosted web app, downloadable macOS or Windows desktop app, and source build for Linux. Pro access and model availability are commercial considerations separate from the MIT-licensed superproject.
Four submodules make source ownership visible
The current repository is a coordinator for four pinned modules: mindsdb/cowork for the frontend, mindsdb/cowork-server for the API, mindsdb/anton for the default agent, and mindsdb/data-vault for data connections. make setup runs npm in the frontend and uv sync in two Python backends. Development can launch Electron or a browser SPA alongside a FastAPI server.
This separation helps contributors work on each component, but it complicates reproduction. Submodules begin at pinned commits, branch selections live in dev.env, and .gitmodules sets ignore = all. A changed submodule can therefore leave the parent status looking clean until someone deliberately pins the new commit. Reviewers must inspect both the superproject pointer and the commit inside every changed module.
What happened when we ran it
Our lab cloned commit ff891bd and tested the Node project under frontend/ in a fresh 3-CPU, 8 GB Debian container. The checkout contained 2,799 files, about 253,736 source lines, and 114.4 MB. Npm installation succeeded in 37 seconds, adding 511 packages and occupying 735 MB. The frontend then built successfully in 16 seconds.
The project exposed no test script or target to our harness, so tests were skipped. That means the measured build proved compilation, not agent behavior, connector correctness, credential isolation, scheduling, or artifact publishing. The structural scan found 2 CI workflow files, a Dockerfile, and no tests directory. Current superproject structure may place checks inside the linked module repositories, which still leaves this measured commit without a runnable test target in the path we assessed.
Npm audit reported 23 known vulnerabilities in the installed frontend tree: 3 critical, 19 high, 0 moderate, and 1 low. Those numbers are the strongest reason to keep an evaluation isolated. They do not prove an exploitable path in every deployment, but critical and high advisories deserve package-level triage, fixed-version checks, and a repeated production build before credentials or private data enter the system.
Connected data makes credential boundaries the product
The README lists BigQuery, Postgres, Gmail, Drive, HubSpot, Notion, and Linear as connection examples. It says credentials remain scoped to connections and agents do not receive raw keys. That is the right design goal for an agent workspace, because a model should receive the minimum data and actions needed for one job. A buyer should verify that claim with permission tests across connectors and users.
Model access also needs a clear bill of materials. Hosted Claude, GPT, and Gemini routes depend on accounts, terms, data policies, and network access. Open DeepSeek, Qwen, or Kimi models need a reachable inference service and enough hardware. An air-gapped deployment can only perform tasks supported by models, packages, connectors, and data already available inside the boundary. The word air-gapped does not supply those pieces.
The reset command can erase the exact state users value
make flush is intentionally destructive. The README says it removes the Cowork server tool, backend virtual environments, provider keys under ~/.anton, and the database, Hermes state, conversations, and projects under ~/.cowork. It prompts by default, while FORCE=1 skips confirmation. That target is useful for a clean-install test and dangerous in ordinary troubleshooting.
Back up or export valuable artifacts before using it. Production operators also need to identify which state lives in the local database, which lives in connector systems, which is hosted, and which can be rebuilt. A workspace promises continuity through memory and projects, so recovery is part of product acceptance rather than an afterthought.
Release notes and repository links describe different product eras
The current README calls the product MindsHub Cowork but tells readers to clone mindsdb/minds, files issues there, and uses badges from that repository. CLAUDE.md also contains an older minds-platform clone path. Meanwhile, the latest GitHub release attached to mindsdb/mindshub, v26.1.0 from April 23, describes SQL handlers, database integrations, and knowledge bases rather than the current Cowork superproject.
GitHub recorded 39,649 stars, 2 combined issues and pull requests, and a last push on August 21, 2026. The recent push argues against calling the code abandoned. The low local issue count and cross-repository links suggest that public activity and product history are split, so buyers should follow the module and mindsdb/minds trackers instead of reading the number 2 as a tiny support queue.
Build success is only the start of a safe trial
The 16-second frontend build makes a source experiment feasible, and the MIT license is permissive for the superproject. Each bundled submodule keeps its own license, so redistribution should inventory all four. The harder acceptance work is behavioral: connector scope, agent permissions, model routing, artifact publication, scheduling, multi-user separation, and recovery. None was exercised by our build-only run.
MindsHub is worth a contained trial for a team that wants agent work to end in reusable artifacts rather than chat. Keep test data synthetic, use narrowly scoped connector accounts, and resolve the 23 audit findings before widening access. If the actual need is a deterministic integration workflow or one model-backed application, Dify, Langflow, or n8n presents a narrower operating problem.