AI workload scheduling: a control tower for AI work

Picture an airport with a thousand runways and no control tower. Planes would still land. Most of the time. Nobody could tell you which runway a flight used, why, or whether it followed the rules for that airspace.

That is roughly where AI capacity is heading. More of it is being built in more places: big campuses, smaller sites near cities, rooms next to factories and power plants. The capacity is spreading out. What it still lacks is the tower.

The problem with many places

When AI ran in a few giant regions, the question "where should this request go?" had a short answer. You picked a region and everything went there.

Spread capacity across many sites and the question gets harder, and more interesting. For each request, someone or something has to decide:

• Which sites are allowed to run it, given where the data is permitted to go?
• Which of those sites is close enough to answer in time?
• Which one has the right model loaded and room to take the work right now?
• What happens if that site is busy or goes offline halfway through?

And once the work is done, a buyer will reasonably ask: where did it run, and can you prove it?

A person can't answer those questions thousands of times a second. A traffic controller for AI work can.

What a traffic controller would do

Think of it as three jobs, done for every request.

Pick the site. Each request arrives with rules attached. Some rules are firm, such as "this data must be processed in Germany." Some are preferences, such as "answer as fast as you can" or "use the cheaper option if it's close." The controller reads the rules and chooses a site that fits.

Meter the work. As the request runs, the controller measures what was used: which model, how much work, how long. That becomes the basis for a fair bill and for planning more capacity where demand is growing.

Keep a record. When the work is done, the controller writes down what was promised, where the work was placed and what was delivered. That record is something a finance or compliance team can check later, without taking anyone's word for it.

Firm rules and flexible ones

A key design choice is how the controller treats rules when things get busy.

A sensible approach splits them into two kinds. A hard rule is never relaxed. If a buyer says the work must stay in one country, it stays there, even if that means waiting. A soft rule can bend within limits. If the nearest site is full, a soft rule might allow the next site over, or a different machine in the same place. What it can never do is widen the jurisdiction.

That split matters because it lets a network stay flexible without quietly breaking promises. Flexibility lives inside the boundaries the buyer set.

Following one request

Here is the path a single request would take through a controller like this:

1. Request. An application sends a prompt.
2. Policy. The controller checks the rules attached to it.
3. Region. It narrows the options to the places the rules allow.
4. Cell. Within a region, it picks a group of machines.
5. Node. Within that group, it picks a machine with room.
6. Engine. The model runs on that machine and produces the answer.
7. Delivery record. The controller records what happened.

From the buyer's side, it looks like one simple call. Underneath, every step is a decision that respects the rules. If a step can't be completed, a controller built this way would go back one step and choose again, still inside the same rules.

Commit, place, deliver

A useful way to describe the record is in three words.

Commit is what was promised: the model, the rules, the terms. Place is where the work actually ran. Deliver is what came back, and when.

Put those side by side and you have something close to a receipt for AI work. It answers the questions buyers keep asking and rarely get answered today.

Why it should not care about the chip

One more design choice matters. A controller like this should be built to run across accelerator vendors. AI chips will keep changing. A network that only works with one kind of hardware ties its buyers to one supplier's roadmap and prices. A controller that treats chips as interchangeable resources lets the network use whatever capacity is available and suited to the job.

Questions to ask any provider

Whether or not you ever use our network, these are fair questions for anyone running your AI workloads:

• Can I set rules that are never relaxed, and see proof they were followed?
• When a site is busy, what can change and what can't?
• Can I see where each request ran, after the fact?
• Is your setup tied to one chip vendor?

What we're building

This is the idea behind Starfield Fabric, which is in development: one control plane for distributed AI inference. Fabric is designed to schedule, meter and record every request across many sites, following the path above, with hard and soft policies and a delivery record for every workload.

Underneath it, we are building standardized compute close to power, connectivity and demand, connected through one programmable network for AI inference.

If you want to follow Fabric as it develops, start from the Starfield Fabric page. For the basics behind this, read what AI inference is, and keep the AI infrastructure glossary open for the terms.