Why one agent isn't always enough
Most of the time, lac agent handles what I throw at it. It reads files, writes code, tracks tasks, and keeps context in .lac-memory.json. For a focused job — "refactor this service", "add validation to these routes" — one agent moving sequentially is perfectly fine.
But there's a category of task where that falls apart: anything big enough to have genuinely independent sub-problems. "Build out the full auth system" or "migrate the data layer and update all the tests that depend on it." You end up with one agent context-switching back and forth, losing the thread, or just picking an order of operations that creates unnecessary back-and-forth.
That's the problem /multi is built for.
What /multi actually does
When you run /multi inside a lac agent session, you're switching into Multi Agent Mode. Instead of one AI working linearly, the task gets split across two to four specialized agents running in parallel. Each agent owns a slice of the problem and works it independently.
Then — and this is the part that makes it genuinely useful rather than just a neat demo — a dedicated Project Manager agent reviews everyone's output before it touches your repo. If something doesn't pass review, the PM sends it back with specific feedback and the responsible agent retries. It'll do this up to three times per agent before the session finalizes.
Once everything clears review, the PM synthesizes a final summary: what was changed, where, and why. You get the full picture without having to reconstruct it from four separate diffs.
How I actually use it
Here's a real example. I had a project where I needed to:
- Add pagination to three different API endpoints
- Write integration tests for each of those endpoints
- Update the API docs to reflect the new query params
These three things are related but not tightly coupled — the tests don't depend on the docs being written, and the pagination logic doesn't need the tests to exist before it can be implemented. Running them sequentially through a single agent would've taken longer and introduced unnecessary ordering constraints.
I opened a session, described the full scope, and ran /multi. The agents split it roughly as I expected: one on the endpoint changes, one on the test suite, one on the docs. While they were running I could see each agent's progress in the terminal. About four minutes later the PM came back, flagged that the test agent had missed covering one edge case, asked for a retry — and then finalized everything once it passed.
The whole thing would've taken me closer to 40 minutes doing it manually, and probably 15+ with a single agent working through it in order.
The /undo that actually matters
Here's something worth knowing before you rely on /multi for anything critical: the undo behavior is different from regular lac agent.
In a normal agent session, /undo rolls back the most recent file change — one step at a time, with a diff preview so you can see exactly what you're reverting.
In a /multi session, /undo reverts the entire session at once. All agents, all changes, all at once. That's intentional — the changes are interwoven across files, and peeling them back one agent at a time would leave your repo in a half-reverted state that's worse than either direction.
So the practical advice: before you kick off a /multi run on anything you care about, make sure you're on a clean branch or at a clean commit. Not because the tool is unreliable — the PM review catches most problems — but because a single all-or-nothing undo is a much blunter instrument than a step-by-step rollback. Give yourself somewhere clean to fall back to.
When to reach for /multi vs. a single agent
I don't use /multi for everything. Honestly, most tasks don't need it. The overhead of spinning up parallel agents and running a review cycle is worth it only when the task has real parallelism in it.
A few heuristics I've landed on:
- Use /multi when you can naturally split the task into 2+ independent workstreams. If the sub-tasks don't block each other, parallel execution helps.
- Stick with lac agent when the work is sequential by nature — each step depends on the output of the last. A single agent with PlanMode is better here.
- Use /multi when you want a built-in review pass. The PM doesn't just merge output blindly — it actually checks it. That's useful when you're not going to manually review everything yourself.
- Stick with lac agent for quick, focused edits. Spinning up four agents to rename a function is just noise.
Setup
If you don't have lac-cli installed yet:
pip install lac-cliOr with the install script:
curl -fsSL https://lacai.io/install.sh | bashThen run lac agent to start a session, describe your task, and type /multi when you're ready to go parallel. You can check out the full CLI docs at lacai.io/lac-cli.
One practical tip before you go
Give the agents a tight, specific task description. The PM review only catches output problems — it can't fix a vague brief. If you say "improve the backend," you'll get four agents interpreting that four different ways and a PM trying to reconcile them. If you say "add cursor-based pagination to /api/posts, /api/comments, and /api/users, with matching tests and updated OpenAPI docs," the split will be clean and the review will be meaningful.
Specificity is still your job. /multi handles the execution.