Several AI Agents on One Task: How Aiglade Splits the Work and Brings Results Together

Last updated: 2026-10-25

Aiglade is a Windows desktop application that puts Claude Code, Codex CLI, Hermes, and OpenClaw into a single window, with a Chinese onboarding wizard, ready to use after installation, and no programming required. It is built as an Electron desktop app and serves as the single console for these AI agents, with no web version. This article explains what happens when several agents work on one task: how the task is split, how results are brought together, and where the human steps in.

How is a task split up in the first place?

The first step of splitting is the user describing one task in Chinese, rather than first breaking it into instructions for each agent. The user does not need to write code or explain a technical implementation. Describing the task itself in Chinese is enough, and the task then enters dispatch and queueing. The agents inside the window include Claude Code, Codex CLI, Hermes, and OpenClaw, all in the same window, so the user does not need to understand each one separately or learn each one's usage first.

Splitting here means dividing the work, not breaking the interface apart. Dispatch answers the question of who the task goes to. Queueing answers the question of what order tasks run in. Together, they give several agents a predictable order, and the user can see in the interface whether a task is currently being dispatched or queued. Before splitting, the user needs to describe the task itself, the relevant background, and the result that is wanted. There is no need to describe a technical route or to specify which technical approach the task should take. Where the description is unclear, the window stops at a confirmation point and asks, rather than pushing ahead on a guess. That is also where human judgment enters the splitting step. For a basic introduction to the product, see the Aiglade about page. For the official background of individual tools, see the Claude Code documentation and the Codex documentation.

In what order do the split parts run?

The split parts run in queue order, not piled up without order. When several tasks exist at once, the queue relationship lets each task's progress be tracked on its own, so the thread is not lost as the number of tasks grows. The user does not need to remember who a task went to, or check back and forth across different places. The task, the dispatch result, and the queue status all belong to the same management interface, and the user can map them directly to a specific task when looking.

A single console means there is only one management entry for tasks, and the user does not need to search across several places to confirm a task's status. The desktop form also puts task management and local records on the same side, so the correspondence between the interface, the task, and the record is more direct. The window itself is the carrier of the collaboration: the built-in agents' tasks gather here, and the management actions happen here too. Dispatch and queueing also have counterparts in the record: the dispatch entries in the audit table correspond to who a task went to, and the status-change entries correspond to how far a task has gone. When checking the record, those two kinds of entries can be mapped back to a specific task, instead of reconstructing the dispatch result from memory.

How are results brought back together?

Results are brought together by returning to the same window under the same task, not by some automatic mechanism that writes a new combined result. After the split parts move ahead, their progress and results map back to the task that was originally described. In the same window, the user sees different sides of the same task, not several unrelated outputs. The basis for calling it brought together has three parts: the same window, the same task, and two record locations that match each other.

The first record location is the status change: the daemon writes audit entries through a single path into an audit table, with action values covering creation, dispatch, heartbeat, status change, gate, resolution, and archiving. This is a record in a database. The second record location is the session: each CLI tool keeps its session records on the local disk. The two locations answer different questions, and the audit table does not answer session content, while session files do not answer the full picture of status changes. When both locations match, the thread for the task is complete. When they do not match, the bringing-together step is not finished, and it cannot be announced as done first. The checking order also matters: look at the status-change entries in the audit table first, then look at the session files on the local disk. When both match, the thread is complete. Looking at only one location makes it easy to mistake session content for status changes, or status changes for session content. The confirmation card is the last human checkpoint before bringing together counts as done: if an action that triggered a gate has not been confirmed, the bringing together is not complete, and however much progress exists, it is still unconfirmed progress.

Where does the human step in?

The human steps in at the action that triggers a gate. When a task reaches an action that triggers a gate, the action does not run directly. It stops and waits for the user to confirm. What the user sees is a confirmation card with two actions: approve or reject. Approval is judged by object equality, not by keyword matching. A gate carries a timeout, and a timeout does not mean default approval. Confirmation happens before execution, not as a note written afterwards.

Confirmation only covers the single action that triggered the gate. It does not change the goal of the task, and it does not attach approval conditions to other actions. The user takes part in decisions that are readable, not in technical details that are not. After confirmation, the task continues. Before confirmation, the task stays waiting, and that waiting state itself is directly visible on the Chinese interface. The practice of Chinese documentation and Chinese interfaces is common on domestic platforms too. For example, the Alibaba Cloud Model Studio documentation and the Zhipu Open Platform documentation both provide explanations in Chinese, and readers can compare how different platforms write their explanations.

What happens to split tasks after an interruption?

After an interruption, split tasks are handled by conditional resuming, not by resuming everything automatically. After the daemon crashes or restarts, orphaned tasks are marked resumable and keep their checkpoints. Resuming is started by hand: the checkpoint is read, the task moves from resumable back to running, and the executor replays history from the checkpoint. When the user returns, the records show how far the task got, and the next step can be decided from there.

The boundary is equally clear: only a task that carries a checkpoint and holds the resumable status can resume. It is not true that any task can resume from where it stopped. Tasks in other states cannot resume and return a 409 response instead. The search runtime does not support resuming. The continuation starts from the checkpoint, not from the beginning of the task. Split tasks may sit in different interruption states: the ones that can resume follow the checkpoint path, and the ones that cannot are handled as 409 responses. The two kinds of results are not blended into a single claim that everything can resume.

Where does this split-and-join model stop?

This split-and-join model stops at three boundaries. The first is that not every operation requires approval. Only actions that trigger a gate stop and wait for user confirmation, and this article makes no claim about confirmation for other operations. The second is that not every task can resume. Only tasks that carry a checkpoint and hold the resumable status can resume by hand, and the search runtime does not support it. The third is that no automatic combined result is promised. Bringing together means progress and results return to the same window under the same task and are confirmed by two record locations, not that some unexplained mechanism writes the conclusion for the user.

The three boundaries together with the split-and-join process give the complete picture of several agents working on one task. Splitting is dispatch and queueing. Bringing together is the same window, the same task, and two record locations that match. The human checkpoint is the confirmation card at a gate. Resuming is a task with a checkpoint and the resumable status, resumed by hand. Each claim covers only behavior that has been checked, and none of them borrows another one's implementation. The practical test for whether a task was truly brought together is simple: open the same window, find the same task, and check that the audit entries and the session files tell the same story. If either side is missing, the work is not yet joined, and the honest statement is that it is still in progress. Walking the full chain in order looks like this: the user describes one task in Chinese, the task enters dispatch and queueing, it moves ahead in queue order, actions that trigger a gate stop for the confirmation card, progress and results return to the same window under the same task and are confirmed by the audit table and the session files, and after an interruption only tasks with a checkpoint and the resumable status resume by hand. If any link in the chain does not match, that link is handled by its own boundary first, rather than describing the whole chain as already completed. For comparison, the Microsoft Learn documentation shows how another platform writes its Chinese-language explanations, but this article's claims about Aiglade stay with dispatch and queueing, the confirmation card, and the two record locations.