Unified Scheduling for Multi-Agent Sessions: Managing Parallel Tasks at a Glance

1. From One-on-One Conversations to Multi-Task Scheduling

Early AI coding assistants functioned much like pair programming: you ask a question, wait for an answer, and proceed to the next step. This model works fine for single tasks. However, when agents can independently handle longer tasks such as modifying code, running tests, and organizing documentation, the limitations of this approach become apparent.

Starting an independent task usually requires a new terminal session. Juggling five tasks means maintaining five windows. Switching tasks involves searching through windows or setting up grid layouts with split-screen tools. Figuring out which task is stuck requires checking outputs one by one. The more tasks there are, the more time users spend “finding the status,” leaving less time for actual decision-making.

This situation can be compared to managing a team of ten interns working in separate closed offices. To check progress, the manager must knock on each door. The problem isn’t the interns’ capabilities, but the lack of centralized, scannable information.

A unified scheduling panel solves this by centralizing information. It shifts the user’s role from a “conversationalist” to a “dispatcher” responsible for assigning tasks, scanning the overview, handling necessary queries, and reviewing results. This role transition changes the focus of interaction design from single-turn input/output experiences to presenting the status of numerous parallel tasks and enabling quick decision-making.

2. Four Core Elements of a Scheduling Panel

1. One Row Per Session

The basic unit of the panel is the session. Each session occupies a row and includes at least the following fields:

• Task Title: A brief description generated from the user’s initial command.
• Current Status: Running, Waiting for Input, Completed, Failed, Stopped.
• Latest Summary: Key information from the most recent output, typically truncated to one or two lines.
• Update Time: Helps determine if a task has stalled.

This structure allows users to complete a full overview scan on a single screen without opening any detail pages.

2. Unified Task Submission Entry

An input box remains at the bottom of the panel. When a user submits a task description, the system creates a session in the background, adds a new row to the list, and execution begins immediately. This process requires no window switching and no waiting for previous tasks to finish.

The design focus for the submission entry is speed and non-blocking behavior. The submission action only handles registration and initiation; time-consuming operations are delegated to the background.

3. Visual Encoding of Status

Status is the most critical information on the scheduling panel. If relying solely on text labels, users must read line by line during a scan, which is inefficient. A common practice is to assign fixed icons and colors to each status, for example:

• Dynamic Icon: Running
• Yellow: Waiting for human confirmation or input
• Green: Completed
• Red: Failed

Two points require attention here. First, color should not be the sole information carrier; it must be paired with icon shapes and text labels to accommodate users with color vision deficiencies. Second, a specific color should maintain a consistent meaning globally to avoid confusion with other UI prompts.

4. Hierarchical Viewing and Blocking Response

Dispatchers rarely need to read the entire output of every session. More commonly, operations occur at three levels:

1. Scanning: Reviewing all statuses in the list to identify which tasks need attention.
2. Previewing: Opening a lightweight panel for a selected session to view the latest few outputs without leaving the main interface.
3. Full-screen Entry: Enlarging the session to the entire window for in-depth troubleshooting or detailed interaction with the agent, returning to the list once done.

For sessions in the “Waiting for Input” state, the panel should support direct replies. This allows the agent’s block to be resolved directly within the list, eliminating the need for the dispatcher to find the corresponding window first.

3. Designing the Status Model

Status definitions must be clear, or the panel will provide misleading information. A viable status model includes the following six states:

• Queued: The task is registered but has not yet acquired execution resources.
• Running: The agent is currently executing.
• Waiting for Input: The agent requires human-provided information or confirmation.
• Completed: The task finished as expected.
• Failed: An error occurred during execution and could not be automatically recovered.
• Stopped: Terminated actively by a human or the system.

Transitions between states should be driven by explicit events. For example, when an agent asks a question or requests confirmation, the session moves from Running to Waiting for Input. Upon the user’s reply, the session returns to Running.

Below is illustrative pseudocode demonstrating the mapping between events and states. It describes a general design concept and does not correspond to any specific product’s API.

Define Session:
    ID
    Title
    Status        # queued | running | waiting_input | completed | failed | stopped
    Latest_Summary
    Update_Time
Define Handle_Event(Session, Event):
    If Event is "Request_Input":
        Session.Status = waiting_input
    Else If Event is "User_Reply":
        Session.Status = running