Technology

Models read. Rules check. Solvers decide. Agents act.

Logistics runs on messy inputs and hard constraints. Fero puts language models where the mess is, a deterministic rule engine where your policies are, classical optimisation where the constraints are, and people where the risk is.

One decision, end to end

From WhatsApp order to paid invoice

01 · Readagent
Need 6 pallets Jebel Ali → Al Quoz tomorrow, before 10. Rest of the drops in the sheet. drops_thu.xlsx
Fwd: Sharjah orders · 2 PDFs

Please collect from our Sajaa site after 14:00.

3 channels · 2 formats · 0 re-keying

Architecture

Five layers, one loop

Each layer does the job it is provably good at, and hands a structured result to the next.

  1. 01

    Perceive

    LLMs · OCR · speech

    Emails, WhatsApp messages, PDFs, spreadsheets and phone calls become structured orders, rates and events.

    Order intakeInvoice extractionRate calls
  2. 02

    Check

    Rule engine · policies

    Versioned rules hold your contracts, tariffs, guards and approval limits. Missing or conflicting facts block the action.

    PricingDispatch guardsApprovals
  3. 03

    Decide

    MILP · CP-SAT · metaheuristics

    Solvers search the space of feasible plans and return the best one they can prove, with the reason for anything left out.

    RoutingSchedulingPackingConsolidation
  4. 04

    Act

    Agents · approval gates

    Agents carry the plan out: book, notify, invoice, chase. Risky steps wait for a person.

    DispatchBillingProcurement
  5. 05

    Learn

    Forecasting · evaluation

    Outcomes flow back as training data: demand forecasts sharpen, extraction improves, benchmarks tighten.

    DemandETAsBenchmarks
Try it

Watch a solver think

Routing is a search problem: 48 stops can be visited in more than 10⁶⁰ different orders. Heuristics find excellent answers without trying them all.

Live · runs in your browser

48 stops, one van

The dashed line is what a busy planner does: drive to the nearest stop, repeat. Press solve and a local-search heuristic starts rewiring the route, keeping every change that makes it shorter.

Nearest-stop route
403.5
Current route
403.5
Distance saved
0.0%
Moves evaluated
0
Improvement passes
0
Compute time
0.0 ms

A toy: one vehicle, no time windows. Production solvers add capacity, windows, breaks and a whole fleet, and search far harder.

Rule engine

Your policies, as rules a machine can prove

Between reading and deciding sits a deterministic rule engine. It holds your contracts, tariffs, guards and approval limits, and it is the reason an agent cannot talk its way past them.

DISPATCH-REEFER @v5on DispatchTrip
  1. Leaving a port? Customs must be cleared.customs = CLEARED
  2. Gross weight within the port limit.9,420 kg ≤ 10,000 kg
  3. Weighbridge agrees with the declared weight.Δ 180 kg ≤ ±250 kg
  4. Temperature reading is fresh.age 6 min ≤ 15 min
  5. Temperature within set point.7.4 °C vs 4.0 ± 2 °C

Dispatch blocked

reason REEFER_TEMPERATURE_OUT_OF_RANGE · evidence logged · replayable

  • Readable

    Every rule has a plain-English readback generated from the rule itself, never paraphrased by a model.

  • Fails closed

    A missing or conflicting fact blocks the action. Absence is never consent.

  • Explainable

    Each decision records the rule, version, evidence and reason code, and can be replayed exactly.

  • Versioned

    Rules are effective-dated and frozen on release. Change means supersede, never edit.

  • Shadow mode

    New rules run silently against live traffic, with impact previewed before they enforce anything.

  • Maker–checker

    Whoever proposes a rule cannot approve it. Financial and high-impact rules route to senior approvers.

AI drafts · code verifies · people approve

Describe a policy in plain words, like “offer to our preferred haulier first; if nobody accepts by noon, go to the next”. A language model drafts the rule; the compiler rejects any threshold you did not actually state and asks instead of guessing; an approver signs it off.

Classical algorithms, compute-heavy

The maths does the deciding

Six optimisation engines sit under every Fero product. They search the space of feasible plans and return the best one they can find, with a reason for anything they leave out.

  • 01Trip planning

    Vehicle routing

    Sequences every stop across every vehicle so the fleet covers the day with the fewest tours and kilometres.

    MethodRich VRP · metaheuristic search (Rust)

    Time windowsWeight + volume capacityPickup–delivery pairsDriver breaks
  • 02Linehaul scheduling
    T1T2T3T4

    Constraint scheduling

    Assigns every leg to a vehicle and a driver at the same time, without double-booking either, and protects the cold chain first.

    MethodOR-Tools CP-SAT · interval model

    Driver hoursDock capacityOpening hoursTemperature class
  • 03Order splitting
    3T×410T×240FT×1

    Fleet-mix optimisation

    Chooses the cheapest combination of vehicle types that can legally carry a set of orders, and says how many of each.

    MethodInteger linear programming · branch-and-bound

    Per-type costWeight & volumeItem dimensionsVehicle availability
  • 04Load building

    3D load packing

    Places every carton in the truck or container, in three dimensions, and proves it fits before anyone loads it.

    MethodPivot-based 3D packing · knapsack ILP

    Six rotationsStackabilityCollision checks500–2,000 items per load
  • 05LTL → FTL
    2 SHIPMENTS → 1 TRUCK

    Route-similarity consolidation

    Finds shipments travelling the same way at the same time and merges them onto one vehicle, ranked by utilisation and kilometres saved.

    MethodFréchet-distance matching · parallel (Rust)

    Route shapePickup proximityTime-window overlapDetour tolerance
  • 06Replenishment
    FORECAST

    Demand forecasting

    Predicts what each site will need and when, so routes and capacity are planned for tomorrow's demand rather than yesterday's.

    MethodGradient-boosted trees · seasonal decomposition

    Order cadenceSeasonalityChangepointsOutliers
Why not just a chatbot?

A language model can describe a plan. It cannot prove one.

Routing forty trucks is a combinatorial search problem. Language models are brilliant at reading the world and poor at exhaustive search. Fero uses each for what it is good at.

CapabilityLLM onlyFero
Reads a WhatsApp order, a PDF, a phone call
Returns a plan that is always feasible
Finds the best plan, not a plausible one
Every number traceable to a contract
Says why a load was left out
Applies your policies the same way every time
Stops before it moves money
Agent runtime

Autonomy with guard rails

Agents in Fero are held to rules enforced in code, not in a prompt.

  • Rule 01

    The engine owns every number

    Rates, totals, variances and plans come from deterministic code and solvers. The language model reads, classifies and explains; it never invents a figure.

  • Rule 02

    Risk-tiered actions

    Read-only and low-risk tools run immediately. Anything that changes money or commitments suspends until a person approves it.

  • Rule 03

    Same API, same permissions

    Agents act through the platform's own API with a scoped key, so they can do exactly what their role allows and nothing more.

  • Rule 04

    Fails closed

    A plan is re-checked against live data before it is applied. If anything moved since the solve, nothing is half-applied.

  • Rule 05

    Every refusal has a reason

    A load the solver could not place comes back with the constraint that stopped it, so the fix is obvious.

  • Rule 06

    Budgeted and logged

    Each organisation runs under its own token and cost budget, and every agent action is written to an audit trail.

Bring us one lane. We will show you the difference on your own numbers.

A week of your orders, rates or invoices, run through Fero with your contracts and your carriers.