An Agent Architecture Where the Main Session Only Delegates and Never Blocks on Interruptions

3 hr ago0 views

This article presents an agent architecture for high-density group chat and ticket channels, where the main session acts purely as a dispatcher—it classifies messages, creates subtasks, and routes follow-ups, while sub-sessions execute work in parallel. It explains why prompt-level instructions alone cannot enforce delegation, describes a three-layer reference architecture (scheduler, workers, and structured receipts), and provides a practical checklist covering tool isolation, incremental instruction queues, and evaluation metrics focused on tail latency and zero execution by the main session.

In environments where team collaboration coexists with continuous integration, AI agents are often connected to group chats or ticket channels. Message density is high and task types are mixed, so the main session must both understand new instructions and keep unfinished work moving. Two bottlenecks commonly appear in practice. First, human attention is limited: one person can typically follow only a handful of active conversations, and as models produce output faster, reviewing answers and fielding questions grows more intense, quickly saturating cognitive load. Second, execution and interaction are coupled: once the main session does the work itself, later interruptions either get ignored or force a break in the current task, creating long-tail delays.

Making “the main session only delegates and never executes” a hard constraint is more reliable than simply strengthening prompts. The reason: when facing tasks that “look small,” large models still tend to complete them in place to reduce tool round-trips. With neutral prompts, the model may not delegate at all in an entire round. Even when delegation is explicitly prioritized, occasional self-execution still occurs—and it is precisely these exceptions that stretch out the slowest batch of tasks. Therefore, “the main session must not use execution tools” needs to be enforced at the protocol and runtime level, not just written into the system prompt.

Problem Modeling: Multitasking in High-Density Message Streams

A round of interaction can be abstracted as: a large volume of noise messages (discussions, pipeline notifications, irrelevant mentions) mixed with a few real tasks. The main session’s job should be classification, prioritization, delegation, and summarization—not opening the repository, editing code, or running tests. Sub-sessions are created at task granularity, each with independent context and tool permissions, and return structured results upon completion. This way, the ceiling for a single task still depends on model capability, while the ceiling for multiple tasks shifts from “a human watching every session” to “a human watching summaries and exceptions.”

The key to non-blocking interruptions is that the main session is always in a receiving state. Incoming messages enter a queue, and the main session only routes them: clarifications are merged into the corresponding subtask; entirely new requests create new sub-sessions; chit-chat unrelated to ongoing tasks gets a brief reply or none. Sub-sessions are never interrupted by the main session’s next round of reasoning, avoiding the situation where “one changed requirement restarts the entire pipeline.”

Why Prompts Cannot Enforce the Execution Boundary

Comparative experiments (neutral prompts vs. delegation emphasis vs. architectural enforcement) typically show a stable pattern: with neutral prompts, the model tends to execute everything in the main session and gets repeatedly interrupted by new messages; with delegation emphasized, most rounds do delegate, but “this task is too small, I’ll just do it myself” exceptions remain—and these exceptions often correspond to the longest p95 tail. Architectural enforcement (the main session’s toolset contains no file writing, terminal, or browser tools) turns self-execution from a policy choice into an impossibility. In terms of completion time, forced delegation usually improves both median and tail latency. Cached reads may increase, because each sub-session carries its own system prompt and retrieval—this is a reasonable trade of tokens for isolation and parallelism.

The design principle should therefore be: the policy layer’s prompts handle “how to break down tasks and write delegation briefs,” while the mechanism layer handles “the main session cannot execute.” Missing either one, behavior regresses to a single all-in-one assistant session.

Reference Architecture: Scheduler, Workers, and Receipts

A three-layer split is recommended.

Scheduling layer (main session): Only exposes read-only retrieval, subtask creation, status queries, and task cancellation/merging tools. Its input is the message stream; its output is a task graph (titles, acceptance criteria, dependencies, priorities) plus short confirmations to the user. The scheduling layer’s context should be kept as short as possible—only the task board and recent decisions—avoiding pulling any code diff into the main context.

Execution layer (sub-sessions): Each task gets an independent session with tools authorized on demand (code, testing, documentation, retrieval). Sub-sessions do not talk to the user directly; they only return receipts to the scheduling layer: successful artifacts, failure reasons, and a list of questions requiring user decisions. Long-running tasks should send periodic heartbeats so the scheduler can report progress rather than stay silent when the user asks.

Receipts and merging: When a sub-session finishes, it submits a structured result. The scheduler decides whether to reply directly to the user, split further subtasks, or request human confirmation. A user’s mid-task follow-up is routed via task ID to the corresponding worker’s “incremental instructions” queue, consumed by the worker at a safe point (e.g., after the current tool call finishes), rather than by killing the process.

Illustrative pseudocode for the scheduler:

on_message(m):
  t = classify(m)  # new task / supplement / chitchat / system notification
  if t == chitchat: reply_short_or_ignore()
  elif t == new_task:
    spec = plan(m)
    spawn_worker(spec)  # main session must not execute()
  elif t == supplement:
    enqueue_delta(task_id, m)
  refresh_board()

Worker side:

while not cancelled:
  delta = poll_delta()
  step = next_action(spec, delta)
  if step.needs_human: return questions
  apply_tools(step)
return artifact

Experience Considerations for Instant Messaging Channels

Once connected to an instant messaging channel, users habitually “send half a sentence first, then add another.” If the main session is synchronously blocked in a tool loop, the follow-up gets lost or triggers re-entrancy. The correct approach is to separate the main session’s event loop from worker processes: inbound messages always enter the queue first; the main session consumes the queue single-threaded to guarantee routing consistency; workers run as parallel instances. What the user sees is an immediate acknowledgment like “Noted your follow-up, merging it into Task A,” instead of a response after several minutes.

You also need to prevent the main session from “saying it only delegates while still calling execution tools.” Verification methods include: runtime whitelist interception, audit logs confirming the main session’s tool names all belong to the scheduling set, and failing violating calls outright while recording them for evaluation.

Redistributing Attention and Tokens

A single person can follow only a limited number of sessions, because each session asks questions back. Once the main session only delegates, the user faces a task board: in progress, blocked awaiting decisions, and completed awaiting review. The review target changes from “the full chain of thought” to “artifact + diff + risk points,” so the number of tasks reviewable per unit of time rises. On the token side, the main session’s cache is more stable with fewer repeated reads; sub-session caches are independent, so total usage may increase, but tail tasks are no longer repeatedly evicted from the effective prefix by group-chat noise in the main session, and p95 latency often drops. Operationally, apply TTLs to sub-sessions, store results in object storage, and keep only summaries on the board to avoid unbounded growth.

Implementation Checklist

Remove all side-effecting execution capabilities from the main session’s toolset.
Tasks must carry acceptance criteria and a receipt schema; otherwise spawning is not allowed.
Interruptions enter an incremental queue; workers merge them at tool boundaries. No hard interrupts unless the user explicitly cancels.
Load test with synthetic group chats: heavy noise per round plus a fixed number of real tasks, comparing neutral prompts, delegation emphasis, and architectural enforcement across three dimensions—completion rate, p50/p95, and whether the main session executes zero actions.
Replace parallel long conversations in the UI with a task board plus a pending-decisions queue.

In summary, the multitasking ceiling is limited by human attention, while the single-task ceiling is limited by the model and its tools. Only by stripping execution away from the main session—and using mechanisms to prevent it from creeping back—can you achieve both “interruptions are heard” and “the work keeps moving” amid high-density messages. Prompts can improve willingness to delegate, but they cannot replace tool isolation and queue design. Evaluation should treat tail latency and zero main-session execution as hard metrics, not just average success rates.