AgentRQ
A self-hosted workspace for assigning, supervising, and discussing AI-agent tasks in real time.
The evidence shows workspace-scoped MCP configuration, user-scoped storage, OAuth/JWT, permission-request concepts, and read-only repository permissions in CI; tool and Supervisor effects are also described fairly clearly. Deductions apply because the setup recommends pre-approving several write/download tools and using a dangerous development channel, while Supervisor spans every workspace. Tokens are embedded in URLs without documented log protection, encryption, rotation, revocation, or retention controls, and no vulnerability scanning or supply-chain verification is shown. Pause and task states offer limited recovery, but systematic undo, audit rollback, and data restoration are undocumented. Project, extension, and third-party attribution exists, although the responsible publisher remains unclear.
The README, workflows, and DeepSeek plugin tests present a mostly coherent architecture and behavior. Tests cover parsing, malformed-payload rejection, push deduplication, pause/resume, connection state, and startup-failure warnings. Deductions reflect that only one plugin subset is tested in the supplied evidence, not the whole platform, and MCP URL and placeholder forms are not entirely uniform. Operation depends on Google OAuth, npm packages, Docker Hub, external CLIs, and network services. Failures can produce warnings or rejected inputs, but platform-wide error taxonomy, recovery instructions, and end-to-end failure evidence are absent.
The documentation thoroughly addresses human operators, self-hosters, Claude, Codex, Gemini, DeepSeek, ACP, Slack, and multi-workspace Supervisor scenarios, earning strong audience and environment-fit scores. Tool inventories, workspace boundaries, configuration switches, pausing, and single-agent scope define many capabilities. Deductions apply because Supervisor is broad and unsupported or unsafe scenarios are not systematically documented. Push delivery, queue claiming, startup catch-up, deduplication, and malformed-message handling have tests, but content is forwarded directly to the agent and pre-approval is encouraged, so trigger control is not comprehensive.
The README clearly organizes overview, architecture, installation, gateways, Supervisor, extensions, integrations, credits, and licensing, with many copyable examples and explicit local/Docker prerequisites. Deductions apply for minor inconsistencies among WORKSPACE_ID, <ID>, server names, and URL examples with or without /mcp, plus the absence of a consolidated FAQ or complete limitations section. The full Apache-2.0 license is present. Tag workflows produce semantic Docker tags, but no version policy, changelog, migration notes, or release history is supplied. Discord, the website, and repository imply update channels, yet no maintainer responsibility or support commitment is stated, and publisher identity is unknown.
Tasks, statuses, replies, attachments, real-time pushes, permission responses, and multi-workspace controls produce directly usable collaboration outputs. Tests also verify task IDs, tool naming, and framing that prevents multiline content from forging structural fields, supporting strong output usability. Multiple agent bridges and a unified workspace offer plausible marginal value beyond a basic task list, but no user outcomes, comparative study, or performance data are provided. Self-hosting may reduce platform dependence, yet Go, Node, OAuth, databases, gateways, and operations remain necessary, with no quantified deployment cost, resource use, or benefit.
Architecture, tools, configuration, and publishing claims can be mapped across the README, workflows, and plugin tests; test comments also connect some parser formats to stated backend behavior. This provides moderate traceability and cross-file corroboration. Deductions apply because the supplied code verifies only part of the DeepSeek integration and cannot corroborate authentication, storage, Supervisor, Slack, Docker runtime, or platform-wide security claims. Promotional terms such as “high-performance,” “seamless,” and “secure” are not clearly separated from tested facts, assumptions, or limitations.
- The documentation places tokens in MCP URLs. Keep token-bearing URLs out of version control, shell history, telemetry, and logs, and confirm rotation and revocation procedures before deployment.
- Pre-approving createTask, updateTaskStatus, reply, downloadAttachment, and a dangerous development channel reduces per-action confirmation. Scope permissions to the workspace and task and retain human approval where effects matter.
- Supervisor can administer all workspaces. It should not be granted to production agents by default without independently confirmed auditing, rollback, and recovery controls.
- This is a static review of only the supplied files. No code was executed, and dependency vulnerabilities, container images, authentication implementation, and end-to-end behavior were not verified.
What does this agent do, and when should you use it?
AgentRQ is a self-hosted human-agent collaboration and task-management platform organized around shared workspaces. Its Go/Fiber backend exposes a REST API, workspace-scoped MCP servers, a global Supervisor MCP server, and SSE events, while GORM and SQLite provide persistent user-scoped storage. A Vue 3, Vite, Pinia, and Tailwind CSS frontend displays tasks, conversations, permissions, and live state changes. Connected agents can pull assigned work, change task status, create tasks for humans, exchange messages, download attachments, and request approval for sensitive actions. Each workspace has its own MCP URL and token, while the OAuth2-protected Supervisor manages workspaces, tasks, permissions, and statistics across an account. It is a strong fit for teams that want deployment and data control plus integrations with Claude Code, Codex, ACP agents, or DeepSeek Harness, provided they are prepared to operate a full web stack and its authentication.
A human creates a workspace, decomposes a goal into tasks, and assigns those tasks to an agent. Through the workspace MCP server, the agent calls getWorkspace, getTask, createTask, updateTaskStatus, reply, and downloadAttachment. getTask can retrieve a named task or dequeue the next notstarted task assigned to the agent; updateTaskStatus moves work among notstarted, ongoing, blocked, and completed; conversation history is optionally returned with cursor-based pagination. Human interactions are delivered through notifications/claude/channel and real-time SSE events, with ACP Gateway or Codex Gateway forwarding events to other agent processes. The CoreMCP Supervisor can create and update workspaces, search tasks globally, change order and assignees, control allow_all_commands, update scheduled tasks, answer permission requests, and retrieve attachments. The resulting task state and conversations are persisted in SQLite and presented in the Vue dashboard.
- A developer running several Claude Code projects gives each project its own .mcp.json so every agent receives only that workspace's assignments.
- A team supervising sensitive automation receives permission requests in task conversations and submits allow or deny decisions through the Supervisor.
- A self-hosting operator monitors agent work remotely from mobile, web, or desktop while task states and replies update in real time.
- A program manager uses listAllTasks, workspace statistics, priorities, and assignee controls to coordinate work across multiple workspaces.
- A team already using Gemini CLI, Codex, or DeepSeek Harness connects real-time assignments through the documented gateway or plugin for that runtime.
- An operator creates recurring work with createTask's cron_schedule option and maintains scheduled tasks through updateScheduledTask.
What are this agent's strengths and limitations?
- Workspace-scoped MCP endpoints provide project isolation, while the Supervisor MCP supplies account-wide task, workspace, statistics, and permission controls.
- SSE and protocol notifications deliver assignments, replies, and permission requests in real time instead of requiring agents to poll continuously.
- The documented Go/Fiber, SQLite, and Vue deployment boundary supports self-hosting and control over service operation and stored task data.
- Beyond the native Claude Code channel, the project supplies explicit integration paths for Codex, ACP-compatible agents, and DeepSeek Harness.
- Its task model covers status transitions, conversations, attachments, assignees, priorities, command permissions, and cron scheduling.
- Operating the local stack requires Go, Node.js, npm, and Google OAuth2 credentials, making deployment heavier than a standalone CLI.
- Workspace MCP URLs contain tokens and are stored in project configuration examples, so adopters need an appropriate secret-management practice.
- The documented Claude Code launch uses dangerously-load-development-channels, which organizations may need to review against their security and approval policies.
- Non-Claude runtimes add moving parts: Gemini needs ACP Gateway, Codex needs Codex Gateway, and DeepSeek Harness needs a plugin plus a separate profile for each workspace.
- The supplied evidence does not document backups, high availability, external database migration, or large-scale concurrency characteristics for the SQLite data layer.
How do you install or deploy this agent?
Local development requires Go 1.21+, Node.js 18+ with npm, and a Google OAuth2 Client ID and Secret. Create backend/_config/base.yaml, or development.yaml, with:
auth:
google:
client_id: "your-google-client-id"
client_secret: "your-google-client-secret"From the repository root, run:
make install
make devThe frontend is then available at http://localhost:5173. The project also documents self-hosting with a pre-built Docker image, but the supplied material does not include the Docker commands or environment variables from SETUP.md, so a verified container invocation cannot be reproduced here.
How do you use this agent?
Open a workspace's Setup modal and copy its workspace ID, full MCP URL, and token. For Claude Code, create .mcp.json in the project root:
{
"mcpServers": {
"agentrq-WORKSPACE_ID": {
"type": "http",
"url": "YOUR_MCP_URL"
}
}
}
Create .claude/settings.local.json, enable that project MCP server, and allow the required updateTaskStatus, getWorkspace, reply, createTask, downloadAttachment, and getTask operations. Start Claude from the project directory with:
claude --dangerously-load-development-channels server:agentrq-WORKSPACE_IDThe agent can then call getTask to claim work, reply to report progress, and updateTaskStatus as work advances. For Codex, configure the same workspace URL and tool approvals in .codex/config.toml, add the gateway's .mcp.json, and run:
npm install -g @agentrq/codex-gateway@latest
codex-gatewayFor Gemini CLI through ACP, run:
npm install -g @agentrq/acp-gateway
acp-gateway -- gemini --acpHow does this agent compare with similar options?
Claude Code has the documented native claude/notifications channel path. Gemini CLI and other ACP agents require @agentrq/acp-gateway to translate between ACP and MCP notifications. Codex instead uses @agentrq/codex-gateway to bridge MCP with the Codex app-server protocol, with .mcp.json receiving assignments and .codex/config.toml enabling the agent to call AgentRQ tools. DeepSeek Harness uses a dedicated plugin that maintains a supervised session, with one profile serving one workspace.