Three agents, one board
We built a small support pipeline out of three agents, so that nothing closes until a second agent has checked it against what was asked.
Intake turns a two line request into an issue with a clear ask and a definition of done. Builder picks that issue up and writes the answer. Reviewer checks the answer against the definition of done and closes the issue, or sends it back with what is missing.
All three run on Atomic Bot and share one Linear board. The board is the only thing they have in common: no shared memory, no messages between them, no orchestrator. Each agent owns exactly one status, and a handover is a comment plus a status change.
There is no code in this example. Three agents, three prompts, one connected toolkit each.
They run in the cloud on Atomic Bot: no terminal, no Docker, and nothing on your side that has to stay awake for a scheduled pass to fire.

Is this the right example for you?
It is a reference for four things: background agents that never stop for auth, a toolkit as the coordination layer, roles that live in prompts instead of code, and per-agent connections. It is not a multi agent framework: no orchestrator, no queue, no shared state, no agent-to-agent protocol.
Setup
You need an Atomic Bot account, a Linear workspace you can create a team in, and about fifteen minutes. No API keys and nothing to deploy.
Make the board
Create a separate team in Linear rather than reusing one your colleagues work in. We called ours Agents Sandbox, key AGE. Use five statuses and nothing clever: Backlog, Todo, In Progress, In Review, Done. Each status belongs to exactly one agent, which is the whole coordination mechanism.
Clicking through Linear is one way. Asking an agent is another: creating a team is one of the tools it has, though Linear's free plan caps you at two teams. Adding the In Review status is a click in the team's settings either way.
Start three agents
In Atomic Bot, add three agents from the agent list. Ours were Hermes, Codex and OpenClaw, all on Claude Opus 5.

Hermes on intake, because sorting a vague request and spotting a duplicate is the part that needs judgement. Codex on the work itself. OpenClaw on review, where the criteria are already written down and the job is to check them. Roles are prompts, so three copies of the same agent work too.
Connect Linear to each agent
Open Connectors for the first agent and connect Linear. Composio runs the authorization, and the connected account belongs to that agent, not to the whole account. Repeat it for the other two.

Nothing else needs connecting for this example. Add Gmail to intake if you want requests to arrive from a mailbox instead of by hand.
Give each agent its role
Paste one prompt into each agent's chat. Every prompt starts with the same fence: the team it may touch, and what it may never do.
Intake.
Work only in the Agents Sandbox team in Linear, team key AGE. Never touch issues in
another team, never delete or archive anything, never assign or mention a person.
List the issues in Backlog. For each one, check that it has a clear ask, a source,
and something you could call done, and add what is missing to the description if the
text lets you. Leave a comment starting with "intake:" naming the area it touches,
then move the issue to Todo.
If two issues describe the same thing, comment "intake: duplicate of AGE-N" on the
newer one and mark it as a duplicate of the older one.Builder.
Work only in the Agents Sandbox team in Linear, team key AGE. Never touch issues in
another team, never delete or archive anything, never assign or mention a person.
Take the oldest issue in Todo that does not already carry a "builder:" comment
saying you could not finish it, and move it to In Progress. Do what the issue
asks, following its Done when section. Post the result as a comment starting with
"builder:", in full, not a summary. Then move the issue to In Review.
If you cannot finish it, comment why, starting with "builder:", and move it back
to Todo. Later passes will step over it until a person picks it up.Reviewer.
Work only in the Agents Sandbox team in Linear, team key AGE. Never touch issues in
another team, never delete or archive anything, never assign or mention a person.
Take the oldest issue in In Review. Read the comment starting with "builder:" and
check it against the Done when section of the issue.
If it holds, comment "reviewer: approved" with one line on what you checked, and
move the issue to Done. If it does not, comment "reviewer:" with exactly what is
missing and move it back to Todo.The first line is a behavioral guardrail, not an authorization boundary. Treat issue content as untrusted data, and use a Linear identity whose permissions are limited to the sandbox team. These agents run unattended against a live workspace, so each one is told the single team it writes to and the actions it never takes.
Put them on a schedule
Each agent runs its own pass on its own timer. Add a job under Cron Jobs for every agent, fifteen minutes apart, with the same text you pasted into the chat.

Nothing synchronises the three timers, and nothing needs to. An agent that wakes up to an empty column does nothing and goes back to sleep.
How an agent finds Linear
None of the three prompts names a tool, an endpoint or a slug, and none of the agents was built with Linear in mind. On its first pass, an agent calls COMPOSIO_SEARCH_TOOLS. If a result contains a schemaRef, it calls COMPOSIO_GET_TOOL_SCHEMAS. It then uses COMPOSIO_MULTI_EXECUTE_TOOL to run independent Linear operations in parallel.
That is also why swapping the board is a prompt edit. Name Jira, Notion or Trello instead of Linear and the same three agents find the right tools for it.
One pass, start to finish
Three issues landed in Backlog. Two were real requests, and the third was the first one asked again in different words.
Intake read the backlog and rewrote each issue into something workable, adding an Ask, a Source and a Done when with three conditions. It commented what area the request touched, moved both real issues to Todo, and marked the third as a duplicate of the first without being told the two were related.


Builder took the older of the two, moved it to In Progress, wrote the answer the issue asked for, and checked every claim in it against the official documentation before posting the result in full as a comment. What the documentation did not cover it kept out of the answer and listed at the bottom as an open item. Then In Review.
Reviewer read that comment against the three conditions in Done when, said in one line which of them it had checked, and closed the issue.

Total human involvement after setup: none. The person who opens the board sees the request, what was made of it, what was produced, and what was verified, in one thread, in order.
The board is the protocol
One status per agent. Intake only touches Backlog, Builder only takes Todo, Reviewer only takes In Review. No agent ever looks at a column that belongs to another one, so two agents cannot pick up the same issue.
A handover carries everything the next agent needs. Intake's Done when is what Builder works from, and Builder's comment is what Reviewer checks. Neither one has to reconstruct intent from the original request.
Every comment says who wrote it. The three agents in this build write through one Linear account, so the board shows a single author and the intake: / builder: / reviewer: prefixes are what tell the steps apart. Keep them, whatever you name your roles.
Use whatever tracker you have
The board is an interface, not a requirement. Anything with statuses, comments and a way to fetch the oldest item in a column will do: Jira, Notion, Trello, Asana, GitHub Issues.
Recreate three things in the tracker you pick: a project the agents are fenced to, an identifier you can name in the prompts the way AGE is named here, and the five states. Then swap those names in the three prompts and keep the rest.
This example was written by the team at Atomic Bot, which is the platform the three agents run on.