lac-cli /multi: Split a Big Task Across Parallel Agents

When one agent isn't the right shape for the job

I reach for lac agent every day. It reads my files, remembers the project structure in .lac-memory.json, and handles most tasks without drama. But there's a category of task where I kept hitting a wall — not because the agent was bad, but because the task itself was too wide. Think: "refactor the auth system, update the tests, add JSDoc for every public method, and write a changelog entry." That's four different mindsets in one prompt.

What usually happened was the agent would do two things well and phone in the other two. Not because it couldn't — it just had too much surface area to maintain quality across all of it at once.

That's the problem /multi is built to solve.

What /multi actually does

When you type /multi inside lac agent, you're switching into Multi Agent Mode. Instead of one agent handling everything sequentially, lac-cli spins up between two and four specialized agents and runs them in parallel. Each one takes a focused slice of the task.

Once they're done, a Project Manager agent reviews all the output. If something falls short, it doesn't just pass it through — it retries that piece, up to three times, with specific feedback. When everything passes review, it synthesizes a final summary across all the agents' work.

The practical effect is that you get output with consistent quality across every part of the task, not just the parts the single agent happened to prioritize.

How to actually use it

First, make sure you have lac-cli installed and you're inside an agent session:

pip install lac-cli
lac agent

Once you're in, describe your task and then kick off multi mode:

/multi

lac-cli will ask you to confirm how many agents to use (2, 3, or 4) and then break your task into parallel workstreams automatically. You don't have to manually divide the work — it figures out how to split it based on what you described.

Here's a real example. I had a medium-sized Express app and I wanted to:

• Add input validation with Zod to all route handlers
• Write integration tests for the three main endpoints
• Generate JSDoc comments across all controllers
• Update the README with current route documentation

Before /multi, I would have done these one at a time, context-switching myself as much as the agent. With four agents running in parallel, all four tracks were done in roughly the time the slowest single task would have taken. The Project Manager flagged that one of the test files had a missing teardown and retried it. The final synthesis was clean.

The Project Manager layer matters more than it sounds

The retry loop is the part people underestimate. It's easy to think of multi-agent systems as "faster" and leave it there. But the actual value in /multi is that there's a review step baked in. The Project Manager doesn't just aggregate — it checks whether each agent's output actually satisfies the original intent.

Up to three retries with feedback means the system self-corrects on the things that matter. It's not just parallel speed. It's parallel speed with a QA pass built in.

Undoing a /multi session

One thing I want to flag because it catches people off guard: /undo in multi mode reverts the entire session at once, not individual agent outputs. So if agents A and B did great work and agent C made a mess, you can't surgically undo just C's changes with a single command.

My habit is to commit before running a /multi session on anything I care about. Then if I need to roll back, it's a clean git reset rather than hoping /undo lands exactly where I want it. The diff preview before /undo runs is your friend here — read it.

When to use /multi and when not to

Not every task needs this. For a single focused change — fix this bug, add this field, refactor this function — lac agent on its own is faster and less overhead. You don't want to spin up four agents to change a variable name.

/multi earns its keep when:

• The task naturally breaks into 2+ independent workstreams
• You need consistent quality across all parts, not just the first one
• You're doing a cross-cutting change — something that touches models, tests, docs, and config all at once
• You've already tried it as a single-agent task and the output was uneven

A good mental check: if you'd normally split this into multiple PRs or multiple todo items, it's a candidate for /multi.

Combining /multi with PlanMode

If you're not sure how /multi will split your task, run /plan first. PlanMode shows you what the agent intends to do before touching any files. Once the plan looks right, you can approve it and then trigger /multi to execute.

This combo — plan, then multi — is the most reliable way to handle tasks where the division of work matters as much as the execution. You're not flying blind into a four-agent session.

Practical tip to close

Next time you're staring at a task with four bullet points and feeling like you need to do them one at a time, try this:

lac agent
# describe your full task
/plan
# review and approve
/multi

Let the Project Manager do the QA pass. Commit your work after reviewing the diff. The whole thing is faster than you'd expect and the output holds up better than a single long agent session trying to hold too many things in context at once.

You can install lac-cli with pip install lac-cli or grab the installer from the lac-cli page. It's MIT licensed and free.