Which Agent Should Act Next—and What Must Happen Afterward?

Article 9 connected observations into possible explanations. Now consider whether training can improve how agents share work. Routing a familiar task to a specialized bot may be straightforward. Coordinating several cases can involve competing resources, dependencies, permissions, and deadlines.

Start with a practical baseline. A routing table maps each task type to an eligible worker; a fixed workflow defines the next steps. Results return to coordinating code, which checks inputs, tracks status, enforces approval rules, and handles failures with configured retries or escalation. Ready tasks enter a first-in-first-out queue. Workers can already use language models; the coordination policy is manually specified.¹

A briefing needs approval by 10:15. Starting at 10:00, Quick can produce prose by 10:03; Trace can produce a versioned draft with source links by 10:06. These are planning estimates. Check requires those links and takes four minutes. Maya is available at 10:10–10:15 for a five-minute release decision. Both a passing check and her approval are required for delivery.

A simple eligibility rule—“Drafting must produce the source links needed for checking”—selects Trace. The fixed workflow can follow the arrangement below. Nobody is available to add Quick's missing links before the deadline, so its shorter writing time provides no usable advantage here.

An illustrative phrase pattern is “<task> requires <output>.” For example, “Check claims requires Draft v1 with source links.” The relationship map expresses the dependency; the Gantt chart places the same tasks in time.

The controller advances only after the required output arrives. Check records the draft version and its result; Maya's approval refers to that same version. A revised draft needs a fresh check. A straightforward baseline can enforce these handoff rules.

The training proposal now faces a specific question: can it improve coordination when many such workflows interact? The comparison starts with a baseline that already performs these routine checks.

Now give the controller two briefings. Both source-linked drafts are ready at 10:06, but A entered the queue first. A needs approval by 10:25; B by 10:15. Check and Maya are available through 10:25, each handling one task at a time. Fix checking at four minutes and each decision at five, without interruption. For this worked example, assume passing checks, approvals, and zero handoff time.

With first-in-first-out, B's decision would end at 10:20, five minutes late. A deadline check can flag the conflict; finding a repair requires another choice. Choosing B first meets both deadlines with the same workers. Every task goes to the appropriate worker in both schedules. The problem is how their commitments fit together. A deadline-priority rule finds the better route without training; it belongs in the benchmark too.

If each of n tasks has k eligible handlers, there are kⁿ raw assignments: twelve tasks with three options each give 531,441. This counts choices before compatibility checks, ordering, and timing. Dependencies couple those choices, but the count alone does not establish runtime difficulty or a need for training. Algorithms can exploit independence and prune incompatible choices; constraint solvers already address related scheduling problems.²

Training could help a coordinator choose combinations that work well together, recognize missing inputs, and recover after failed handoffs. The proposed training unit is a whole case: its tasks, workers, input and output requirements, resource commitments, deadlines, evidence, and observed results.

The same relationship vocabulary can support labels. Illustrative statements include “<task> requires <output>” and “<review record> concerns <draft version>.” In the proposed Decision Lab training approach, these descriptions would guide arrangement checks and the labels exported for training. Reviewed cases can identify compatible arrangements, capacity conflicts, unsupported claims, and missing approvals. Keep case identities and rule versions consistent across each specialist's examples. Preserve multiple valid routes; mixing parts of different valid arrangements can produce an invalid handoff.

Train first on reviewed examples, then collect actual interactions, including imperfect outputs and recovery actions. Training targets include proceeding, requesting evidence, revising a proposal, and escalating. Begin by training only the coordinator while holding specialist bots fixed. Training those specialists together is a separate experiment. MALT provides a precedent for training generation, verification, and refinement roles from combined outcomes on reasoning benchmarks; gains in this workflow still require measurement.³

The comparison should separate the benefit of explicit constraints from the benefit of training:

Give every arm the same evidence, task descriptions, permissions, specialist bots, runtime checks, and execution budget. The prompted and trained coordinators should use the same prompt and model architecture. Within the trained arm, compare isolated task-routing labels with whole-case and handoff labels at matched training budgets. Freeze policies before testing. Report training and labeling effort, planning time, model calls, and maintenance costs separately.

Hold out entire cases and dependency combinations. Include simultaneous work, unavailable workers, late outputs, missing evidence, and cases with no feasible arrangement. For small cases, an exact solver can establish model feasibility; independent review must still check evidence and whether the model represents the task correctly. Multiple valid routes should count as correct.

For feasible cases, measure complete workflows finished correctly by the deadline, including valid handoffs and approvals. Also count invalid proposals caught by checks, violations that escape, false blocks, human repairs, latency, and cost. Score appropriate escalation separately when a case is infeasible or underspecified. Use paired cases and repeated runs for stochastic models, reporting variation.

Keep runtime checks after training. A model could learn to satisfy a checker using unsupported claims; consistency alone does not authenticate evidence. Changing only the coordinator helps show whether better proposals and fewer repairs come from training. If fixed rules or a solver achieve the same outcomes more cheaply, they remain the stronger choice.

The potential value is better coordination on unfamiliar combinations at an acceptable total cost. That experiment remains to be run; the schedules here demonstrate the problem and a baseline improvement.