Choosing an Agent Working Mode

Before launching an Agent, you need to choose a working mode. The working mode determines how the task is split, how sub-agents collaborate, when you need to confirm things, and how deliverables are accepted.

Heicode's working modes fall into two categories:

• Collaboration modes: determine how multiple Agents work together, including Sub mode and Swarm mode.
• Delivery modes: determine how the task moves forward and gets accepted, including Waterfall mode and Agile mode.

Sub mode is not Swarm mode. Sub mode is the basic capability where a main Agent splits up the task and sub-agents collaborate explicitly; Swarm mode is a different collaboration style in Heicode — on a tenant-level virtual machine, a lead Agent and multiple worker Agents run together, where the lead receives the goal, breaks the task down, and dispatches it, and workers claim and execute subtasks, with up to 8 workers, 3 by default (adjustable by plan). This is a lead-dispatches, worker-executes architecture — not a decentralized, self-organizing system with no central scheduling where Agents compete for tasks on their own.

Waterfall mode and Agile mode correspond to the two fixed templates in the one-click "Dev Mode Team" deployment feature, with fixed roles and headcounts: Agile = Product (planner) + Dev (executor) + Review (code-reviewer), 3 roles total; Waterfall = Analysis (analyst) + Architecture (architect) + Dev (executor) + QA (qa-tester) + Review (code-reviewer), 5 roles total.

Quick comparison of the four modes

Sub mode

Sub mode is Heicode's basic multi-Agent collaboration style. Its focus isn't "swarm self-organization" but "controlled decomposition by a main Agent."

In Sub mode, the main Agent is responsible for understanding the user's goal, splitting it into subtasks, assigning them to sub-agents, aggregating the results, and delivering to the user. Sub-agents are responsible for a single area, such as research, frontend, backend, testing, review, or deployment.

How Sub mode works

User goal
-> Main Agent understands the goal
-> Main Agent splits into subtasks
-> Sub-agents are created or invoked
-> Sub-agents execute their own tasks
-> Sub-agents explicitly hand off results
-> Main Agent aggregates
-> Verify and deliver

Key Sub mode concepts

The relationship between Sub mode and Swarm mode

Sub mode and Heicode's Swarm mode both fall under "multi-Agent collaboration," but they differ in how control works:

• Sub mode has no lead/worker role split — subtasks are explicitly assigned by the main Agent.
• Swarm mode has a clear lead and workers: the lead breaks the task down and dispatches it, and workers claim, execute, and report their heartbeat.
• Sub mode centers on handoff and aggregation; Swarm mode also needs the lead to aggregate results across multiple workers.
• Sub mode fits controlled division of labor with clear boundaries; Swarm mode fits exploratory tasks that need multiple workers processing in parallel.

Simply put: Sub mode and Swarm mode are two different multi-Agent collaboration styles in Heicode. Swarm mode is not simply an upgrade of Sub mode — it's a lead-plus-worker architecture.

When to choose Sub mode

Choose Sub mode when:

• A task needs multiple specialized roles involved.
• Subtask boundaries are relatively clear.
• You need the main Agent to keep unified control of direction.
• You need implementation, testing, and review handled separately.
• The problem is complex, but doesn't yet need large-scale parallel processing across many workers.
• You need to keep the task within a clear budget and permission scope.

Sub mode is not recommended when:

• The task is small enough for a single Agent.
• Requirements are unclear — the goal itself isn't defined.
• Subtasks are strongly dependent on shared, dynamically changing state.
• You need a large number of Agents to automatically find tasks and influence each other.
• Output must be signed off strictly by fixed stages.

Sub mode configuration recommendations

The number of sub-agents should be adjusted based on actual task needs — there's no fixed tier; it depends on task boundaries and division of responsibility.

Common role combinations (roles drawn from Heicode's 19 role templates, such as analyst, architect, code-reviewer, debugger, executor, planner, qa-tester, etc.):

Permission recommendations:

• Each sub-agent only gets the resources it needs.
• code-reviewer Agents don't directly modify production resources by default.
• explorer Agents can prepare deployments, but production deployment must be approved.
• What sub-agents share is task state and results, not unnecessary secrets.

Swarm mode

Swarm mode is one of Heicode's multi-Agent collaboration styles, using a lead-plus-worker architecture: each tenant maps to an Azure virtual machine, on which an api container, a lead container, and several worker containers run via docker-compose. The lead receives the user's goal, breaks the task down, and dispatches it to workers; workers claim tasks, execute them, and report results back to the lead. Up to 8 workers, 3 by default (adjustable by plan).

Swarm mode is a good fit for complex tasks that need multiple workers processing in parallel. It is not a decentralized system with no central scheduling — it's a lead-plus-worker architecture with a clear lead responsible for decomposition and scheduling.

How Swarm mode works

User goal
-> The lead Agent receives the goal
-> The lead breaks it into subtasks
-> Workers claim the subtasks dispatched to them
-> Workers execute, and report heartbeat and progress
-> High-risk operations go through approval
-> The lead aggregates worker results
-> Verify and deliver

Core components of Swarm mode

Differences between Swarm mode and Sub mode

When to choose Swarm mode

Choose Swarm mode when:

• The task needs multiple Agents exploring simultaneously from different directions.
• Subtasks have dynamic dependencies that can't be fully split up front.
• You need to continuously absorb new information and adjust the path.
• You need multiple results to cross-check, complement, or compete with each other.
• You need to handle large-scale code review, research, or complex troubleshooting.
• A single main Agent would easily become a bottleneck.

Swarm mode is not recommended when:

• The task goal is very small.
• Acceptance criteria are unclear.
• The budget is very tight.
• No one is available to handle exception approvals.
• Production high-risk operations are involved without a clear boundary.
• You need strongly consistent transactions or a strictly linear process.

Swarm mode configuration recommendations

Confirm before launching:

• How the lead plans to break down the task.
• What resources each worker can access.
• The worker count cap (up to 8, 3 by default, adjustable by plan).
• Which actions must require human approval.

Recommended constraints:

• Confirm the worker count cap per plan, not exceeding 8.
• Production operations must exit the swarm's automatic flow and go through approval.

Swarm mode monitoring focus

Focus on:

• Whether tasks broken down by the lead are piling up.
• Whether any worker is duplicating work on the same task.
• Whether a worker is stuck or hasn't reported a heartbeat in a long time.
• Which worker is consuming the most budget.
• Whether there are high-risk permission requests.
• Whether the lead's aggregated results have clear evidence.

When you find a problem, you can:

• Stop an abnormal worker.
• Reduce worker concurrency.
• Ask the lead to summarize current results early.
• Switch to Sub mode for controlled decomposition.
• Switch to Waterfall mode for formal delivery.

Waterfall mode

Waterfall mode is a good fit for tasks with clear goals, a clear stage order, and risk that needs strict control. It requires that one stage be completed and confirmed before moving to the next.

How Waterfall mode works

Requirements confirmation
-> Design
-> Implementation
-> Testing
-> Review
-> Release preparation
-> Release approval
-> Delivery archiving

Each stage should have a clear output.

When to choose Waterfall mode

Choose Waterfall mode when:

• Requirements are already clear.
• The delivery boundary is fixed.
• Production release is involved.
• Customer delivery, compliance, legal, or security content is involved.
• A complete audit trail is required.
• The team wants sign-off confirmation at every stage.

Waterfall mode is not recommended when:

• The goal is still being explored.
• The product direction needs frequent adjustment.
• You need to quickly try multiple approaches.
• You don't know what the final deliverable should be.

Agile mode

Agile mode is a good fit for tasks that need continuous iteration. It doesn't aim to finish everything in one shot — instead, each round delivers a verifiable increment.

How Agile mode works

Establish the goal
-> Choose this round's scope
-> Execute
-> Verify
-> Demo or deliver
-> Collect feedback
-> Adjust for the next round

Every round should answer three questions:

• What are we doing this round.
• What are we not doing this round.
• What counts as done this round.

When to choose Agile mode

Choose Agile mode when:

• Product requirements are still changing.
• You want to complete an MVP first.
• UI, interaction, or copy needs multiple rounds of adjustment.
• You need feedback from the customer or team every round.
• The task can be broken into multiple small increments.
• You don't want to open up too much permission at once.

Agile mode is not recommended when:

• It's a one-off migration or release that can't be split into rounds.
• Requirements are already strictly frozen.
• No one is responsible for each round's feedback.
• The team has no time to accept increments.

How to choose a mode

You can choose based on these rules:

Can modes be combined?

Yes. Collaboration modes and delivery modes are usually used together.

Common combinations:

• Agile + Sub: within each iteration, multiple sub-agents divide the work to hit this round's goal.
• Agile + Swarm: within each iteration, multiple Swarm workers quickly explore approaches, risks, and implementation paths.
• Waterfall + Sub: within each stage, sub-agents divide the work, with strict acceptance between stages.
• Swarm to Waterfall: once exploration is done and the approach has stabilized, move into the formal release stage.
• Sub to Swarm: when static decomposition proves insufficient, and more parallel workers are needed.

Before switching, confirm:

• Whether current deliverables have been saved.
• Whether unfinished tasks have been archived.
• Whether the budget has been reset.
• Whether permissions need to be narrowed or widened.
• Whether approval rules still apply.
• Whether the reason for switching is recorded in the audit trail.

Mode selection examples

Example 1: Fixing a login failure

Recommended: Sub mode.

Reasons:

• The Backend Agent analyzes the error and checks the endpoint.
• The Frontend Agent checks the client-side redirect logic.
• The Reviewer Agent verifies the fix.
• Subtask boundaries are clear — Swarm mode's multi-worker parallelism isn't needed.

Example 2: Large-scale code review

Recommended: Swarm mode.

Reasons:

• Security, performance, testing, dependencies, and architecture can be reviewed in parallel by multiple workers.
• Discovered issues can generate follow-up tasks.
• Results from multiple workers can cross-check each other.
• The lead aggregates everything into a unified risk list.

Example 3: Launching a legal terms page

Recommended: Waterfall mode.

Reasons:

• Content needs to be accurate.
• Review is needed before release.
• Production deployment requires approval.
• Delivery requires archiving and audit.

Example 4: Designing a resource center

Recommended: Agile mode.

Reasons:

• Content and structure need multiple rounds of confirmation.
• You can build a documentation version first, then an in-site page.
• Every round can produce inspectable output.

On the term "Swarm"

The word "swarm" easily makes people think of a decentralized system with no central scheduling, where Agents compete for tasks on their own — but the Swarm mode Heicode has actually implemented isn't like that: it's a lead-plus-worker architecture, where one lead on a tenant virtual machine is responsible for breaking down and dispatching tasks, and up to 8 (3 by default) workers are responsible for claiming and executing them.

Heicode layers platform constraints on top of this architecture:

• Permission boundaries.
• Approval rules.
• Budget caps.
• Credential TTL.
• Audit records.
• The ability to stop and take over.

This means customers get controllable lead/worker collaboration, not untrackable automated sprawl.