Running one coding agent is fine. You open a terminal, describe the job, watch it work.
Running three is where it falls apart. Each one lives in its own terminal; none of them knows what the others did, and the only record of what happened is scrollback you will close by accident. There is no answer to "what is in flight right now" other than checking four windows.
Multica is a task board for that problem. Agents get assigned issues the same way people do, they move their own cards across the board, and their work is attached to the issue instead of living in a terminal you closed.
This is what setting it up on a real project looked like: this site, its actual backlog, three agents, and what the first few hours actually consumed.
Setup: 20 minutes, no errors
I used the desktop app on macOS rather than self-hosting, which is the fastest route.
The only step that needs a decision is authentication. Log in to GitHub from your terminal over HTTPS before you start, because that is the credential the agents use when they open pull requests. Get that wrong, and everything works right up until the moment an agent tries to push, which is the worst place to discover it.
That was the whole setup. Download, sign in, connect the repository, done in about twenty minutes with nothing going wrong.
One thing that catches people out: Multica does not ship an agent. It drives the CLIs you already have. A daemon scans the machine for tools it recognizes and registers a runtime for each. It supports 23 out of the box, including Claude Code, Codex, Cursor, Copilot, OpenCode, OpenClaw, Gemini CLI, and Kimi. Mine runs on Claude Code on the MacBook. If you have no agent CLI installed, install one first.
Creating agents by asking for them
I expected a form. There is one, but it is not how you are meant to work.
Multica ships with an agent called Mika, described as a workspace chief of staff, and you create everything else by talking to it. You describe the job you want done in plain language and Mika creates the issue, the agent, or the schedule. The dialog literally prompts you with an example: "let Bojan fix the inbox loading slowness in the Web project".
Both of my other agents came out of that chat:
| Agent | Job | Access |
|---|---|---|
| Mika | Chief of staff. Turns goals into issues, coordinates the others, builds reusable workflows | Workspace |
| Vera | Reviews agent-authored pull requests with fresh context | Owner only |
| Scout | Finds AI tools worth adding to the directory and verifies them | Workspace |
The narrowness matters. An agent told to "help with the site" produces vague work. An agent told "review agent-authored PRs, and you did not write this code" produces something usable.
So does the access column. Vera is owner only, because a reviewer anyone can retask is not a reviewer.
Instructions are plain text in the agent's Instructions tab. Edit them and behavior changes on the next run; no redeploy. You are tuning a job description, not a config file.
Writing issues agents can actually finish
The board is an ordinary kanban: Backlog, Todo, In Progress, In Review, Done. Agents move their own cards. When Vera finished a review, she moved the issue to In Review herself and left the write-up as a comment.
What made this work was writing issues with an Outcome line instead of a task line. "Define the verify gate agents must pass before hand-back" is a task. "A named, runnable verify gate" is an outcome. Agents handle the second far better, because there is something concrete to check themselves against.
Some real ones off my board:
- Connect the codebase to the project
- Define the verify gate agents must pass before hand-back
- Automated code review pass on agent PRs
- Backlog sweep: turn existing TODOs and known issues into issues
- Repeatable CLI triage for pending tool submissions
The part that matters: making them stop
This is the piece I would keep if I threw the rest away.
Scout runs on a schedule through Autopilot: a cron trigger at 17:00 daily, which creates an issue in a dedicated project and assigns it to Scout. The instructions are explicit about where it must stop, and that is most of the prompt:
Run one Phase 1 scouting cycle. Phase 1 only, report and stop.
Check out the repository and re-read
CLAUDE.mdbefore anything else, in particular the CRITICAL SAFETY RULES. Do not work from memory of these files.Then STOP. Do not write SQL, open a PR, or touch the database. Set the issue status to
in_reviewand wait.
Everything before "STOP" is read-only: sweep for candidates, deduplicate against what is already listed and anything already staged, verify each survivor by loading its own website and pricing page in a headless browser, and post the findings as a comment. Nothing is written anywhere.
I read that comment and reply naming which ones to add. That reply is what unblocks Phase 2, where it writes the migration, runs the validation scripts, and opens a pull request. Applying the migration to the live database stays my job, explicitly: "Applying it to the live database is his action, never yours."
Three stops, each waiting on a human. Silence keeps it stopped indefinitely, because there is no timeout that quietly approves for you.
That design came from a specific worry. One script in this repo writes to the production database unless you pass --dry-run, and I don't want an unattended agent editing a directory with 400+ tools.
Two smaller instructions in there earn their place too. "Never treat aggregator or roundup pricing as evidence", because that is exactly how a wrong price ends up copied across the whole internet. And "Do not pad the batch to reach a number; that is a worse outcome than a short report", because otherwise you get five results whether or not five exist.
If you take one thing from this post: decide what an agent may do without asking, and make everything else stop and wait.
What it actually consumed
Multica has an Analytics tab. This is the first few hours of use, not a month, though the dashboard window says 30 days because that is all the history there is:
| First few hours | |
|---|---|
| Estimated cost | $23.43 |
| Tasks | 20, none failed |
| Run time | 1h 15m |
Read that number carefully, because it is not a bill. My runtime is Claude Code on a $ 100-a-month plan I already pay for, so nothing here appeared as an extra charge. The $23.43 is Multica's estimate of what that usage would have cost at API rates, which makes it a useful measure of how much work you got through, not money that left my account.
Split by agent, Mika did 19 tasks for an estimated $21.31 and just over an hour of run time. Vera did a single code review for $2.12 and 9.5 minutes.
The comparison worth drawing is against your plan, not against a bill. Twenty tasks in an afternoon consumed roughly a quarter of a month's allowance at API-equivalent rates. If you already pay for a coding agent subscription, that is the frame. Agents on a board burn your existing allowance faster than you typing at one of them does, and the analytics tab is where you find that out before your limits do.
Is the output any good
Here is Vera reviewing a pull request another agent wrote:
The blocking finding is the only one I'd defend without qualification, and I only have it because I ran the gate instead of reading it. No amount of staring at
"eslintWarnings": 27tells you the true count is 25; you have to execute it.
Then, unprompted:
The two I'm least sure about are the two I'd have produced from the diff alone. #1 (unenforced prohibitions) is an argument, not an observation... Both are the kind of finding a reviewer generates to look thorough, which is precisely why I'm flagging them as the suspect ones.
An agent separating what it verified from what it inferred, and telling me which half to distrust, is more useful than a longer list of findings.
I am not going to pretend every run looks like that. A backlog sweep the same afternoon canceled a dozen issues, which was correct but not exactly craftsmanship. The point is that good output is legible and bad output is visible, because it all lands on the issue rather than in a terminal.
The CLI
Everything on the board has a command-line equivalent, which matters if you want to script around it:
multica agent get <agent-id> --output json
multica autopilot get <autopilot-id> --output json
multica autopilot runs <autopilot-id> --output json
autopilot runs is the one I reach for: it is the run history for a scheduled agent, so it answers "did it fire last night and what did it do" without opening the app.
License and pricing, before you build on it
Self-hosting is free with no caps on agent count. Concurrency is limited by your hardware, and you can join multiple machines as runtimes.
Two things the marketing does not lead with.
The licence is not plain open source. It is Apache 2.0 with additional conditions: you may not offer Multica as a hosted service to third parties without a commercial license, even if you charge nothing. You may not remove the branding without a written waiver. Internal use inside one organization is explicitly fine, which covers most people reading this.
There is no published cloud pricing. The hosted version offers a free trial, and multica.ai/pricing returns a 404.
Would I keep it
Yes, with a caveat: the value is not the agents; it is the board and the gates.
The agents already existed. What changed is that I can see what they are doing, the work survives the session, and nothing irreversible happens without me saying so. That last part is what makes it usable on a live site rather than a toy repo.
Honest status: the scheduled scouting run is configured and has not fired yet, so I can tell you the design is right but not yet that it survives contact with a month of daily runs. I will report back when it has.
If you run one agent occasionally, this is a coordination layer for a problem you do not have yet. If you have three terminals open and no idea what is finished, it is the missing piece.
Originally published at intelligenttools.co, where I keep a directory of AI tools with prices checked on the vendor's own page.
Top comments (1)
"Silence keeps it stopped indefinitely, because there is no timeout that quietly approves for you" - that sentence is the whole architecture, and I can confirm it from the other side: we run a human + several agents over a shared kanban across two products, and the single rule that made it safe was the one you found too - the card is the claim. An agent moves the card before touching code, so the other agent (and the human) see "hands off" without asking. Two additions from our practice: first, the inverse of your no-timeout rule needs stating - any suppression or pardon must be consumed by the event it excuses, or an expected gap quietly becomes a standing hole. Second, Vera's self-assessment ("the two I'm least sure about are the two I'd have produced from the diff alone") is the most valuable paragraph in the post - a reviewer that separates verified from inferred is rare, but the follow-up question decides whether it's real: has Vera ever rejected a PR outright, and does the board show when she last said no? A reviewer whose refusal history is empty or invisible is indistinguishable from one that stopped looking. If Multica surfaced "last refusal" per agent next to cost and run time, that analytics tab would be the first I've seen that measures trust instead of throughput. And "do not pad the batch to reach a number" deserves to be a standard instruction in every scheduled agent on earth.