Routing & recovery

Routing and recovery solve two different problems:

Model Router decides which provider/model is a suitable candidate for the work.
Runtime Supervisor decides what to do when durable execution stalls, fails, or needs a person.

Model Router

Choosing a model can depend on more than a provider name and model id.

Routing requirements can include:

modality;
required tools;
privacy and locality;
context requirements;
provider/model capabilities;
runtime and resource constraints.

The core routing stages are integrated on the current Preview stack.

Resource coordination is not finished yet

Deeper resource coordination still needs a public Model Manager interface for preparing a runtime and checking whether it can run.

The Router should not reach into Model Manager’s private code just to start or prepare resources. That integration stays blocked until a public interface exists.

Runtime Supervisor

Runtime Supervisor handles durable recovery decisions for situations such as:

execution failure;
deadlines or stalls;
recovery after startup;
verification failure;
escalation to a Human Task.

Those decisions are stored as part of the work state instead of being one-off frontend retries.

Router fallback is still blocked

Supervisor-driven Router fallback is intentionally not implemented yet.

If a WorkExecution fails, the system needs to remember the full routing requirements that produced the original candidate—not just the provider/model ids.

Otherwise it could lose constraints such as modality, tools, privacy, context, or runtime requirements and choose a fallback for the wrong reasons.

That fallback path stays blocked until the system can durably record the routing requirements and the candidate chosen from them.

Principle

When an integration is not ready, LM Nexus prefers to block it explicitly rather than store the wrong meaning in an unrelated field or reach into another module’s private code.