Douchat Integrates Jev to Enable Multi-Agent Task Collaboration

The most common form of multi-Agent group chat is taking turns speaking: each Agent responds to the same message in sequence. Douchat recently integrated Jev, attempting to change this pattern into collaborating around a single task—not every group message needs all Agents to reply; instead, it first judges whether this matter actually needs collaboration and who needs to collaborate.

The author breaks the overall approach into three layers: Jev handles structured judgment, the LLM handles planning and execution, and the program handles scheduling, state recording, and failure recovery. This division itself reveals the design orientation: judgment and execution are separated, while scheduling and state—parts that are error-prone and must be reliable—are handed to the program rather than left to the model to improvise.

It should be noted that all of the above comes from the author's own account on X, belonging to source-party claims, with no third-party verification or performance data to support it.

The product offers two decision modes. The default decision reuses the LLM configured for group members and does not require a separately configured decision model; Jev decision uses Douchat's cloud decision service and consumes decision credits. The decision model is only responsible for "who does it and how to organize it"; when actually executing tasks, each Agent still uses its own model and tools.

There is a clear fallback path here: when Jev is unavailable, the judgment is uncertain, or the task requires complex planning, it automatically falls back to the member LLM. In other words, Jev decision is not the only pathway; when judgment capability is insufficient, the system hands decision authority back to the member models.

The source does not give the specific credit consumption or billing rules for Jev decision mode, nor does it state whether this integration has been fully rolled out, which users it targets, or what release stage it is in.

After a new task enters the group chat, the program first checks member availability, then combines the task, group chat context, and member capabilities to select a Leader. In default mode, the member LLM returns the Leader and execution plan; in Jev mode, a Choice is used to select a suitable Leader. The Leader is not fixed as the first Agent in the group; for subsequent collaboration on the same task, it tries to retain a healthy and suitable Leader to avoid frequent switching.

An easily misunderstood point is the Leader's authority boundary. According to the author's description, the Leader is the task organizer; the actual dispatching, timeout handling, and state persistence are done by the program. In other words, the Leader takes on an organizational role, not the scheduler itself.

The author also mentions that the Leader is not required to say "received" every time: work that can start directly starts directly, and the Leader speaks first only when hosting, preparation, or clarification is needed.

The first question the decision layer must answer is not "who does it" but "should it be done at all." The author lists five judgment outcomes: no reply needed, handled directly by one member, handled independently in parallel by multiple members, completing member contributions in sequence, and entering more complex task planning.

On member filtering, Jev currently uses Noul to judge one by one whether candidate members still need to participate: clearly relevant ones are selected, clearly irrelevant ones are excluded, and when the judgment is ambiguous it is handed to the LLM for further planning. To reduce waiting, relatively independent issues such as Leader selection, routing, and member relevance can be handled in a single Jev request.

The source does not explain the specific technical implementation and interrelationships of components such as Jev, Noul, Choice, and Score, so here we can only describe the roles each plays and cannot reconstruct the complete call chain.

Currently three execution modes are supported: single-person, serial, and parallel. In serial tasks, subsequent members can see prior results; independent tasks can run in parallel, with at most 4 members executing simultaneously. Simple tasks are assigned directly; complex tasks have the member LLM generate a plan specifying which members participate, what each member specifically delivers, in what order execution proceeds, whether the Leader needs to summarize at the end, and whether necessary information is missing and the user must be waited on first.

The parallel cap of 4 members is a clear constraint, but the source does not state whether this cap is configurable or will be adjusted. The execution process also has count and timeout limits, intended to prevent Agents from handing off to each other indefinitely.

After a member's execution fails, the scheduler requests a decision again, choosing to skip, substitute, or pause. Different tasks are handled differently: personal-participation tasks cannot be impersonated and completed by someone else; explicitly required deliverables cannot be silently skipped just because a member failed.

Completed results are recorded. For steps that may have already produced external operations after an interruption, the system will not blindly rerun—this is a rather conservative constraint, at the cost of possibly sacrificing some smoothness of automatic recovery in exchange for avoiding duplicate side effects.

When further collaboration is needed, the decision layer arranges the next step based on existing results; when user supplementation is needed, it enters a waiting state; after completion, the Leader summarizes as needed.

The author explicitly states that the current plan is still mainly "member division of labor + serial/parallel," and the next step is hoped to upgrade to an explicit DAG, with an example chain given: A and B research in parallel → C organizes the plan → A reviews → Leader summarizes. Each task node has an independent ID, dependencies, executor, deliverables, and status, and the program advances based on dependencies.

On this basis, three more things are planned: task-level supervision, where executors report heartbeats, actual progress, and blocking reasons, distinguishing "still online" from "still making progress"; structured takeover, letting substitutes inherit completed work, artifacts, and remaining tasks, avoiding starting over or duplicating operations; and result acceptance, checking each round whether deliverables meet requirements before deciding to complete, rework, or continue breaking down. Member selection can also further introduce Score to evaluate suitability for different subtasks, while considering confidence and team capability coverage.

These all belong to the direction of "to be filled in next," and the source does not state whether they have been implemented. The source also does not provide any performance, success rate, or comparative benchmark data to verify the actual effect of this collaboration mechanism.