Does Multica Reduce Work or Add More? Lessons from a Real Squad Workflow

I previously wrote a Multica guide that focused on the basics: how Issues work, how agents are organized, and how multi-agent collaboration is structured.

Getting those individual features working is one thing. Putting an actual multi-stage workflow into Multica and letting several agents hand work to each other is another.

I took a real multi-stage task I was already working on and ran it through a full Squad workflow. It was not a demo invented to test Multica. It was a real workflow that needed several roles to participate in sequence, including upfront analysis, task decomposition, work by different agents, verification of key results, and an independent review step.

The task was completed, but the process made one tension in Multica much more obvious to me:

Multica can organize multiple agents, but organizing the agents can itself become work.

This article is not another setup guide, and I am not trying to answer the vague question of whether Multica is “good.” I want to focus on something more practical: in a real Squad workflow, where did Multica reduce my workload, and where did it turn me into an agent manager?

The short version: it changes the shape of the work more than the execution speed

Multica still presents itself as an agent workspace: you assign Issues to AI coding agents, the agents run on runtimes you control, they continuously write progress and results back to the Issue, and the work eventually comes back for review.

The current How Multica works and Squads documentation makes the model fairly clear:

• an Issue stores task context, discussion, and ownership;
• a Runtime performs the actual execution;
• a Squad has one Leader and one or more members;
• when an Issue is assigned to a Squad, the Leader wakes first;
• the Leader reads the context and decides who should take the next step.

The problem this structure solves is not whether a single agent can write code. It is more about coordination:

• who should handle this step;
• where the task currently stands;
• who should take over next;
• who performs the final review;
• how several agents share one trackable work object.

If my workflow is still just “open Codex, ask for one thing, and check the result a few minutes later,” Multica can feel unnecessary.

It starts to make more sense when a task runs for tens of minutes or longer, requires several roles to hand work off, and I do not want to keep watching several terminals at once.

Why a multi-stage task is a better test than a single-agent job

This task was a useful Squad test because it was not something one agent could cleanly finish in a single step.

The workflow had several distinct stages:

1. understand the initial context and inputs;
2. split the work into stages;
3. let different roles handle different parts;
4. verify key results and current state;
5. hand the result to an independent role for final review.

In other words, it already had a natural structure of upfront analysis, work by multiple roles, then review and acceptance.

I connected the relevant repository to my self-hosted Multica setup and assigned one real task to a Squad. The Squad had a Leader for coordination and Worker agents for different stages. The Leader decided who should receive each next step.

What I wanted to test was not whether the agents could do the underlying work. They already could when used individually.

The real question was:

Can Multica turn several already-useful agents into a collaboration chain that I do not have to supervise continuously?

The first obvious friction: the Worker finished, but the Leader did not continue

The clearest issue in this experiment was handoff.

In one instance, the Worker agent responsible for the upstream step completed its task and left a completion comment. I expected the Leader to take over again and decide what should happen next:

• whether another agent was still needed;
• whether the task should move into review;
• whether the goal had already been met;
• whether the Issue should move to the next state.

That did not happen. The Leader did not continue automatically.

The task simply sat there. There was no obvious error, and the Worker was no longer running. I eventually had to add another comment myself to wake the Leader and keep the workflow moving.

More importantly, this was not a single isolated occurrence. In the same full Squad experiment I ran into another similar case where a Worker had finished but the Leader did not naturally resume coordination, so I had to intervene again.

According to Multica’s current Squad documentation, normal progress updates from a member are supposed to wake the Leader so it can continue coordinating. That means what I observed does not fully match the behavior described in the current docs. At the same time, I did not do a strict root-cause investigation, so I am not treating this as proof of one specific Multica bug.

Possible factors include:

• how the Squad instructions were written;
• how the Leader interpreted the current stage;
• the trigger semantics around comments, mentions, and completion events;
• the implementation in the version that was running at the time;
• a concrete handoff bug.

The only thing I can state confidently is what happened in my workflow:

In this real run, I could not assume that “a member finished” meant “the Squad would keep advancing toward the final goal by itself.”

That distinction matters.

Similar requests already exist in public issues

Public GitHub issues describe behavior that is close to what I saw.

Issue #5464 describes runs that can stall after an agent starts a sub-issue and reaches a review or blocked state, without automatically bringing the Leader, user, or another designated agent back in.

Issue #7185 is even closer to my experience. The author says they frequently need to post a simple continue comment in real Squad projects to get the Leader to coordinate the next step. The proposed Goal Mode would have reawakened the Leader when members or child Issues completed. The issue was later closed as not planned, so it should not be read as an official commitment to implement that exact design. It does, however, show that “the human becomes the scheduler” has been a real user concern.

The public reports look similar to my experience, but I do not assume they share the same root cause.

Squad feels more like dynamic coordination than a deterministic workflow engine

Before using it this way, it was easy for me to imagine a Squad as a fixed chain:

Lead → Researcher → Writer → Reviewer → Done

After running a real workflow, I think that model is too deterministic.

The current Squad model is closer to this: the Leader reads context, then uses comments and mentions to decide which member should take the next step. Role descriptions are context for the Leader; they are not a strict state machine.

So a Squad is better understood as:

an AI Leader deciding what should happen next at runtime

rather than:

a fixed DAG or pipeline that guarantees every node runs in a declared order.

The distinction is also visible in Multica’s public roadmap discussions.

As of September 20, 2026, GitHub Issue #1943, Workflow Orchestration , is still open. The proposal asks for a stronger orchestration layer with things such as:

• fixed nodes;
• conditional branches;
• review and QA gates;
• retries and fallbacks;
• state-machine constraints;
• explicit failure and human-takeover paths.

Another public issue, #1998 , uses a Developer → Reviewer → Tester pipeline as an example. It explains that similar flows can already be assembled with agent instructions, sub-issues, and comments, but much of the correctness still lives inside prompts rather than declarative platform-level rules.

That leads me to separate two ideas:

Multica already has the first. The second is not yet a complete first-class workflow engine.

That explains part of the gap between my expectation and the actual experience: I expected the process to keep moving toward the goal on its own, while a Squad behaves more like a Leader that makes a decision each time it is successfully woken.

The second friction: the task finished, but reviewing the code change was still awkward

The workflow did eventually complete.

Later in the process I also had Multica handle commit and push. From a delivery perspective, the work reached the repository.

The next question was:

What exactly changed, file by file, and how do I review it efficiently?

In my experience, Multica did not provide a particularly direct way to inspect the full code diff inside the same task-management flow.

I specifically went looking for a built-in terminal, a diff viewer, and community discussion around the same problem.

That highlighted another part of multi-agent systems that is easy to underestimate:

Delegation is only half the problem. Review is the other half.

For research or content tasks, I can usually open the final document and read it.

For code, seeing only:

• “the agent finished”;
• the Issue is Done;
• a commit was pushed;

is not enough for a complete review experience.

I still want to answer questions like:

• which files changed;
• what each diff contains;
• why each change was made;
• which tests were run;
• whether the agent modified anything outside the Issue boundary.

This does not mean Multica cannot work with GitHub, the Git CLI, or external review tools. It means that in my workflow, task management and code review were still separate parts of the experience rather than one continuous interface.

If I keep using Multica for code work, I will make “provide an easy-to-review change entry point” part of the deliverable instead of merely asking the agent to commit and push.

For example:

finish implementation → create commit or PR → leave a PR or diff entry point in the Issue → review agent checks it → human gives final sign-off

Why some users describe it as managing a group of interns

In the community material I had read before this experiment, I saw two very different reactions to Multica.

Some users like it because they can hand off long-running tasks, wait asynchronously, and come back later to review the result.

Others feel that, for personal use, opening Codex directly is easier. One description that stuck with me was roughly:

“It feels like managing five or six interns and checking on each one.”

Before running a complete Squad workflow, I mostly treated that as an interesting community reaction.

After using one myself, I understand where the feeling comes from.

The problem is not necessarily that the agents are weak. It is that a management layer appears around them:

• task decomposition;
• role definitions;
• Squad instructions;
• handoffs;
• status tracking;
• manual wake-ups;
• result review;
• Git delivery;
• deciding the next step.

Each part is individually reasonable.

But if the underlying task would take one strong agent ten minutes, the management structure can become heavier than the task itself.

That is why Multica’s value depends heavily on the type of work.

Tasks I am more likely to put into Multica

After this run, I am more inclined to use Multica for four kinds of work.

1. Tasks that are asynchronous anyway

Examples include long research jobs, batch analysis, changes across many files, or long test runs.

Even without Multica, I would not sit and watch those jobs continuously.

2. Tasks that need explicit handoffs

One agent researches, another implements, and a third reviews.

If the task already has several roles, Issues and recorded state become more valuable.

3. Tasks with clear acceptance criteria

For example:

• which files must be produced;
• which tests must pass;
• which directories must not be changed;
• whether a PR must be created;
• what the review step needs to verify.

The clearer the acceptance criteria, the easier it is to let the work run asynchronously.

4. Several projects or machines running at once

When agents are spread across different runtimes, machines, or model resources, one shared view is more useful than trying to remember which terminal is doing what.

Tasks I would not prioritize for a Squad

There are also tasks I would still keep outside Multica.

1. Very small changes

If one Codex session can solve the problem in a few minutes, creating an Issue, assigning a Squad, and waiting for handoffs is unnecessary overhead.

2. Highly exploratory work

For example:

• the product direction is still unclear;
• the UI needs to be adjusted while I am looking at it;
• the architecture still requires frequent discussion;
• I do not yet know the acceptance criteria myself.

Those tasks need rapid human-agent interaction. An IDE, Codex app, or direct chat often feels more natural.

3. High-risk work where I need to intervene at every step

If I already have to watch the execution continuously, the asynchronous advantage becomes much smaller.

So I do not currently see Multica as the single entry point for every AI task.

A more accurate rule for me is:

Use it for work that is already clear enough, asynchronous enough, and structured enough to benefit from persistent state and handoffs.

The next collaboration chain I want to test

This run convinced me that Multica is worth continuing to test, but it did not prove that I already have a stable production workflow.

The next flow I want to validate is closer to a real software project:

Codex → planning and task decomposition

AGY / Grok → implementation

Codex → independent review

DS / another agent → validation through a testing skill

This is still a planned workflow, not a Multica best practice I have already proven.

I also want to keep the number of agents small rather than building a miniature “AI company” with a dozen roles. The model behind a role can change manually. What matters first is whether the handoff structure itself works.

The main questions I want to answer are:

1. after implementation finishes, does review reliably take over;
2. if review fails, can work route back to implementation cleanly;
3. can a testing skill act as a real gate;
4. which stages still require human approval;
5. compared with opening separate Codex and Grok sessions manually, does the workflow actually reduce management time?

If those questions do not have stable answers, adding more agents will only amplify the coordination cost.

An important constraint: I am not claiming Multica is more efficient than a single agent

This is the main boundary I want to keep around the conclusion.

I do not have enough data to say that:

• Multica is always faster;
• Multica always uses fewer tokens;
• a Squad is more efficient than several manually managed agents;
• the Leader handoff problem I saw belongs to one specific version;
• the review friction I saw is representative of every user’s setup.

This experiment involved one real project sample. I did not run a controlled A/B test of the same task using Multica Squad versus manually managed Codex and Grok sessions.

I also did not capture complete measurements for both approaches, such as:

• total elapsed time;
• number of human interventions;
• token usage;
• number of rework cycles;
• final output quality.

So the conclusion I can support is narrower:

Multica turns multi-agent work from “several chat windows” into a collaboration system with persistent task state, but handoffs, review, and workflow design create a new layer of management cost.

Whether that is a net reduction in work depends on whether the task is complex enough to justify that layer.

Version and environment boundary around v0.5.0

The version-sensitive observations in this article mainly reflect the Multica product state around the release of v0.5.0.

I did not lock every related component to an exact version during the experiment, so I am not attributing the handoff behavior I observed to one specific version.

That is also why this article focuses on workflow-level behavior rather than presenting a temporary bug list for one release.

Multi-agent platforms move quickly. For capabilities such as strict workflow orchestration, automatic Leader wake-ups, and code-review views, the right approach is to keep checking the current documentation and public issues as the product evolves.

The core trade-off: a management platform does not eliminate management cost

Looking only at the feature list, it is easy to imagine Multica like this:

Connect several AI agents, define their roles, and let them finish the project by themselves.

My experience was closer to this:

Once you connect several AI agents, you gain a management layer that can persist tasks, assign work, run asynchronously, and coordinate handoffs. But that management layer does not automatically remove management work.

For small tasks, I still prefer to work directly with a single agent.

For genuinely multi-stage, long-running work that needs several people or agents to participate in sequence, Multica already has clear value.

The question I still need to answer is whether it can move from:

“I am managing a group of AI agents”

to:

“the group of AI agents is actually managing more of the work for me.”

After this experiment, the most interesting questions about Multica are no longer how many agent backends it supports. They are more practical:

1. Who reliably advances the next step?
2. How are outputs reviewed with enough confidence?
3. Where should a human intervene so this is actually less work than managing several agents by hand?

If those three problems are solved well, multi-agent systems start to become more than just busier interfaces.