The single-agent bottleneck
Most of the time, one agent is enough. You ask it to refactor a function, it does the job, you move on. But every so often you hit a task that is genuinely wide — audit the entire codebase for security issues, research three competing approaches and compare them, write tests for five different modules at once. Running all of that through a single agent in one prompt is slow, and the output tends to wander. The agent has to context-switch constantly and usually does a mediocre job at every sub-task instead of a good job at any of them.
I used to break these tasks up manually. Paste the security prompt, wait, paste the testing prompt, wait, then try to stitch the results together myself. It worked, but it felt like exactly the kind of thing a computer should be doing instead of me.
That is what /multi is for.
What /multi actually does
Inside lac agent, typing /multi activates Multi Agent Mode. You describe the task once. lac-cli then splits the work across two to four parallel specialized agents, each focused on a specific slice of the problem. While they run, a Project Manager agent sits above them, watches every output, and decides whether the result is good enough.
If any agent's output is weak or incomplete, the Project Manager sends it back for a retry — up to three times — with specific feedback about what needs to improve. Once everything passes review, the Project Manager synthesizes all the individual results into one final summary and hands it to you.
You don't have to coordinate any of that. You just write the task and wait.
Running it
First, make sure you have lac-cli installed:
pip install lac-cliThen launch the agent:
lac agentOnce you're inside the agent session, type:
/multiYou'll be prompted to describe the task. Write it like you'd explain it to a senior engineer. The more specific you are about what "done" looks like, the better the Project Manager agent can evaluate the outputs.
A real example I ran last week:
Audit this Express project for: 1) missing input validation, 2) insecure direct object references, 3) missing rate limiting, 4) hardcoded secrets. Give concrete line references for each issue found.
That naturally splits into four focused agents, one per category. Each one reads the relevant parts of the codebase and comes back with findings. The Project Manager checks that each report actually has line references and isn't just vague warnings, retries any that fall short, then combines everything into a single ranked list of issues.
It took maybe three minutes. Doing that manually through one prompt had taken me closer to fifteen, and the output was worse.
The retry loop matters more than it sounds
The retry mechanism is the part I underappreciated at first. Three retries with targeted feedback is not the same as just running the agent again. The Project Manager doesn't just say "try again" — it gives the agent specific notes on what was missing. So if an agent returns a vague answer like "rate limiting may be missing," the PM pushes back: "Identify which routes specifically lack rate limiting middleware and cite the file and line number." The second pass is almost always significantly tighter.
This is the kind of review loop you'd do yourself if you had time. Most of the time, you don't.
Undoing a /multi session
Because /multi can involve a lot of file writes across multiple agents, lac-cli treats the whole session as one undo unit. If something went sideways, you don't have to unwind each agent's changes individually. Just run:
/undoThat reverts the entire /multi session at once. Same diff preview, same safety net you get with regular lac agent undo. It is worth knowing this exists before you run /multi on something critical for the first time.
When to reach for /multi vs. a single agent
Not every task needs it. If the problem is coherent and linear — "add pagination to this endpoint" — a single agent handles it better. /multi earns its place when the task has genuinely parallel workstreams that don't depend on each other's output. Think: audits across categories, research across options, test generation across modules, documentation across components.
A rough rule I use: if I'd normally open three separate prompts and manually combine the results, that's a /multi task.
One thing to keep in mind
Running two to four agents in parallel means you're burning through tokens faster than a single agent session. If you're on a provider with tight rate limits, you'll feel it. Ollama users running locally are basically unaffected — parallel agents just means parallel CPU/GPU load, no API limits to worry about. If you haven't tried lac agent with a local model yet, it's worth setting up just for sessions like this.
Try it on something real today
If you have a codebase sitting around with a nagging "we should audit this at some point" task, that is exactly the right first thing to throw at /multi. Install lac-cli, start an agent session, and run:
lac agent
/multiDescribe what you want audited and let the Project Manager earn its title. You can find the full lac-cli docs at lacai.io/lac-cli.