The Single-Agent Ceiling
Most of the time, lac agent running on its own is exactly what I need. Ask it to refactor a module, generate a migration, write some tests — it handles the job, shows me a diff, and I move on. Fine.
But some tasks are just wide. "Build out the authentication layer — registration, login, password reset, email verification, rate limiting, and tests for all of it." Hand that to a single agent and you're watching one thread work through it sequentially. Every sub-problem waits on the one before it.
That's the problem /multi solves.
What /multi Actually Does
When you type /multi inside a lac agent session, you're switching into Multi Agent Mode. Instead of one agent working linearly, the task gets split across two to four parallel specialized agents. Each agent gets a focused slice of the problem and works on it independently.
Once all of them finish, a Project Manager agent reviews every output, checks whether anything is missing or inconsistent, and synthesizes a final summary. If something isn't right, the PM can retry individual agents with specific feedback — up to three times per agent before it accepts what it has and moves on.
The final output lands in your session as a clean summary with everything merged. You can then undo the entire /multi session in one shot with /undo, which reverts every file touched across all agents. That's a nice safety net when you're experimenting.
A Real Example: Setting Up a New Service
Say I'm scaffolding a new Express service that needs a database layer, an API layer, middleware, and tests. In a normal session I'd give all of that to one agent and wait. With /multi, I describe the full scope and it splits roughly like this:
- Agent 1 handles the data models and database setup
- Agent 2 builds the route handlers and controllers
- Agent 3 writes middleware (auth, rate limiting, error handling)
- Agent 4 writes the test suite
All four are working at the same time. The PM then checks that the models Agent 1 wrote are actually the ones Agent 2's controllers import, that Agent 3's middleware wires into the correct routes, and that Agent 4's tests cover the right endpoints. If Agent 2's controllers referenced a model that doesn't exist yet, the PM sends it back with that note before synthesizing anything.
Is it magic? No. Is it noticeably faster than one agent doing all of that in order? Yes, for tasks where the sub-problems are parallel by nature.
How to Trigger It
First, get into an agent session:
lac agentDescribe your task or give it context. Then type:
/multiThe agent will ask how many sub-agents to use (or pick based on task complexity if you've given it enough context). You can specify explicitly:
/multi 3From there, watch the breakdown happen. Each agent's progress surfaces in the terminal. When the PM synthesizes, you get a structured summary of what was built, what files changed, and any caveats the PM flagged.
The Project Manager Is the Useful Part
Honestly, the PM is what makes this more than just "run four commands at once." Without a review step, parallel agents would produce output that doesn't actually fit together. Agent 2 imports from a path that Agent 1 decided to name differently. Agent 4 tests an endpoint Agent 3 removed. That kind of inconsistency is annoying to clean up manually.
The PM's job is to catch exactly that. It compares outputs, looks for broken references, and either fixes them or sends the relevant agent back to retry with a specific correction. The retry cap of three means it won't loop indefinitely on a hard conflict — it'll surface the issue and let you decide.
The PM's synthesis note is worth reading carefully. It'll usually call out anything it couldn't fully reconcile. That's your signal to jump in and make the final call yourself rather than blindly trusting the merged output.
When Not to Use It
Not every task benefits from /multi. If the work is genuinely sequential — where step two can't start until step one is done — splitting it across agents just introduces coordination overhead without any speed gain. Fixing a specific bug, renaming a variable across a codebase, updating a config file — none of those need four agents. /multi shines when you have a large task that naturally decomposes into parallel workstreams.
Also worth knowing: because multiple agents are writing files simultaneously, you want your project memory (.lac-memory.json) to be reasonably accurate before you kick off a multi session. Agents use that context to understand the project structure. If the memory is stale or minimal, agents can end up working with wrong assumptions about where things live. Spend thirty seconds updating it beforehand if the project has changed a lot.
Undoing Everything at Once
This is the detail I was glad to find out before I needed it rather than after. Because a /multi session can touch a lot of files across multiple agents, /undo after a multi session reverts the entire session at once — not just the last individual agent's changes. One command, clean rollback. That makes it much less stressful to try /multi on a real project.
Practical Starting Point
If you haven't tried /multi yet, the easiest way to get a feel for it is on a task you've been putting off because it felt too large to start. Open a session, give lac agent a thorough description of what you want built, then hit /multi. Watch how it decomposes the work and pay attention to what the PM flags in the synthesis. That review step alone is worth studying — it'll show you how the agents interpreted your prompt and where the ambiguities landed.
Install or update lac-cli with pip install --upgrade lac-cli and give it a try.