Open Duet's server belongs to one owner
A roster of AI coworkers does not give your human team separate accounts. Open Duet's README says its experimental server is intended for one owner with paired devices. Within that boundary, it provides named agents with instructions, workspaces and memory, plus conversations and routines. That makes it an interesting personal workbench for someone who wants several agents available from one place.
The distinction affects the adoption decision immediately. You can appoint a lead and specialists, inspect their conversations and choose approval settings. Team leads currently need Claude. If your plan depends on several people sharing administration or choosing any engine as team lead, the documented product boundary already rules it out. A single operator experimenting with delegated work has a more credible reason to try it.
What happened when we ran it
Our Open Duet backend run installed 34 dependencies in 12 seconds and used 38 MB, then built successfully in 1 second. Tests failed with exit code 4 after 1 second. We checked commit 69a65e4 on 2026-10-24, with the Python project under backend/. The sandbox had 3 CPUs and 8 GB of RAM. Its recorded image was ghcr.io/astral-sh/uv:python3.12-bookworm; actual interpreter and operating-system versions require the raw toolchain logs.
The command stopped while loading backend/tests/conftest.py. The fixture file tried to import pytest_asyncio and raised ModuleNotFoundError. That is the concrete failure we can diagnose: the module was unavailable to the test process. The excerpt doesn't establish why it was missing, and we have no passing-test count. It supplies no evidence that an agent conversation, scheduled routine or approval decision worked.
Pip-audit reported 0 known vulnerabilities in the environment it examined. That result cannot establish the safety of external engines, desktop components or actions an agent takes. The checkout held 695 files, about 98194 source lines and 5.3 MB. Our scan recorded 3 CI workflow files, a Compose file and a tests directory, with no Dockerfile detected. The small backend environment is useful evidence about this path, not a measurement of the complete desktop or server footprint.
The selected engine decides where prompt content goes
The README says Open Duet stores conversations, notes and settings in the instance's local data folder or server database. Workspace files stay in the assigned folders. It also says the selected engine receives the prompt and the context needed for each turn. That context can include attachments or workspace content. Hosting the interface yourself therefore leaves a separate decision about the model provider.
You bring the engine account, CLI sign-in or API key, and Open Duet includes no model subscription. The documented options include command-line agents and OpenAI-compatible endpoints such as Ollama or LM Studio. A local endpoint is available as a configuration choice, but we did not verify a local model conversation. Check the engine's capabilities before choosing it: the README warns that tools and image support vary.
Approval modes include Ask first, Accept edits and Plan only. I would begin with Ask first and an expendable workspace, then inspect the requested actions before granting more freedom. That is an adoption recommendation. Our backend checks did not exercise those controls, so we cannot describe them as independently verified safeguards.
Routines need a running backend and computer access is optional
Routines can run on a schedule, by webhook or on demand, according to the README. They execute in the backend, which must stay running, and a routine does not approve actions by itself. Leaving the desktop closed only works for recurring work if a suitable backend remains available. A successful Python build doesn't demonstrate that operating arrangement.
The ordinary chat path does not require Docker. Isolated agent computers do, and computer and browser access are experimental and off until enabled. The server guide adds a concrete deployment difference: its Compose route cannot access the host's Docker, so agent computers require the direct route. Choose the deployment around the capability you need before expecting the container path to cover everything.
Server recovery requires more than the database archive
The self-hosting guide calls for a Linux server, an HTTPS domain and an engine configured on that server. It treats the passphrase and credential-encryption key as separate secrets to retain. Its backup archive excludes the encryption key and engines' own sign-ins. Restoring the database alone is therefore insufficient to recover every credential and engine connection.
Desktop packaging has its own caveat. The README calls installers experimental and unsigned, with no automatic updates, and presents the source checkout as the documented route. It also says a built-in integration catalog for services such as Gmail, Slack and Notion is not yet available. Those are practical reasons to wait if you expect a managed desktop experience or ready-made business integrations.
Open WebUI serves shared access, while CrewAI serves coded workflows
Open WebUI documents role-based access control and user groups. Consider it when several human users need a self-hosted model interface with differentiated permissions. That is a different requirement from one owner operating a roster of agents. It is also a separate product to assess, not a shared-account workaround we tested inside Open Duet.
CrewAI is a Python framework for multi-agent workflows, with Crews and event-driven Flows. Choose it when you want to define the workflow in application code. Open Duet's appeal is the persistent workspace and conversations around named agents. Neither comparison establishes a performance or reliability advantage.
October maintenance does not settle experimental features
GitHub recorded a push on 2026-10-23 and 6 open issues and PRs. Recent pull requests addressed memory aliases and Markdown rendering. Our documentation rating is 4/5 for explicit owner, engine and deployment limits, with a fifth point reserved for an operating path independently verified here. Setup, support and production maturity remain unscored. First reproduce the backend's test prerequisites, then check one disposable agent task and its approval path before leaving a routine unattended.