AgentRQ: A Self-Hosted Task Board That Lets Agents Pull Their Own Work

The gap AgentRQ fills between an agent and its operator

An agent running in a terminal has no durable place to put work. It finishes a step, prints text, and the only record of what it was asked to do lives in a scrollback buffer. If it needs a decision from a human before touching a production database, the request arrives as prose in that same stream, and the human has to be watching at the moment it appears. AgentRQ addresses that specific gap: it gives each workspace a task list that both the human and the agent read and write through the same API, so a permission request becomes a task state rather than a sentence nobody saw. The audience is narrow and identifiable. You need agents that can connect over MCP or ACP, you need to run your own server, and you need more than one agent or more than one person touching the same queue. A single developer chatting with one Claude session in a terminal gains nothing from a task board. A team running several harnesses against shared infrastructure, where one agent's finished job should trigger another's, is the case the project is built for.

How the Go backend, MCP servers and the event bus fit together

The README describes a decoupled service-oriented architecture, and the split is worth reading closely because it determines what you are actually operating. The backend is Go on Fiber, serving a REST API for workspace and task management. Alongside it, an integrated mcp-go SSE server exposes tools and resources to models. There is a third component the README calls CoreMCP, described as a global MCP server that lets agents manage all workspaces, tasks and statistics across the platform, which is a supervisor role rather than a per-workspace one. Persistence is GORM over SQLite, scoped per user. An internal pub/sub event bus pushes real-time SSE notifications to connected clients, and the Vue 3 frontend keeps its Pinia state in sync from those events rather than polling. That chain matters: an agent calls an MCP tool, the Go handler writes to SQLite, the event bus publishes, and every open browser or desktop window updates. The desktop build is Electron rendering the same Vue components as the browser, so there is one UI codebase rather than two. The README also lists Google OAuth2 with JWT session management, which is the one piece of the architecture that assumes you have an external identity provider rather than a local user table.

Scheduling, events and the workflow graph

Three mechanisms carry most of the automation weight. Scheduling attaches a launch date or a recurring cadence to a task, with the README naming intervals of every 15 minutes, hourly, daily, weekly and custom days. A background poller ticks every minute and spawns the task when due, so nothing has to stay awake waiting. Events are named signals such as qa_passed, deploy_finished or blog_published that a task fires on completion. Wire an event to a workspace and that workspace receives a new task automatically, with no polling and no glue code on your side. Workflows are the composition layer: events and workspaces arranged on a graph, where you drag a workspace onto an event to subscribe it, or drag an event onto a workspace to emit it on completion. The README is explicit that this replaces a decision-tree DSL or a YAML file, and that is a real design position rather than a slogan. A graph you can see is easier to audit than a YAML file you have to read, but it is also harder to diff in code review and harder to generate from a script. If your release process is already expressed as configuration in a repository, the graph is a second source of truth you now have to keep aligned.

Installing and running it: what the repository actually tells you

The supplied README does not include an installation section, a docker-compose file, or a list of environment variables. It documents the architecture, the feature set, and the desktop app, and it points to agentrq.com and a Discord server for the community. So the honest position is this: you cannot get a working deployment from the material here alone. What can be stated from the repository metadata is the shape of the build. The backend is Go, so a build produces a binary; the frontend is Vue 3 with Vite, so it produces static assets; the desktop shell is Electron and the README says it auto-updates by checking in the background and installing on restart. Configuration keys you will need to locate before you start include whatever holds the SQLite path, the Google OAuth2 client credentials, and the JWT signing secret, since all three are named as components of the running system. None of their names appear in the text provided. Treat the first hour of evaluation as reading the repository tree and the MCP tool definitions, not as deploying.

The browser-side models and where the data boundary sits

Two features run inference in the browser rather than on the server. Auto-title generation downloads a small language model once, caches it, and uses it to write a task title from the description. Speech-to-text runs an in-browser Whisper model for dictation on task descriptions and replies. The README states that in both cases nothing leaves the machine. That is a meaningful boundary for anyone whose task descriptions contain customer names or internal hostnames, and it is unusual enough to note: the server never sees the audio, and the title generation never calls an API. The cost is paid on the client. A first-time user downloads model weights before either feature works, and dictation quality is whatever the browser-hosted Whisper variant delivers rather than whatever a hosted endpoint would. The README does not state model sizes or supported browsers, so treat those as things to measure on your own hardware before you tell a team to rely on dictation.

Where AgentRQ is the wrong tool

The dependency on Google OAuth2 is the first constraint that will stop some deployments. A self-hosted tool that requires an external identity provider is not fully self-contained, and the README gives no indication of a local-password or single-user mode. If your environment cannot reach Google's endpoints or cannot register an OAuth client, the login path is a blocker, not a configuration detail. The second constraint is the ACP and MCP requirement. The description says the project is designed to work with your own Claude subscriptions and any harness with ACP support. If your agents are plain HTTP scripts or a framework that speaks neither protocol, AgentRQ has no documented way to reach them. The third is operational: a Go API server, an MCP SSE server, a supervisor MCP server, SQLite and a Vue frontend is a stack, and the release cadence visible in the metadata (three patch releases across two days in September 2026) suggests the surface is still moving. Pinning a version and reading the changelog between upgrades is not optional here. A team that wants a task manager and does not want to run infrastructure should use something hosted instead.

How it differs from a plain MCP server or a general task tracker

The nearest comparison is a standalone MCP server that exposes file or shell tools to a model. Those give an agent capabilities; they do not give it a queue with state that survives a restart and that a human can inspect. AgentRQ inverts the direction of control: the workspace holds the tasks, and the agent pulls what is assigned to it, updates status, and asks for permission through the same channel. The other comparison is a general-purpose task tracker with an API. Those have durable state and a UI, but they have no concept of an agent as a first-class actor, no tool-call history lane showing what ran and whether it was allowed or denied, and no event bus that spawns a task the moment another finishes. The History tab in the task detail view, which groups a run into Input, Agent and Tools lanes and lets you search and click into any entry, is the feature that has no equivalent in a generic tracker. That is the real differentiator: not the board, but the audit trail attached to each run.

Licence, upgrade cost and what to verify before you commit

AgentRQ is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notice files and state significant changes. It also includes an explicit patent grant. That is a permissive licence with no copyleft obligation on your own code, and it is the same licence family many Go infrastructure projects use. This is not legal advice; if you are embedding it in a product, have counsel read the NOTICE requirements. On upgrade cost, the visible signal is the release list: v0.5.21, v0.5.20 and v0.5.19 all landed within roughly two days in September 2026, and the version is still pre-1.0. Pre-1.0 with that cadence usually means internal APIs, MCP tool names and database schema can change between minor versions. Budget for reading release notes before each bump and for testing a restore from a SQLite backup, since SQLite is the only persistence layer named. The concrete things to verify first are the MCP tool list the server exposes, which ACP harnesses are supported at your pinned tag, and whether the OAuth2 requirement can be satisfied in your network. If any of those three fails, the rest of the feature set does not matter.

Editorial conclusion

Adopt AgentRQ if you already run Claude Code, OpenCode or another ACP-capable harness and you want task state, approvals and scheduling on a server you control rather than inside a vendor dashboard. Do not adopt it if you only need a chat window, if you cannot run a Go binary plus SQLite plus an OAuth provider, or if you expect a stable plugin API across minor versions. Before committing, read the MCP tool list in the repository, confirm which ACP harnesses are actually supported at your pinned version, and check whether the Google OAuth2 login can be replaced or bypassed for a single-user deployment.

Official sources

1. agentrq/agentrq on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases