Who should get the next job?

Hermes needed more than a queue

On 27 July, the work advanced Hermes orchestration, repository strategy and Drive governance. The next task was to define capability-based routing and the limits around automatic dispatch.

The distinction matters. Having tasks in a queue is not the same as knowing which component should perform them. Giving the next available agent a job may be convenient, but convenience is not evidence that it has the information, tools or permission the job requires.

The recorded bottleneck was that autonomous dispatch and specialist routing were not yet operational. This was design work towards a more dependable way to send work to the right place.

For UBIKITOS, the practical question was becoming sharper: when a request arrives, how should the system decide what happens next without turning the founder into the dispatcher for every small step?

That question has much more inside it than a list of agent names.

A capability is more useful than a personality

An agent can be described as diligent, creative or analytical. Those descriptions may influence its writing, but they do not establish what it can reliably do.

Capability-based routing starts from the work. Does the task require reading a source? Producing a structured artifact? Using a particular tool? Checking a result against defined criteria?

The receiving component needs the relevant capability under the actual operating conditions. A specialist label is only useful if it points to something testable.

Consider a hypothetical research request with a source the system cannot access. Routing it to an agent called “research expert” does not solve the access problem. The workflow needs either a legitimate source path or an honest report that the required material is unavailable.

This is why the routing design mattered. It could help the project stop treating a role description as a substitute for an operational requirement. The next job should go to a component because it can meet the task’s needs, not because its name sounds appropriate.

The handoff needs to carry the question

A task can change meaning when it moves between components. The original request may include a qualification that disappears from the shortened instruction passed to the next stage.

A hypothetical instruction to summarise a source while preserving uncertainty might become simply “write a summary.” The output could then be fluent but less careful than the requester intended.

A useful handoff needs to preserve the purpose, the relevant constraints and the expected result. It should also make missing information visible rather than asking the receiving agent to fill the gaps silently.

The orchestration work on 27 July was part of designing this kind of connected workflow. It did not establish that every routing path had already been implemented or tested.

The next practical step was to define the dispatch limits and capability requirements clearly enough that a bounded task could be sent through the system and evaluated. A successful handoff would preserve the question, not merely move some text to another worker.

Automatic dispatch needs a boundary

Sending work automatically can reduce repetitive coordination. It can also create a process that keeps assigning tasks without a clear relationship to the original objective.

The routing system therefore needs to know what it may dispatch and what requires another decision. A proposed task may be outside scope, depend on unavailable information or involve an action that needs human approval.

Those conditions should not be treated as minor inconveniences for the agent to work around. They are part of deciding whether the task is eligible to proceed.

For a harmless internal draft, the boundary may be simple. For a consequential action affecting another system or person, the required authority is different. One routing rule cannot responsibly flatten those cases into “the next task.”

The day’s recorded direction included automatic-dispatch limits for that reason. The goal was useful continuation within an understood remit. It was not a promise that the system should invent and launch any job that seemed related to the project.

The repositories and records had to agree

The same day included repository strategy and Drive governance. Those topics belong in the orchestration story because the work depends on knowing where its instructions and outputs live.

A task can be routed correctly and still use the wrong version of a document. An output can be generated successfully and then become difficult to find or identify. The storage and source strategy affects whether the next stage can trust the material it receives.

This does not mean every file needs to exist in every system. Different locations may serve different purposes. The important part is that the relationship is explicit enough to avoid conflicting claims of authority.

A hypothetical archived draft in Drive should not silently override a current accepted specification in a repository merely because it was easier to retrieve. The workflow needs to understand the status of the source, not just its availability.

The 27 July work was helping define that operating context around Hermes, with the live routing proof still ahead.

A routed failure should teach something specific

When a dispatched task fails, the system needs enough information to distinguish a routing problem from an execution problem.

Was the task sent to a component without the required tool? Were the inputs incomplete? Did the component fail despite having the right conditions? Did the result exist but fail acceptance?

These distinctions affect the next action. Reassigning the same task to another similarly configured agent may simply repeat the failure. Improving the input may be more useful than increasing the number of workers.

The point is to make routing part of an inspectable workflow. The system should be able to explain why a task was assigned and what the result says about that choice.

This is a retrospective way to describe the design requirement, not a claim that a complete routing-learning mechanism was running on the day. The recorded next step remained defining the capabilities and dispatch boundaries needed for a bounded operational path.

The next job needed a reason to go where it went

The day advanced orchestration and the surrounding source strategy. Autonomous specialist routing was still a capability to establish through implementation and testing.

The useful next result would be a task assigned for an explicit reason, executed within its scope and returned with an outcome that could be assessed. That would show more than a queue moving. It would show that the system understood something practical about the relationship between a job and the means of doing it.

For a founder, that is the appeal of orchestration. The system can take over repetitive coordination while keeping its decisions understandable.

The agent’s name can remain memorable. The assignment still needs a reason. On 27 July, the work was moving towards making that reason something the project could inspect rather than something it merely assumed.