Home AEGOS Fleet Scheduling

Scheduling.

How Fleet decides what to run and where to put it — choosing the next job, checking it can run, claiming the resources, and matching work to a machine.

Decisions Choose the next move

A lightweight decision engine chooses what Fleet should do next, within the bounds Core sets. It weighs what is worth running, picks the next job, and hands it down the pipeline — staying small and legible, so you can always see why it chose what it chose. It can only choose within the rules: it cannot authorise a protected action or skip a gate. Real autonomy over what runs next; none over what is allowed.

Allocation Check feasibility, read-only

Before committing to anything, Fleet asks a read-only question: can this job run, and where? Allocation tests the job against current state — a resource with the right capability, free capacity and headroom — and returns candidates, not commitments. Because it touches nothing, it is cheap and safe to call as often as planning needs, so Fleet can weigh a dozen what-ifs before committing to one.

Reservations Claim resources safely

When Fleet commits, it atomically claims the resources it needs with a time-boxed lease, so two jobs never grab the same capacity. A reservation is all-or-nothing: either the capacity was free and is now yours, or the claim fails cleanly — no partial holds, no races. Every reservation carries a lease, so a crashed or hung job can never hold capacity forever; when it lapses, the resource returns to the pool automatically.

Routing By capability, not hardware

Work is described by what it needs — a capability — not by which machine runs it. A job asks for “image generation” or “a 24 GB GPU model” and Fleet finds a resource advertising that capability, so hardware is decoupled from work. Add a machine and it simply advertises its capabilities; retire one and work reroutes. The fleet grows and shrinks without anyone touching the jobs.

Get in touch

← Back to AEGOS