Delegatus Agent Workbench
Delegate software tasks to coding agents, review their changes, and track the work on a local board.
- Source repo
- Latand/delegatus
- Stars
- ★ 33
- Last updated
- today
- License
- MIT
- Primary language
- TypeScript
- FA score
- 55/100 · Major gaps
At a glance
- How it runs
- Works with
- Portable with changesCodex · Claude CodeClaude API (Partial support)
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A developer who wants to assign several GitHub issues to agents and track them on one project board.
- Not a fit if
- Users who need native Windows support for Codex or Copilot
- Teams that cannot use agent accounts or network features
- Source review
- 55/100 · Major gaps
What does this agent do, and when should you use it?
Delegatus gives each project an orchestrator you can message from a browser board or your phone. The orchestrator creates tasks and starts pipelines in separate Git worktrees, where Claude Code or Codex agents build, review, and revise work; GitHub Copilot can run single agents but cannot serve as the orchestrator. A pipeline can leave a pull request open for you or merge it automatically when review passes if you enable that option. The app also provides conversation search, account usage details, shared memory, Telegram features, team sign-in, and an MCP server. It runs on your own machine through a Bun CLI, with a documented Docker setup for long-running service deployments; network access is guarded by an access key when exposed beyond localhost.
You submit work in the project orchestrator's chat. Delegatus places it on the Inbox, In progress, Waiting, and Done board and starts a pipeline of up to eight stages in its own Git worktree. Stage agents run through Claude Code or Codex; each review round starts a fresh reviewer, and findings can send work back for fixes. The pipeline produces a pull request, which stays open unless you enable “Merge when the review passes.” You can read and search Claude Code, Codex, and Copilot conversations, including diffs and command output; add multiple accounts per engine; let agents message each other and share memory; receive reports through Telegram; and expose tools to your Claude Code or Codex sessions through the MCP server.
- A developer who wants to assign several GitHub issues to agents and track them on one project board.
- A maintainer who wants separate build and review agents to iterate in an isolated worktree.
- A team that wants reviewed pull requests merged automatically while keeping that behavior opt-in.
- An individual developer who needs to check task progress, answer decisions, or follow agent chats from a phone.
- An engineer who wants searchable local Claude Code, Codex, and Copilot conversations with diffs and command output.
How do you install or deploy this agent?
Install Bun 1.4 or newer and either Claude Code or the Codex CLI. GitHub Copilot is optional. Launch the CLI, then use the browser setup to sign in to agent CLIs, choose a project folder, and create its orchestrator. The repository also documents building from a checkout and a Docker setup for long-running deployments.
How do you use this agent?
Start Delegatus and open its local web interface if it does not open automatically. Complete setup and select a project, then describe work in the orchestrator chat, such as handling an issue or reviewing a PR. Track pipeline stages and decision requests on the board. Pull requests remain open by default; enable “Merge when the review passes” to allow automatic merging after review.
What are this agent's strengths and limitations?
- Coordinates build, review, and fix stages in one pipeline, each in an isolated Git worktree.
- Reads and searches Claude Code, Codex, and Copilot conversations, while pipelines run on Claude Code or Codex.
- Combines a browser board with phone access, Telegram reports, shared memory, and an MCP server.
- Supports multiple accounts per engine and displays five-hour, weekly, and per-model usage limits.
- Requires Bun and Claude Code or Codex CLI; Copilot cannot run pipeline stages.
- Native Windows supports Claude Code only; the README directs users to WSL 2 for the rest.
- Anyone who can reach the app can run commands as the user, so remote access requires careful access-key handling.
- Some memory and voice-summary features send selected content to Anthropic through Claude Code; a daily install ping is also enabled unless disabled.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Delegatus Agent Workbench This agent | 55 · Major gaps | CLI | ★ 33 | today | TypeScript | Codex · Claude Code |
| Kandev | 74 · Some gaps | CLIFree + model costs | ★ 990 | today | Go | Codex · Claude Code |
| Chorus Agent Harness | 55 · Major gaps | CLIFree + model costs | ★ 1.2k | 1d ago | TypeScript | Codex · Claude Code |
| Ateam Agent Workbench | 70 · Some gaps | Desktop appFree + model costs | ★ 13 | 1d ago | TypeScript | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows default binding to 127.0.0.1, access-key enforcement on other binds and --tailscale, log APIs refusing paths outside known transcript folders, and an explicit admission that reachability equals command execution as the operator; this is a deliberate least-privilege trade-off, but agents run with full operator authority and no per-command confirmation, so least_privilege and user_confirmation score 2. Data-flow disclosure is unusually thorough (daily anonymous ping fields, opt-out switch, memory/voice summaries, direct Anthropic usage endpoint, default-off and fail-closed consent), so data_flow_transparency scores 3. Sensitive-data handling has a privacy gate and known-value fingerprinting, but design docs admit quadratic regex behavior and ~4-core CPU cost and treat detectors as hints only, so 2. Dependency security shows only external dependencies (Bun 1.4, Bubblewrap, systemd) and curl|bash installers with no lockfile audit or vulnerability handling evidence, so 1. External effects include merges, pushes, Telegram and relay writes, while rollback is only scattered across design docs, so external_effects and rollback score 1 each. Source attribution has provenance.json and upstream commit references but no unified attribution statement, so 1.
README and security docs are broadly consistent on binding, telemetry and merge-off defaults, so self_consistency scores 2; however design docs cite commit hashes that differ from the reviewed revision, indicating version drift. Dependency availability gives only install commands and Docker tags with no version pinning or offline guidance, so 1. Failure messages describe missing-CLI startup hints, telemetry timeouts and fail-closed corrupt consent files, which is moderate, so 2.
Audience and scenarios cover individual developers, teams, phone and Tailscale use, so 2. Capability boundaries are explicit (Copilot cannot run the orchestrator, Windows only Claude Code, WSL2 required), so 2. Trigger precision relies on natural-language instructions and decision forms without precise trigger conditions or misfire safeguards, so 1. Environment fit covers Linux/macOS/WSL2/Docker, so 2.
README information architecture is clear with a full guide, so 3. Install notes cover quick start, clone and Docker but rely on curl|bash and coarse version requirements, so 2. Naming stability has no versioned API or naming commitment evidence, so 1. Examples and FAQ include screenshots and guide links but no standalone FAQ, so 2. Known limitations have platform and security sections, so 2. License is MIT and consistently declared, so 2. Versioning and changelog only mention an Updates menu and RELEASING doc with no CHANGELOG evidence, so 1. Maintenance responsibility is unclear with an unverified publisher and no governance or support commitment, so 1.
Output usability includes board, conversations, decision forms and PR flow, so 2. Marginal value comes from multi-engine orchestration, shared memory and phone access, but competition is strong and evidence is largely self-reported, so 2. Cost-benefit is weakened by self-reported ~4-core privacy gate cost and Bubblewrap/systemd environment requirements, so 1.
Design docs cite specific commits, line anchors, measurements and failed candidates, so claim_traceability scores 2. Most claims come only from the repository's own docs without independent cross-sources, so cross_source_corroboration scores 1. Docs separate measured, inferred and unverified items (e.g. no real sub-agent probes), so fact_inference_separation scores 2.
- Agents run with full operator authority; anyone who can reach the service can execute commands, and a phone-access link is effectively a secret.
- A daily anonymous install ping is on by default; enterprises should confirm DELEGATUS_TELEMETRY=0 or DO_NOT_TRACK=1.
- The privacy gate self-reports quadratic regex behavior and ~4-core CPU cost, and detectors are hints only, not a substitute for human review.
- Installation relies on curl|bash and external CLIs (Claude Code, Codex, Copilot) with no version pinning or dependency vulnerability handling evidence.
- Commit hashes cited in design docs differ from the reviewed revision, so documentation may lag the code.
- Publisher identity is unverified and maintenance responsibility or support channels are unclear.