I Used Multica for a Day — Here Is What I Think

I came across Multica and decided to spend a full day actually using it before forming an opinion. A lot of AI orchestration tools look great in demos but fall apart the moment you try something real. Here is what I found. 😊

What Multica Is

Multica is a multi-agent orchestration platform. The mental model is a three-level hierarchy: your computer as the runtime, and agents organized into squads. You can configure agents from different LLM providers, assign tasks to them, and manage the work through a Kanban-style dashboard.

The pitch is that you are not locked into one AI provider. Claude Code for coding, Gemini for research, GPT for writing — all in one interface, delegating work like a team.

What Works Well

The UI is clean and genuinely human-friendly. Setting up agents and squads feels intuitive, more like a modern project management tool than a developer utility. And the multi-provider flexibility is real — if you want to use different models for different kinds of work, Multica gives you a clean way to manage that without juggling multiple CLIs.

The concept of Computer → Runtime → (Agents ← Squad) gives you a clear mental model for thinking about resource allocation across different agents. That structure is useful.

Where It Breaks Down

Manual steps create real friction. Things like providing API keys through a .env file do not play nicely with the way Multica clones from GitHub repos. Agents cannot access those credentials in the spawned process. In practice, this means setup requires human intervention at points where you want the system to just run. If you are using Claude Code or Cursor in the same session, you can work around it, but it is still a manual step. 😬

Orchestration is not actually orchestrated. This one hit me hard. I set up an orchestration agent to delegate issues automatically. It kept throwing the same error: multica cli is not authenticated. The error is misleading — my local CLI was authenticated and working fine. The problem is that spawned agent processes do not inherit that authentication context. The agent was trying to use the Multica CLI to assign tasks, but the subprocess had no idea I was logged in.

What I expected was that an agent configured inside Multica should be able to call the Multica API directly, through the backend. That is not how it works today. Tasks have to be manually assigned to agents. For a tool built around orchestration, this gap is significant. ❌

Caching benefits disappear. When multiple agents share a single context, you lose the prompt caching advantages that make individual Claude sessions efficient. This is not specific to Multica — it is a general problem with multi-agent architectures — but it is worth knowing if you are thinking about token costs.

My Honest Take

Multica is a polished tool that brings traditional project management thinking into the agent era. The Kanban board, the squad structure, the multi-provider flexibility — all of it makes sense in that frame.

But here is the question I kept coming back to: do we actually need traditional project management anymore? Do we need a Kanban when we have agents that can plan? Do we need manual delegation when the goal is autonomous execution?

The best version of agent orchestration probably does not look like a dashboard. It probably looks like a well-prompted agent with good tools.

A Different Approach

After a day with Multica, I started sketching out what I would want instead. The core idea: orchestration should start from a coding session, not a dashboard.

Imagine a CLI tool — call it ai-orch — that works like this:

On init, it scans what coding agents are installed locally and registers them, with configuration stored in a simple JSON file (agent name, path, specific instructions)
Tasks come in from a plan agent or brainstorming output, with dependency information
The tasks get structured and saved to a local database with unique IDs
The current session spawns parallel Bash calls — --work 1, --work 2 — using cheap models like Haiku to execute and return results
Each worker reports completion (or blockers) back to the CLI
When all jobs finish, a --review step has each agent cross-review the others' work
The main session gathers everything, merges changes to one branch, and gives a summary

The benefits over what Multica currently offers:

Simpler — no dashboard to maintain, no manual assignment
Auto delegation — the orchestration happens in code, not in a UI
Cross-agent review — agents check each other's work before merge
True multi-model — use Codex, Gemini, Claude in the same workflow without context sharing overhead

Multica is building in the right direction. The gaps I ran into feel like early-product problems, not fundamental design flaws. I would watch where they take the agent API access and the authentication model for spawned processes — those two fixes would change the experience significantly. 🤞