How Concierto works
How the three core components (server / daemon / AI coding tool) coordinate to run an agent's work.
Concierto is a distributed platform. The web interface you see is just the front of house. The real work is done by three components: the Concierto server owns the data (workspaces, issues, members, the task queue, and so on); a runtime picks up tasks and drives the AI coding tool; and the AI coding tool (Claude Code, Codex, and other CLIs) is the component that actually writes code. The big difference from Linear or Jira is that agents never run inside the coordination server. They run either on your own machine (the local daemon) or on Concierto Cloud's managed worker pool (the hosted runtime). The server only coordinates.
The three core components
- Concierto server. The workspaces, issue lists, and comment threads you see all live in its database. It's also a WebSocket hub that pushes real-time updates between you and your teammates. It does not execute any agent tasks.
- Daemon. Part of the Concierto CLI, running on your own machine. On start it detects which AI coding tools are installed locally, registers with the server, and begins polling for tasks every 3 seconds and sending heartbeats every 15 seconds.
- AI coding tools. One of the eleven (or several in parallel): Claude Code, Codex, Cursor, Copilot, Gemini, Hermes, Kimi, Kiro CLI, OpenCode, OpenClaw, Pi. Once the daemon has picked up a task, it uses these tools to actually do the work.
With the local daemon, the toolchain stays local: your API keys, code directories, and authorized tools are only ever used on your machine, and the Concierto server never sees any of them, whether you self-host or use Cloud. With the hosted runtime, the work runs on Concierto Cloud's worker pool instead, using platform-managed model access that is metered as credits (see Plans and billing).
The lifecycle of a task
Take the most common scenario, you assign an issue to an agent:
- You click assign in the web UI. The browser sends an HTTP request to the Concierto server.
- The server sets the assignee on that issue to the agent and, at the same time, creates an execution task in the task queue with status
queued. - The daemon on your machine picks up the task on its next poll (within 3 seconds). Task status becomes
dispatched. - The daemon creates an isolated working directory locally and invokes the corresponding AI coding tool. Task status becomes
running. - The AI writes code locally, runs tests, and posts comments back to the server.
- Execution ends. The daemon reports the result (success / failure) to the server, and task status becomes
completedorfailed. You see the progress update in real time in the web UI (via WebSocket).
A single task is one turn of a larger loop, not the whole job. When a step lands, the agent chains the next one toward the goal, reviewer agents gate the result, and a human is pulled in only for a decision that needs one. See How agents loop for the full picture.
For the detailed mechanics, see Daemon and runtimes and Tasks.
Four ways to get an agent working
It's not only "assign an issue". Concierto has 4 triggers, one per collaboration style:
| How | Typical scenario | Docs |
|---|---|---|
| Assign an issue | The most common. Assign an issue to an agent and it starts on its own | Assigning issues |
| @mention an agent in a comment | "Take a look at this one for me". Don't change the assignee or status, just fire off a comment | Mentioning agents |
| Direct chat | Standalone conversation, not tied to an issue. Ask questions, have it draft an issue | Chat |
| Autopilots (scheduled) | Standing instructions, "do a standup summary every Monday morning" and the like | Autopilots |
Runtimes: where it runs, and how many tools
A runtime is what executes a task. There are two models:
- Local daemon. A runtime is the pairing of "daemon × one AI coding tool." If the daemon on one machine has both Claude Code and Codex installed and is joined to two workspaces, Concierto registers 4 independent runtimes (2 workspaces × 2 tools). Your keys and code stay on your machine.
- Cloud (hosted) runtime. Concierto Cloud runs a managed worker pool that claims and executes tasks, so no local daemon is needed. A workspace with hosted execution gets a Concierto Hosted runtime provisioned automatically; the pool's workers run the agent's work and model usage is metered as credits. This is the runtime behind Concierto Pro.
Hosted execution is generally available on Concierto Cloud for Concierto Pro workspaces. Self-hosted deployments enable it with HOSTED_RUNTIME_ENABLED. See Daemon and runtimes for the full comparison.
Next steps
- Cloud Quickstart, connect to Concierto Cloud in 5 minutes
- Self-Host Quickstart, run your own backend
- Daemon and runtimes, a deep dive into the component the architecture rests on