AI Agents for freight forwarders.

In one paragraph

A disruption — a port strike, a river running low, a corridor closing, a tariff filed — reaches a freight desk through a dozen different institutions, in a dozen different formats, and usually later than it reached somebody local. SQRlane runs on the bookings in a forwarder's TMS: it reads sixty free sources across six families — news, river gauges, weather and sea state, natural hazards, government filings and reference rates — decides which of those bookings are affected, and produces three things for each one: a decision, the reasoning behind it, and the carrier and customer emails it implies. Each of those is expressed as a change to the booking record it came from and queued back into the TMS — the exception on the booking, the new discharge port and ETA, the drafted mail on its communication log. Nothing is sent and nothing is written until a person approves it. Beside that loop sits the everyday desk: agents that work every inbound mail — quotes, bookings, documents, milestones, invoices, customs — hand each other the work as recorded messages, check every output against the customer's standing instructions, and learn from each correction a person makes. The risk loop's decisions are handed to that desk to carry out. The whole system runs on open-weight models that can be hosted inside the European Union, so the shipment data never has to leave.

The problem this addresses

A mid-size forwarder's operations desk does two jobs badly, through no fault of its own. It watches for disruption, which means someone reading trade press between other work — one narrow slice of a signal that actually arrives from broadcasters, waterway authorities, weather services, seismic networks, government registers and central banks, in that many different formats. And it reacts to disruption, which means opening the booking system, checking which boxes are exposed, weighing the options, writing the same six emails it wrote last time, and then keying every one of those decisions back into the TMS booking by booking — because until that last step happens, nothing that was decided has actually happened.

Existing risk platforms do the first job and stop. They raise an alert and leave the desk exactly where it was — knowing something is wrong, with all the work still to do. They are also priced for enterprise shippers, not for a forwarder with a few hundred bookings in the water.

So there are two gaps, and the second is the expensive one. The first is that detection is narrower than the problem — a monitor reading headlines is reading a summary of some of the signal, late. The second is that detection is where every tool stops: the decision, the two emails and the write-back are left to a person, and the write-back is the part that eats the day.

How the loop works

Six stages, run in order, on demand. The numbering is real: each stage consumes the previous stage's output — and the first and last are the same system, because the agents work on the forwarder's records rather than on a book of their own.

Every stage records why it did what it did — the loop is auditable, not just automatic

The part that makes it a loop

Risk platforms stop at stage 01. The TMS and the execution stack own stages 00 and 05 and assume someone already decided the middle. Welding the two together — reading the book out of the system of record, deciding, writing down the reasoning, and putting the result back on the same record — is the whole idea. The agents do not run beside the TMS; they run on it. A shipment rerouted on Tuesday is on the new route on Wednesday, and is no longer exposed to the thing that moved it. A shipment that is held accrues a day of delay for every day it waits, and carries that delay when it resumes. Holding is not free, and the system says so.

What is real, and what is staged

This is a prototype. Being precise about which half is which is what makes the demonstrable half worth anything.

Where the model decides, and where it must not

The most common way an AI logistics tool loses trust is by letting a language model do arithmetic. SQRlane splits the work along a hard line.

Code computes the facts. Which chokepoints a route passes through. Which of them carry active risk. How many days an alternative adds. Whether that fits inside the schedule slack. What the revised arrival date is. What each option costs — the premium for taking it, plus what the days it lands late are worth to that customer. All ordinary, testable code. Dates and sums never go near a model.

The model makes the call and explains it. Given those facts, is the right answer to move the box, hold it, or leave it alone — and why, in language an operations lead would accept.

Pricing the options is the sharpest case of the line. A rate is what an option costs to take; it is not what the decision costs, and ranking routings by days answers only which one lands soonest. So the advisor sums a premium, a per-day cost of being late and a one-off cost of missing the date at all, then refuses any alternate that does not beat staying put in money. Every term is arithmetic and no probability is applied anywhere — the moment a model is asked how likely a cold chain is to break, the number it returns is invented, and an invented number is worse than none. The commercial terms are authored on each booking, like the bookings themselves: the arithmetic is exact, its inputs are synthetic, and nothing here is measured.

This split has a useful side effect: a booking whose route carries no active risk never reaches the model at all. That is a genuine answer, not a shortcut, and it keeps a meaningful share of the board deterministic.

Guard rails around the model's answer

• If the model proposes a route it was never offered, the reroute is refused and downgraded to a hold.
• If it returns a decision value that isn't one of the three allowed, the result falls back to no-action.
• If the provider fails entirely, transparent rules decide instead and every affected card is badged as rule-decided.
• Each of those interventions is written into the shipment's reasoning record, so a refused answer is visible rather than silently swallowed.

The model layer

Six jobs with genuinely different requirements — and most of the sixteen agents need no model at all. Sizing each job separately, and not calling a model where code gives the same answer every time, is where nearly all the cost and latency savings live.

Sixteen agents, and which of them need a model

The agents are named for the job a forwarding desk already has, in two layers: the risk layer, which runs when a lane moves, and the everyday desk, which runs on every inbound mail. Five of the sixteen call a model in this build, and two more would with work this build does not do yet: reading scanned documents, and turning a customer’s written instructions into rules. The rest are code — prices, weights, dates, rule checks and field values are computed, never generated — and code is both the cheapest and the most repeatable model there is.

That split is the recommendation in one line: a capable mid-size model where the answer is a label that sends work somewhere, a large mixture-of-experts model where the answer is a judgement someone will challenge or a source that must not be missed, a strong writer where tone is the deliverable, a vision model where the input is a picture, and no model at all where the answer must be exact — a price, a weight, a rule check, a write to the record. Qwen3-235B-A22B earns the judgement slot because only about 22 billion of its parameters work on each token, which puts a large model’s reasoning at close to a small one’s price. Every agent also records the reason for each message it posts — the cues that classified a mail, the customer rule behind a send-back, the slack arithmetic behind an escalation — and for the agents that use no model, that reason is the computation itself.

What that costs, measured rather than assumed

A cycle under the Hamburg scenario makes fourteen calls — five to screen headlines, three decisions, six drafts. Measuring the actual prompts and outputs gives roughly 12,800 input tokens and 3,700 output tokens per cycle, at the usual four-characters-per-token approximation.

The everyday desk adds one call per inbox run: about 950 input tokens for the thirteen-mail morning, measured from the prompt, and an estimated 350 out — roughly $0.0002 at the screening price, and a little more as a person’s corrections are added to the prompt as context.

The stronger picks in the agent table change one stage of the cycle: screening runs on Qwen3-235B-A22B instead of Qwen3.5-9B. Pricing every token of the cycle at that model’s rate gives an upper bound of $0.0048 a cycle — about $17 a year at ten cycles a day, $87 at fifty — still about seven times under the frontier figure. Gemma-3-27B and Qwen2.5-VL-72B are not priced in the catalogue extract used here; the vision model would be paid per document, not per cycle.

Sizing each stage separately is about ten times cheaper than reaching for a frontier model everywhere, for output a desk would not be able to tell apart on the two stages that do not need it. That ratio, not the absolute figure, is the point: inference is not the cost centre here, but carelessness with it is the easiest avoidable one.

Running it in Europe

Shipment data is commercially sensitive: lanes, volumes, customers, rates. The architecture is designed so none of it has to leave the EU.

Every model in the table above is open-weight, which means it can be served from infrastructure you choose rather than reached through a vendor's own cloud. That is the sovereignty argument in full — not a policy promise about where data is processed, but an arrangement in which the question does not arise.

Lyceum Inference Studio, run from Berlin, serves a catalogue of open-weight models from eu-north1 on a pay-per-token basis, with no commitment. Three properties of it matter here more than the price does.

Why per-token beats renting a GPU here

It is worth being explicit, because the alternative looks cheaper on a spreadsheet. A dedicated GPU is priced by the hour whether or not anything is running. This system makes roughly fourteen calls when a disruption lands and then nothing for hours. At ten cycles a day the recommended model mix costs about twelve dollars a year; a single rented GPU left running would cost more than that before lunch on the first day. Reserved capacity starts to make sense when the desk is large enough to keep the endpoint genuinely busy, or when a fixed latency SLA is worth paying for — and dedicated endpoints exist for that case.

Built in Europe, for Europe

That phrase is doing a lot of marketing work across the sector at the moment, so it is worth being exact about what it means here and what it does not.

Two different claims, often blurred together

There are two separate axes here and the marketing usually collapses them. Residency is where your data is processed. Provenance is where the model weights came from. They are not the same thing, and only one of them is settled by choosing an EU host.

For most forwarders the residency axis is the one that matters, because the risk they are managing is commercial confidentiality rather than model lineage. If a procurement process demands European weights as well, that is available — at some cost in capability on the harder reasoning stage.

What is genuinely European here

• The problem is. The lanes, chokepoints and regulations modelled are the North Range ports, the Rhine, the Mediterranean corridors and EU customs entry — not a global abstraction with European labels applied.
• The processing can be. EU-hosted inference with zero retention, from a European provider.
• The data need never leave. Because the models are open-weight, they are served where you choose. That is a property of the architecture, not a clause in a contract.
• It suits the regulatory direction. Recorded reasoning for every decision, and a human approval gate before anything leaves the building, are exactly the properties an EU AI Act conversation asks about.

Assumptions, and how this breaks

Every item below is a real failure that occurred during development, not a hypothetical risk register.

The pattern worth taking away

Every one of those was found by looking at real output, not by reasoning about the code. The rate limit in particular survived three rounds of confident wrong diagnosis until the fallback was made to state its own reason on screen. A system that degrades silently is worse than one that fails loudly, because you will demonstrate it in that state without knowing.

What this is not

Scope discipline is what kept this buildable. None of the following are in it, and none are accidental omissions.

• Not route optimisation. Candidate routes are pre-defined. The system chooses among them and justifies the choice; it does not compute new ones.
• Not a sending system. Emails, booking amendments, customs entries and TMS write-backs are all drafted and held. There is no transport layer in the codebase, and a test fails the build if one is ever imported.
• Not connected to a real TMS. Working through the TMS is the design and both directions are modelled — the read is the only door to the book, and every agent action is expressed as a change to a booking record. What is absent is the far end: no vendor, no credential, no endpoint. It contacts nothing.
• Not self-training. The everyday desk learns from corrections, but a lesson is a rule and a line of context a person can read and delete. No weights change, and a lesson that would undo an earlier correction is refused.
• Not always-on. It runs on demand. For a demonstration, a button beats a background job.
• Not measured. There are no accuracy figures, hit rates or time-saved claims anywhere in this document, because none have been measured. Inventing them is the fastest way to lose a room that knows the domain.

What production would require

The distance between this prototype and a product is not mostly model work. It is integration, trust and liability.

• A real TMS connection. The shape is already here — one read path and a write-back per agent action — so the work is the far end of it: a vendor's API, credentials, field mapping against their schema, and the reconciliation that follows when the two systems disagree. Replacing the synthetic pool with a live book is the single highest-value next step, and everything downstream of it already assumes it.
• Inference moved in-region. Deploy the model classes above on EU capacity and benchmark them, replacing the illustrative costs here with measured ones.
• Evaluation the domain would accept. A held-out set of historical disruptions, scored on whether the decision matches what the desk actually did — the only credible answer to “how good is it”.
• Sending, deliberately and last. The approval gate exists because trust is earned in that order. Drafting well for months is the argument for eventually being allowed to send.