Multi-Agent Parallel Scheduler: One Screen to Control AI Coding Sessions

1. The Real Bottleneck Is No Longer Model Capability, but Human Attention Bandwidth

Over the past two years, AI coding assistants have undergone an identity shift. They are no longer just “faster compilers” or code suggestion tools; they have become executors that can be assigned work. You describe a goal, and the agent reads code, edits files, runs tests, and reports back. Once this loop works, the developer’s workflow is quietly rewritten.

However, a structural problem quickly appears: the interaction model is still single-session, linear, and one-to-one. In one terminal window, you can only talk to one agent. When it is thinking, you wait. When it is executing, you also wait. If you want to push three tasks forward at the same time, the only option is to open multiple terminals. If you want to switch between tasks, you need split screens or terminal multiplexers to create a grid. If you want to know which task is stuck, you have to scan each window and scroll through thousands of lines of output.

This is essentially managing processes the way one manages threads. There is no scheduler, no unified view, and no state reporting. The human is forced to act like the operating system kernel.

A useful analogy: you hire ten interns. Each one is capable, but each is locked in a separate room. To know what everyone is doing, you must open one door after another. The act of opening doors itself produces no value, yet it consumes a large amount of time.

Three kinds of loss follow from this:

• Serial waiting loss: A single task does not become faster just because you are watching it, but the time that could have been overlapped between tasks is artificially stretched.
• Context switching loss: Every time you switch terminal windows, you have to reload the background of that task: which module is being modified, what conclusion was reached in the previous round, and what remains unfinished. This reload cost is often pure waste.
• State blind-spot loss: When multiple tasks are running, waiting for your reply, or failing silently, there is no aggregated view. Everything depends on memory and manual inspection. The delay in discovering a failed task is often measured in hours.

Therefore, what is needed is not a stronger model, but an extra hand: a control surface that can hold multiple execution streams at the same time and compress their states into one screen.

2. Capability Boundary: The Scheduler Is a Control Plane, Not the Brain

Before designing this kind of “scheduler” or “agent view”, it is important to clarify its role and avoid mismatched expectations. Its core capabilities can be summarized in three things:

1. Register: Create new execution units at very low cost. Ideally, you submit an instruction in a unified input area, press Enter, and a new session row appears. Work begins in the background immediately, without switching windows or changing the current context.

2. Observe: Compress the state of all execution units into a high-density view. At a glance, you can see which sessions are running, which are waiting for input, which have completed, and which have failed or stopped.

3. Intervene: Provide the shortest path for human intervention when a session requires a decision. After intervening, the user can return to the global view without losing context.

It is equally important to define what it does not do: it does not replace the model, it does not raise the intelligence ceiling of a single task, and it does not replace human architectural judgment. In software architecture terms, it is a control plane, while the agent itself remains the data plane. The value of the control plane is to reduce management complexity, not to improve execution capability. Confusing the two leads to dangerous conclusions such as “with a scheduler, no review is needed”. The opposite is true: the higher the parallelism, the higher the requirement for human review.

3. Three-Layer Interface Model: List, Preview, and Drill-Down

A usable scheduler should structure its information architecture in layers rather than flattening everything onto one screen. A recommended model is list - preview - drill-down.

L1: Session Table for Global Situational Awareness

The main surface is a table where each row represents one session. Field design determines information density:

Field	Purpose	Design Notes
Session identifier	Unique location	Short ID plus task title summary for easy verbal reference
Status	Current phase	Use a state-machine enumeration, not free text
Visual encoding	Fast recognition	Use three layers: color, icon, and motion
Current action	What is happening now	Use the agent’s latest action summary
Workspace / branch	Isolation information	Used to judge file conflict risk
Elapsed time and usage	Cost awareness	Duration, token usage, or call count
Waiting reason	Blocking attribution and priority	What kind of decision is needed determines approval priority

A persistent input box should be kept at the bottom. Submit one instruction, a new row appears, and execution begins in the background. Submit another instruction, another row appears. The key benefit of this design is that it does not introduce mode switching. You do not need to leave the current view to start a new task, and your focus stays in the same place.

L2: Preview Panel for Low-Cost Troubleshooting

When a row requires human intervention, the user should not be forced to enter that session immediately. A more reasonable approach is to expand a preview panel in place, showing the latest status, recent messages, pending decisions, and available options. Most blocking situations—confirming an approach, choosing a dependency version, approving a write operation—can be resolved at the preview layer, with nearly zero handling cost.

L3: Full-Screen Drill-Down for Deep Participation

Only when you need to review a complete reasoning chain, inspect diffs line by line, or take over manual operations should you enter full-screen mode. At that point, the experience should be exactly the same as entering a single session directly. Once the task is handled, one return action brings you back to the table.

The significance of the three-layer structure lies in tiered cognitive load. Ninety percent of scenarios should stop at L1 or L2, and only ten percent should require full attention cost. This design logic is similar to that of top, tmux session lists, and task managers in operating systems.

4. Session State Machine: Make “Stuck” a First-Class Citizen

The reliability of a scheduler depends almost entirely on the rigor of its state model. A minimum viable state set is:

RUNNING     # Executing and producing output
WAITING     # Blocked, waiting for human input or decision
SUCCEEDED   # Task completed, output ready
FAILED      # Exited abnormally, needs root-cause analysis
STOPPED     # Manually stopped, can be resumed
QUEUED      # Registered but not started, limited by concurrency cap

State transitions must be explicitly defined. Any undefined transition should be treated as an exception:

QUEUED    -> RUNNING | STOPPED
RUNNING   -> WAITING | SUCCEEDED | FAILED | STOPPED
WAITING   -> RUNNING | STOPPED | FAILED
SUCCEEDED -> RUNNING            # Re-activated after follow-up instructions
FAILED    -> RUNNING | STOPPED  # Retry after repair

Three engineering constraints deserve emphasis:

• Visual encoding must not rely on color alone. Color distinction has issues with color vision deficiency and terminal theme differences. It is necessary to use icon shapes and motion at the same time: motion indicates execution, while static icons with different shapes indicate waiting, success, failure, or stop.

• State must be event-driven, not scraped by polling output. Parsing terminal text to infer state is a fragile anti-pattern. Any output format change can cause misjudgment. The correct approach is for the execution side to actively report structured state events.

• State must be persisted. Process crashes, terminal closure, or machine restarts should not make a session unrecoverable. At minimum, the task definition, current state, output path, and recent context summary should be saved.

5. Blocking Is the Most Expensive Waste: Batch Human Decisions

Parallel sessions introduce an easily overlooked bottleneck: the human is a serial resource. Five sessions may raise questions at the same time, but you can only answer one at a time. If the queue has no strategy, it will produce a lot of inefficient thrashing.

Mitigation measures, ordered by return on investment, are:

1. Reduce the total number of questions. At the task description level, instruct the agent to “complete all decisions it can make autonomously and only ask when facing irreversible operations, external dependencies, or ambiguous requirements”. Change “confirm every step” into “confirm only key decision points”.

2. Turn choices into upfront policies. Common decisions—dependency version policy, error-handling style, whether test files may be modified, commit granularity—should be defined once before the task starts, rather than asked repeatedly during execution.

3. Prioritize by blocking type, not by arrival time. Irreversible operations should be handled first. Style-related choices can be deferred and batch-processed.

4. Set timeout fallback. A session that does not respond for a long time should not occupy a slot indefinitely. After timeout, it should automatically become STOPPED and preserve its state, rather than hanging silently.

6. Engineering Implementation Priorities: Isolation, Event Flow, and Concurrency Governance

From an implementation perspective, a scheduler must solve five kinds of problems.

1. Session Isolation

Each session needs an independent pseudo-terminal (PTY) or subprocess to carry interactive output. The working directory should preferably use an independent copy or an independent branch to prevent multiple agents from writing to the same file and overwriting each other. Stronger isolation can use containerized execution, which naturally provides boundaries for the file system, network, and resource limits. The judgment criterion is simple: can any two sessions be safely killed at the same time without affecting each other?

2. One-Way Data Flow

A recommended one-way data flow is:

session execution side -> structured event stream -> aggregator -> rendering layer

For example:

{
  "session_id": "s-014",
  "event": "state_changed",
  "from": "RUNNING",
  "to": "WAITING",
  "reason": "needs_decision",
  "summary": "Need to confirm whether to introduce a new parsing library",
  "options": ["Keep handwritten parsing", "Introduce dependency"],
  "ts": 1756300000
}

The rendering layer does not modify state in reverse. All changes go through events. This allows multiple windows, web clients, and log archives to share the same event stream. State consistency no longer depends on interface synchronization.

3. Rendering and Incremental Updates

When the number of sessions reaches dozens, full redrawing becomes a bottleneck. Use virtual lists to render only visible areas. Trigger row updates only when state changes. Non-critical fields such as elapsed time and usage can be refreshed at low frequency. Also note that high-frequency animations can continuously consume CPU during long sessions. Animation throttling or an on/off switch should be provided.

4. Concurrency and Resource Governance

A global concurrency limit is required. Sessions beyond the limit enter QUEUED. Each session should have an independent resource quota and timeout policy. Failed retries should use exponential backoff. At the same time, “usage” should be exposed as a first-class metric in the session table. After parallelism increases, cost usually grows faster than output. Parallelism without a cost view is out of control.

5. Conflict Detection

Multiple agents modifying the same code repository in parallel is the most frequent source of failures. Practical approaches include:

• Assigning non-overlapping file or module scopes to each session.
• Performing content- and timestamp-based conflict detection before writes and preventing overwrites.
• Using independent branches for each session and resolving conflicts during merge.

Parallelism must match isolation strength. This is the key prerequisite for the whole approach to be practical.

7. Common Anti-Patterns

• Parallelism exceeds review capacity. Running ten tasks at once while reviewing one file per minute only moves the queue from the machine to the human. Reasonable parallelism should be approximately equal to the number of tasks you can effectively review per unit time.

• Zero-isolation parallelism. Sharing the same working directory is the most common pitfall. Symptoms include “changes mysteriously disappear” and “tests fail randomly”.

• Only running state, no blocking view. Tasks fail silently for hours with no one noticing. The loss can far exceed the benefit brought by the scheduler.

• State is not persisted. Closing a terminal loses the entire scene and increases workload.

• Lack of visibility into cost and usage. Parallelism amplifies consumption, but there is no corresponding observation mechanism.

8. From a Single-Machine Scheduler to a Team-Level Agent Platform

On a single machine, a scheduler is a local interface problem. Once it expands to a team, the nature of the problem changes: sessions need to be visible across people, migratable across machines, archived for execution results, and traceable. Identity, permissions, and usage aggregation also become hard requirements. At this point, a more reasonable form is to make the scheduling capability a platform-level control plane and reuse mature general cloud capability categories:

• Use a container platform to carry session execution environments and obtain isolation, elasticity, and resource limits.
• Use a message queue to carry the state event stream, decouple the execution side from the display side, and support multi-client subscriptions.
• Use a log service to archive complete session records and support retrospective tracing and experience review.
• Use object storage to retain code artifacts, test reports, and diff snapshots.
• Use monitoring and alerting to set thresholds for failure rate, blocking duration, and resource usage, and to notify actively.

On Baidu AI Cloud, the above capabilities are provided as general product categories. Teams can use them to evolve a local session scheduler into an agent runtime platform with unified identity, auditing, and cost aggregation capabilities, without having to build the underlying infrastructure from scratch.

9. Implementation Checklist

If you are preparing to build or use this kind of scheduling capability, it is recommended to proceed in the following order:

1. Define the state machine first. Clarify enumerations, transitions, and exception handling before building the interface. If the state model is wrong, a polished interface is useless.

2. Establish the event flow. Ensure state is reported by the execution side and all display clients share the same event stream.

3. Implement isolation. Give each session an independent working directory or branch, and add conflict detection before writes.

4. Add blocking views and batch handling. Minimize the cost of human intervention.

5. Add usage and cost views. Set global concurrency limits and timeout fallback.

6. Optimize experience last. Preview panels, keyboard shortcuts, and animation throttling should come after the core mechanisms are in place.

10. Conclusion

The real meaning of this capability is not to make AI stronger, but to change the posture of human-AI collaboration: from face-to-face conversation to dispatch and review. Your role shifts from conversational partner to supervisor: assign work, scan the table, answer necessary questions, and review results.

It is worth noting that this upgrade raises two capability requirements: task decomposition and result review. If work is assigned vaguely, parallelism will produce deviations in multiple directions at the same time. If review cannot keep up, parallelism becomes pure risk exposure. A scheduler turns parallelism from “impossible” into “possible”, but whether it becomes “done well” still depends on how humans design the system, including the state model, isolation strategy, and upfront decision policies. Tools solve parallelism; humans solve consistency after parallelism.