Multi-Agent Low-Blocking Scheduling: Dispatch-Only Main Session and Configuration

As agents move from “single-turn Q&A” to “long-running task execution,” the bottleneck often shifts from model capability to human attention. In practice, a single maintainer can effectively follow only three to five active sessions at a time. Once the number of sessions increases, users struggle to review all outputs and are interrupted by follow-up questions, confirmations, and corrections. Efficiency drops instead of improving. The core problem is therefore not simply making the model produce better answers, but making the system better at managing the task flow.

A common pain point in multi-session environments is message-induced blocking. While the main session is executing a task, the user may suddenly add a constraint such as “change the previous request to read-only mode,” or insert a small, low-risk query. If the system must stop the current task immediately to handle the message, the existing execution context may be damaged. If the system ignores it, the user may feel the agent is unresponsive. A more reasonable approach is to treat user-interjected messages as independent events rather than forced interruptions to the current execution stream.

1. Why “the main session only dispatches work” is often unstable when enforced only by prompts

Many teams initially try to constrain agent behavior through prompts, for example by requiring the main session to “not complete tasks itself, only split and delegate them.” In complex message flows, however, this kind of constraint is often unstable. The reason is straightforward: a prompt is a soft preference, not runtime control flow. When a model has access to execution tools, it may easily call them and complete tasks directly, especially when a task appears small or quick.

A simple prototype experiment illustrates the issue. In a high-noise message flow, the system receives many chat messages, status messages, and build messages per round, with only a small number of genuine execution tasks. In a structure using “one main session plus subagent tools,” where the main session decides whether to delegate work, the outcomes differ clearly.

When the prompt only asks the main session to “complete tasks reasonably,” it will likely execute all tasks itself. This may appear to complete the work, but the main-session context becomes continuously filled with new messages, causing frequent interruptions and making long-tail tasks slower.

When the prompt explicitly prioritizes delegation, the main session launches subagents in most rounds, but exceptions still occur. If the model decides that a task is small enough, it may return to direct execution. Such exceptions significantly increase the probability of slow tail tasks, because the main session must handle both task execution and incoming message injection.

A more stable approach is to move the “delegate or execute” decision out of the model’s discretion and into a runtime policy. The main session is allowed only to understand intent, split tasks, route work, and summarize results; it is not allowed to execute specific tasks directly. Deterministic constraints at the architectural level are more reliable than soft suggestions at the prompt level.

2. Controller-style architecture: separating the control plane from the execution plane

A more robust design separates the agent system into a control plane and an execution plane.

The control plane is handled by the main session. Its responsibilities include:

1. Understanding user goals and determining whether executable tasks exist.
2. Splitting tasks into subtasks with clear inputs, outputs, constraints, and acceptance criteria.
3. Deciding dispatch order based on risk, priority, and resource constraints.
4. Collecting subagent results, summarizing them, validating them, and aggregating them.
5. Keeping interaction with the user low-noise and returning only necessary status or final conclusions.

The execution plane is handled by subagents. Its responsibilities include:

1. Completing tasks within isolated contexts.
2. Inheriting only the minimal context needed to complete each task.
3. Calling tools such as retrieval, code execution, file processing, or data analysis when needed.
4. Returning structured results instead of sending all verbose intermediate steps back to the main session.
5. Requesting approval from the control plane when permission or risk boundaries are encountered.

The key of this design is not simply adding a “subagent tool.” It is making the session lifecycle explicit. The main session acts like a scheduler, while subagents act like worker units. The scheduler keeps its context clean, and worker units execute in isolated environments, reducing cross-contamination between tasks.

3. Non-blocking interruption: using a side-channel message queue

In multi-task scenarios, user interjections should not automatically trigger an interruption. A more reasonable design routes messages into different channels:

1. Control messages: change priority, pause, terminate, or authorize.
2. Supplementary messages: add constraints or background to the current task.
3. New-task messages: new requests unrelated to the current task.
4. Query messages: ask about progress, results, or status.

By default, the main session should not stop a subtask immediately because of a normal supplementary message. The system can write the message into a side inbox, and the main session can read it at a safe point. A safe point may be a phase transition in the task, completion of a tool call, return of a subagent result, or completion of a main-session aggregation step.

If a message is truly urgent, priority markers can be introduced:

interrupt_policy:
  default: enqueue
  urgent: preempt
  query: non_blocking_reply

Here, enqueue means the message enters a queue and waits for processing; preempt allows preemption of a lower-priority current task; non_blocking_reply returns status only and does not affect the execution stream.

The benefit is that users do not interrupt the agent every time they type a message. For long-running tasks, reducing invalid interruptions is more important than chasing immediate response. The system can acknowledge receipt with a short reply such as “received; will be merged into the next check,” instead of forcing the model to switch context immediately.

4. Key observations from prototype experiments

In simulated environments with high message noise, multiple tasks, and continuous message injection, a controller-style structure generally shows more stable tail latency than a traditional single-session structure.

In the traditional single-session mode, the main session must receive messages, execute tasks, and handle follow-ups at the same time. Its context keeps expanding. Once a new message arrives, the model may be drawn toward the latest content, causing the current task to be paused or redone.

In the controller-style structure, the main-session context is compressed to task understanding, routing, and summarization. Specific execution is delegated to subagents. Because the main session no longer holds large amounts of tool-call detail, it is less likely to be polluted by irrelevant messages. Subagents can run in parallel, tasks are less likely to interfere with one another, and overall completion time is easier to control.

One caveat is that the controller-style structure may increase context-reading volume. Each subagent may need to read task instructions, necessary background, shared facts, and return templates. This may appear to increase context consumption. However, if prefixes are stable, tasks are reusable, and cache hit rates improve, overall throughput can improve as well. In other words, this architecture does not simply reduce token consumption. It trades context isolation and parallel execution for more stable task-completion efficiency.

5. Task cards: turning delegation into structured contracts

For stable delegation, the main session cannot rely only on natural-language descriptions. Subtasks should be encapsulated as task cards rather than vague chat requests. A minimal task card may look like this:

task_id: task_001
goal: summarize the cause of the most recent build failure
inputs:
  - build log excerpt
  - repository change scope
constraints:
  - read-only; do not modify files
  - no external network access
output_format: markdown_summary
timeout_minutes: 10
priority: high
required_approval: false

A task card converts “what the main session wants to do” into “what a subagent can execute.” Without a task card, a subagent may repeatedly guess the user’s intent. With a task card, it can converge quickly within an isolated context.

In a controller-style architecture, task cards also define permission boundaries. The main session can use the task card to determine whether execution is allowed, whether human confirmation is required, and whether high-risk tools may be called. This centralizes safety policy in the control plane instead of spreading it across individual subagents.

6. General configuration template: making the main session dispatch-only

The following general configuration template is not bound to a specific platform. It can serve as a design reference for multi-agent session systems. The core goals are: the main session does not execute specific tasks by default; user messages enter a queue; subagents run independently; and results are returned in a unified structure.

orchestrator:
  mode: dispatch_only
  main_thread_can_execute: false
  allowed_main_thread_actions:
    - classify_intent
    - split_task
    - route_task
    - summarize_result
    - request_approval
inbox:
  user_messages:
    default_policy: enqueue
    urgent_policy: preempt
    query_policy: non_blocking_reply
  external_events:
    default_policy: enqueue
    batch_window_seconds: 30
delegation:
  min_subtask_complexity: 2
  max_concurrent_subtasks: 5
  default_timeout_minutes: 15
  retry_policy:
    max_retries: 2
    backoff_seconds: 30
  context_isolation: true
  shared_fact_store: true
response:
  main_thread_output:
    - task_ack
    - progress_summary
    - final_report
  subtask_output:
    format: structured_summary
    include_reasoning: false
    include_tool_calls: false
safety:
  require_approval_for:
    - delete_data
    - deploy_release
    - modify_production_config
    - send_external_message
  audit_log: true
observability:
  track_metrics:
    - task_count
    - blocked_duration
    - p50_latency
    - p95_latency
    - retry_rate
    - context_pollution_events

The emphasis is not on exact field names, but on several principles: the main session cannot execute tasks, messages cannot block execution, subtasks must be isolated, results must be structured, and risky actions must require approval.

7. Engineering considerations in practice

First, the main session should remain “thin.” If its context is filled with code diffs, log details, tool outputs, and intermediate reasoning, it may turn back into an executor. It should store only goals, status, the task list, and final result summaries.

Second, subagent context should be “just enough.” Inheriting too much context increases cost and information pollution. Inheriting too little may lead to misunderstandings. A practical approach is to share a stable task background while placing specific inputs in task cards or temporary working directories.

Third, result handoff should be structured. Subagents should not return full reasoning traces directly to the main session. They should return conclusions, evidence, risks, suggested next steps, and necessary references. The main session can then generate user-visible output from these structured results.

Fourth, concurrency should be controlled. Parallel subagents can improve throughput, but excessive concurrency increases review pressure, resource contention, and aggregation difficulty. It is reasonable to start with three to five active subtasks and adjust based on real usage.

Fifth, observability metrics should be designed. At minimum, the system should record task creation time, dispatch time, start time, completion time, failure reasons, retry count, number of user interjections, blocked duration, and context-pollution events. Without these metrics, it is difficult to tell whether the system is improving efficiency or merely adding complexity.

Sixth, generic cloud capabilities can improve stability. For example, message queues can carry side-channel events, object storage can hold task inputs and outputs, logging services can record execution traces, and monitoring/alerting can track timeouts and exceptions. These capabilities do not change the architectural essence, but they make controller-style agents more suitable for long-running operation.

8. Suitable scenarios and limitations

A controller-style architecture is more suitable for the following scenarios:

1. Many tasks exist, and users cannot follow each one deeply.
2. Tasks carry the risk of context pollution.
3. External events or user supplementary messages arrive frequently.
4. Task granularity varies widely, from quick queries to long-running analyses.
5. Clear permission boundaries and audit records are required.

It is not a universal solution. If tasks are highly coupled, splitting them across multiple subagents may increase aggregation cost. If the user only performs single-turn Q&A, the controller-style structure may be too heavy. If tasks require highly continuous reasoning, frequent context isolation may affect result quality. In practice, it is best to start with low-risk, verifiable, rollback-friendly tasks, such as log summarization, code retrieval, document organization, or test-failure cause analysis, and then expand to more complex workflows.

9. Conclusion

The key to a multi-agent system is not to make one session do as much as possible, but to make different roles work at the right layer. A dispatch-only main session keeps the control plane clear. Independent subagents keep task contexts clean. Side-channel queues keep user supplementary information from forcing execution interruptions. Compared with relying on prompts to make the model “voluntarily delegate,” fixing the control flow into the runtime architecture better improves stability and maintainability for long-tail tasks. For teams building low-blocking, multi-task agents, this controller-style scheduling approach is worth validating first.