Stop juggling workflows

I wasn't looking for another project management tool. I was looking for a way to run several development tracks in parallel without becoming the bottleneck myself.

The mental model I wanted: hand off a clear spec, let specialized workers break it down, distribute the pieces, and report back when things are ready for review. The kind of system where my job shifts from doing every step to steering the work.

Most tools assume a human in the loop at every handoff. Mutica doesn't.

The flow ends up being surprisingly simple once you settle into it:

1. Start with a detailed PRD. This is the part people want to skip, and it's the part that matters most. A vague PRD produces vague tasks. A specific one produces specific ones.
2. Feed the PRD to the admin agent. This is the orchestrator. Its job isn't to do the work — it's to read the spec and figure out what work exists.
3. The admin agent breaks the PRD into granular tasks. Issues, not vibes. Each one scoped tightly enough that a single agent can pick it up and finish it.
4. Tasks get routed to specialized agents based on skills. Copy goes to the content writer agent. Implementation goes to a developer agent. Each agent has its own instructions, skills, and knowledge base — they're not generalists trying to do everything badly.

The key shift: I stop being the router. The admin agent does that.

The part that sold me wasn't the architecture diagram. It was watching the automation play out end to end on a real task.

A developer agent picked up an issue, opened it in GitHub, created a branch, wrote the code, pushed it to remote, and opened a pull request. Then the status moved from in review to merge ready on its own as the checks cleared.

That's the full loop — issue creation, branch management, code generation, push, PR, status tracking — without me touching any of it until review.

It's not magic. Each step is something a developer would do manually. The difference is that several of these loops can run at the same time, on different parts of the same PRD, while I'm working on something else entirely.

The temptation when building this kind of system is to have one capable agent handle everything. In practice, that's worse than splitting the work.

A content writer agent with a tight scope and the right knowledge base produces sharper copy than a general agent trying to context-switch. A developer agent that lives inside the repo's conventions writes code that fits the codebase. The skills, instructions, and knowledge attached to each agent are what make the output usable rather than just plausible.

This is the same lesson teams keep learning with humans, just compressed: focused beats versatile, almost every time.

Three things, in order of importance:

1. Write the PRD like the next person reading it isn't you. Because the next reader is the admin agent, and it has no context beyond what's on the page.
2. Resist the urge to over-specialize agents on day one. Start with the obvious splits — writing, implementation — and let real usage tell you where the next seam is.
3. Trust the loop. The first few times an agent opens a PR without you, you'll want to micromanage. Don't. Review at the merge gate, not at every step in between.

The first week with Multica, I treated it like a smarter task router. Hand off the PRD, agents pick up issues, PRs land. Nice loop, but nothing I couldn't have stitched together myself with enough scripts and willpower.

The second week is when the skills system started to click.

Here's what changed. One of the developer agents figured out a clean deployment flow for a staging environment I'd been doing manually for months — the kind of thing where I'd half-documented it in a Notion page nobody read, including me. Instead of letting that solution evaporate into a one-time PR, I saved it as a skill. A short YAML file, committed to .multica/skills/, describing the steps.

The next time another agent — a completely different one, working on a completely different feature — needed to push something to staging, it just used the skill. Didn't re-derive it. Didn't ask. Didn't hallucinate a slightly-wrong version. It pulled the deploy-staging skill and ran it.

That's when the loop stopped feeling like task automation and started feeling like a team that remembers things.

The mental shift is real: every problem an agent solves can become a capability the whole team inherits. Day one, you teach an agent how to deploy. Day thirty, every agent deploys, writes migrations the way your codebase expects, and follows your review checklist without being told. The library compounds in a way prompts never do, because prompts live in your head and skills live in the repo.

The catch — and this is a real one — is that you write the YAMLs yourself. Skills don't emerge magically from agent runs; you have to notice the pattern, codify it, and check it in. I missed that for the first few days and wondered why nothing was compounding. The compounding is real. It's just not automatic.

I've been talking up the loop, so it's worth being clear about where the seams show.

• The orchestration is still mostly me. This is the most important thing to admit. The admin-agent flow I described works, but if you look closely, the human is still steering more than the marketing suggests. I write the PRD. I review the task breakdown. I sanity-check before the agents start. There's a real argument that Multica is managing AI the way you'd manage people — assignments, comments, statuses — when AI might need a different kind of orchestration layer underneath. The "agents as teammates" framing is useful, but it's a metaphor with limits. Don't expect the system to advance the workflow without you; expect it to execute the workflow once you've shaped it.
• Skill curation is manual. I just made the case for skills, but I want to be honest: nothing about them is automatic. You spot the reusable pattern, you write the YAML, you commit it. If you don't do that work, you don't get the compounding. Multica gives you the rails; it doesn't ride the train for you.
• Logs are thin when things go sideways. When an agent works, you see the comments, the status changes, the PR. When an agent goes off the rails, you mostly see... the comments, the status changes, and a PR that's quietly wrong. Terminal output and full run logs aren't surfaced in the UI in a useful way. Debugging means going back to the runtime and piecing together what the agent actually did versus what it decided to write down. I've gotten burned by this twice — both times because I trusted the surface report and merged something that compiled but missed the spec.
• It's early software. I'm running it because I'm willing to put up with rough edges in exchange for a real solution to a real problem. If you need rock-solid, you're early. Expect version churn, expect to read the GitHub issues, expect to occasionally restart the daemon.
• It might be overkill for you. If you're a solo dev running an agent on one task at a time, Multica is more infrastructure than you need. Use the CLI directly until you hit the wall — multiple agents on multiple machines, teammates not knowing what's been automated, the same fix being re-derived in three different prompts. That wall is when Multica earns its weight. Before that, you're managing a system instead of getting work done.
• The skeptical read. I'll steelman it: Multica is a project board with an integration that routes tickets to Claude Code instead of to a human. That's a fair description of the mechanics. Whether it's a new category or just a really good integration depends on how seriously you take the skills layer and the multi-agent coordination. For me, those two are what made it stick. Your mileage will depend on whether you actually use them, or just use the routing.