RFC: Collaborative Task Mode

[musashi1612]

I would like to propose a new optional task mode for Emdash called Collaborative Task Mode.

Today, an Emdash task can spawn a coding agent in an isolated Git worktree. This is already very useful because it lets users run multiple agents in parallel, review their diffs, and merge what works. However, complex software tasks often need more than one type of agent. A real development task may need planning, implementation, debugging, testing, review, and final integration. Asking one agent to do all of that inside one context often leads to context overload, repeated mistakes, weak verification, and unclear handoffs.

Collaborative Task Mode would allow one task to spawn a selected team of agents and coordinate them through structured project memory instead of letting each agent work in isolation. The goal is not just to run more agents. The goal is to make multiple agents collaborate toward one task in a structured, inspectable, and context efficient way.

Proposed User Flow

When creating a task, the user could optionally choose Collaborative Task Mode.

The task form could ask for the goal, constraints, success criteria, suggested direction, selected agents, model or provider per agent, and permissions per agent.

For example, the goal could be to add authentication to an app. The constraints could be that existing routes should not break and long lived tokens should not be stored in localStorage. The success criteria could be that login works, protected routes work, tests pass, and the reviewer approves the diff. The user could then choose an architect agent, a coder agent, a debugger agent, a reviewer agent, a tester agent, and a supervisor agent. The exact provider or model for each role would remain the user’s choice. For example, the architect could use Kilocode, the coder could use Codex, the debugger could use OpenCode, the reviewer could use Claude Code, and the supervisor could use Pi.

After the user clicks Spawn Collaborative Task, Emdash would create the task and start a coordinated multi agent pipeline.

Core Idea

The core idea is that agents should not collaborate by sending long natural language transcripts to each other. That would quickly become noisy, expensive, and difficult to debug.

Instead, agents should collaborate through structured task state stored in the project database. Each agent still works in its own isolated worktree, but every meaningful result becomes part of a shared task memory. This includes plans, subtasks, claims, blockers, decisions, diffs, test results, review comments, failure summaries, merge candidates, and next action requests.

The project database becomes the shared source of truth. The gateway executes actions. The context builder creates compact context packets. The supervisor agent decides which agent should act next. This keeps the system structured while still allowing different agents and providers to contribute to one goal.

Q1: How do isolated worktree agents collaborate toward one multi layered goal?

The agents collaborate through the project database, the gateway, the context builder, and the supervisor agent.

For example, the architect agent first creates a plan. The gateway stores that plan as structured task state. The context builder then creates a coder context packet using the plan, constraints, relevant files, and success criteria. The coder agent implements the task in an isolated worktree. The gateway stores the changed files, diff, terminal logs, and implementation summary. The context builder then creates a reviewer packet containing the goal, constraints, diff, test status, and review checklist. The reviewer writes structured review comments. If tests fail or review issues are found, the supervisor routes only the relevant failure context to a debugger agent. The debugger works in a separate worktree or on a copy of the candidate worktree. The supervisor then compares the current state and recommends the next action or prepares a final merge candidate.

The important point is that agents do not share raw conversation history. They publish structured state to the shared task database and receive role specific context packets generated from that database.

This keeps every agent focused. The architect receives the goal, constraints, repository summary, and success criteria. The coder receives the plan, relevant files, implementation instructions, and constraints. The debugger receives failing tests, stack traces, changed files, and previous failed attempts. The reviewer receives the goal, constraints, diff, test results, and review checklist. The supervisor receives compact task state and available next actions.

So the worktrees remain isolated at the file system level, but collaboration happens through a structured task state layer.

Q2: How is this better than manually spawning the same isolated worktrees?

Manually spawning multiple worktrees is useful, but it makes the user the coordination layer.

The user has to decide which agent should act next, copy relevant context between agents, compare terminal outputs, inspect diffs, route failures to another agent, remember previous failed attempts, ask for reviews, run tests, and decide which implementation should become the final merge candidate.

Collaborative Task Mode keeps the same benefit of isolated worktrees, but adds structured coordination on top of them. The user still controls the task and reviews the final result, but the system handles the collaboration loop. The gateway creates and manages worktrees. The database stores shared task memory. The context builder gives each agent only the context it needs. The supervisor routes the next action. The reviewer, tester, debugger, and coder can work as part of one task instead of disconnected parallel tasks.

In the current manual flow, several agents can work in parallel, but their knowledge does not naturally combine. In Collaborative Task Mode, their outputs become part of one shared task state. This means the user is no longer forced to manually copy context from one terminal to another. The system can preserve the reasoning trail, the rejected attempts, the test failures, the review comments, and the final merge decision inside the task itself.

The difference is simple. Manual worktrees give isolated execution. Collaborative Task Mode gives isolated execution plus structured coordination.

Q3: How does this improve code quality and the software development process?

This architecture does not make any individual model magically smarter. It improves the development process around the models.

A single coding agent often has to plan, edit, debug, test, and review at the same time. That creates a large and messy context. Collaborative Task Mode separates responsibilities. The architect can focus on the approach. The coder can focus on implementation. The tester can focus on validation. The debugger can focus on failures. The reviewer can focus on correctness, maintainability, and risk. The supervisor can focus on routing the task and deciding what should happen next.

This can improve code quality because each agent receives narrower and cleaner context. It can also improve reliability because the output is not accepted immediately after implementation. It can move through test results, review comments, failure handling, and final human approval. The system also remembers failed attempts and important decisions, so later agents do not repeat the same mistakes.

For the software development process, this creates a more traceable workflow. The task contains the goal, constraints, success criteria, agent roles, worktrees, diffs, tests, blockers, reviews, and final merge candidate. Instead of scattered terminals and chats, the user gets one structured task history. This makes the final result easier to trust, review, debug, and improve.

Proposed Architecture

The feature could be built around four components.

The first component is the gateway. The gateway is the deterministic execution layer. It creates worktrees, spawns selected providers, captures terminal output, stores diffs and logs, enforces permissions, and writes events into the project database. The gateway should execute actions, but it should not make high level reasoning decisions by itself.

The second component is the supervisor agent. The supervisor agent is the reasoning layer. A minimal harness like Pi could be useful here because it can run headlessly and can be integrated into another system. The supervisor reads structured task state, decides which agent should act next, decides what context each agent needs, routes failures to the right role, compares outputs, and recommends a merge candidate. The supervisor should propose structured actions, while the gateway validates and executes them.

The third component is the context builder. The context builder prevents context explosion. It does not send every log, message, and diff to every agent. Instead, it creates compact context packets from the project database. A reviewer packet may contain the goal, constraints, diff, test status, and review focus. A debugger packet may contain the failing command, stack trace, changed files, and previous failed attempts. A supervisor packet may contain compact task state and available next actions.

The fourth component is the action protocol. The supervisor communicates with the gateway through structured actions such as create worktree, spawn agent, run tests, request review, send blocker to debugger, summarize run, compare worktrees, prepare merge candidate, ask user, and stop task. The gateway validates the action, executes it if allowed, and records the result.

Inspiration and Validation

This idea is partly inspired by RecursiveMAS and DroidSpeak. The broader lesson from that direction is that agent collaboration should not depend on long natural language transcripts alone. Agents need a more efficient way to pass useful state, preserve context, and coordinate toward a shared goal.

Sakana Fugu also validates the general direction. It shows that a smaller coordinator can route work across stronger models and tools. Collaborative Task Mode would bring a visible and user controlled version of that idea into the software development workflow, where worktrees, diffs, tests, reviews, and human approval are first class parts of the process.

MVP Scope

A first version could be intentionally small. It could support one collaborative task with one supervisor, one architect, one coder, one reviewer, and one debugger or tester. The workflow could be bounded as plan, implement, test, review, debug if needed, and final review. The system would not need hidden model states, KV cache sharing, direct agent to agent terminal control, or fully autonomous merging.

The first version should not replace the existing task mode. It should be an optional mode for larger tasks where manual coordination becomes the bottleneck.

Why This Fits Emdash

Emdash already has the right foundation. It has tasks, isolated worktrees, multiple provider agents, terminal sessions, local state, diff review, merge workflow, and issue based task creation.

Collaborative Task Mode would build on that foundation. It would turn Emdash from a tool that runs many agents in parallel into a tool that can run a coordinated AI engineering team for one task.

[arnestrickmann]

Hi @hp17695,

Thanks for putting together such a detailed proposal.
We plan to expand the ways tasks and automations can be created programmatically in Emdash -for example, through an Emdash CLI or other external triggers.
We’ll review the proposed architecture and MVP scope internally. We’ll keep this discussion open for further feedback and share our thoughts once we’ve evaluated it.

Arne