Skip to main content

02.16Concept

The intelligence is in the ordering

AR Labs' view of AI agent orchestration: every actor, human or agent, needs a task list in the right order, so orchestration is ordering and routing.

On this page
  1. The problem it names
  2. The model
  3. Where it comes from
  4. What exists today

"The intelligence is in the ordering" is AR Labs' idea about orchestrating AI agents: every actor needs the same thing, a list of tasks in the right order. That holds for the person running the organisation, for each AI agent, and for the agents that coordinate other agents. Holding the work is easy; any issue tracker holds thousands of tasks. The intelligence lies in deciding what comes first, second and third, when each thing happens, and who does it. On this view, orchestration is ordering plus routing.

The problem it names

We noticed the same pattern in every place work accumulates. Open browser tabs, the issue tracker, running agent sessions, working documents and agent message inboxes each held everything and had nothing above them deciding what came next. Adding more interfaces to look at the work did not help, because each one drew a queue that did not exist.

An analogy from operating systems frames it. A person is a single-core processor; the work is many threads. When the person acts as both scheduler and executor, holding every thread in their head drains attention even while those threads are not running. An operating system's job is admission control, scheduling and dispatch: the system holds the run queue, the waiting states and the deadlines, so the processor holds only the current task. We want the same for people and for agents.

The model

Read the figure left to right. A few goals lit on the full map become the working map, the working map and three inputs become one actor's numbered queue, and a router sends the top item either to a suitable agent or, when none exists, into a new task to build one.

A dense graph with three lit goals becomes a short working map, then a numbered queue for one actor, then a router to an agent's queue or a new task.Left, the full map: a dense graph of every goal and task with three priority goals lit violet. Dotted lines carry those three into the working map, a short list of goals with the live tasks, sessions, documents and blockers under each. Goal weight, graph position and time and resources order it into a numbered queue for one actor. A router then sends the top item to a suitable agent's queue, or makes building that agent a new task.ONE GRAPH, SEVERAL VIEWSNONE OF THEM IS A SECOND STOREFULL MAPevery goal, concept, taskGOAL 1tasksessiondocGOAL 2sessiondocblockerGOAL 3docblockertaskWORKING MAPa few goals, all live workGOAL WEIGHTGRAPH POSITIONTIME, RESOURCES123456QUEUEfor one actor?SUITABLE AGENT?ITS QUEUE+BUILD IT:A NEW TASKYESNOTHE MAP IS LONG-TERM MEMORY; THE QUEUE IS WHAT ONE ACTOR DOES NEXT
The full map, the working map and one actor's queue are views over the same graph, and a router sends the top item to an agent or makes building one a task.

One structure, several views. The full map is our task graph, all tracked tasks and the dependencies between them, recording every goal, concept and task; it plays the role of long-term memory. The working map is a selection from it: a handful of priority goals, and under each one everything currently live, including tasks, agent sessions, documents, blockers and discussion. The queue is the working map flattened into an order for one actor. None of these is a second store. Each is a view over the same graph, and drawing tools, such as a zoomable canvas or a terminal list, are further views.

The order is computed, not judged in the moment. Three inputs decide it:

Input What it decides
Goal weight Which work matters most, set from the organisation's agreed goals
Graph position What must happen before what; among tasks that are ready, our dependency-graph research recommends ranking first those with the longest chain of work still waiting on them
Time and resources When the work happens and which actor does it

Routing. An orchestrating agent takes the top item and asks whether a suitable agent exists. If one does, the task lands in that agent's queue, which has the same form as everyone else's. If none does, creating that capability becomes a task in its own right.

Lists become primitives. Collections such as a set of browser tabs become objects the system can save, park and bring back later at the right moment, rather than clutter the person must keep track of.

Where it comes from

The idea grew from our practice of designing work as a dependency graph, following graph engineering, a model we adopted from the writer rari: every node has a contract, an edge is a real dependency rather than mere sequence, and routing is deterministic and inspectable. Research we carried out on dependency graphs found that drawing a plan as waves or maps produces a picture for a person to read, while the order in which work is dispatched should come from ranking the ready items, as in the table above.

It also echoes our design for a single autonomous agent. The logical levels design runs from goals to approaches to campaigns and tasks, with evidence kept alongside; it is the same shape for one actor that the ordering idea describes for many.

What exists today

Part of the ordering is built. Taskgraph, our tool for mapping a branch of the task graph, sequences the work in a branch by its dependencies, and VOX Torch and Vox Canvas draw the graph in the terminal and the browser. The missing input is goal weight: the organisation's priorities do not yet flow down into the task graph, so each actor's queue is not yet calculated. Building that queue, first for the person and then for agents with a routing agent between them, is the direction of VOX OS.