Agents work the bookings already in your TMS — they work the inbox, watch the lane, decide, draft the mail, and put the change on the record.
Terminal handling, gate operations and rail shunting stop for the duration. Expected delay 3–5d.
Bookings it moves
Reroute via RTM
EUR 2,304
routing premium, nothing late
Stay on plan
EUR 31,500
1d past the required-by date
Dear Katrin Vogel,
An update on your automotive parts shipment HLCU-2261188: we are bringing it in through Rotterdam instead of Hamburg, which puts arrival at 2026-09-22 — 2 days later than planned.
There is industrial action at Hamburg that we expect to hold cargo there for several days. Routing through Rotterdam costs less time than waiting for it to clear.
That still sits inside your required-by date of 2026-09-24.
Lena Brandt · Head of Operations
Consol details
QUEUED — not written awaiting approval · nothing lands on the booking until you say so
Doing nothing
EUR 141,100
After the decisions
EUR 94,600
Exposure avoided
EUR 46,500
SHP-002 contributes nothing. It is held, and the hold is the least-bad option rather than a saving — the customer is in Hamburg and rerouting adds a cold-chain transfer.
Arithmetic from the run, over each booking's own authored terms: freight premium, cost per day past the required-by date, deadline breach and cold-chain transfer. Synthetic bookings, real reasoning — no estimate, no probability, and the figure moves with the scenario.
60 live sources across six families, no API keys
More shipments means more hires, so costs grow as fast as the business.
60%
Of the workday is coordination
~25
App switches a day
200+
Interactions for one shipment
<40%
Of forwarders run a forwarding system
Sources: Asana (2022), Maersk (2014), Magaya (2025).
Every delay costs more the longer it takes to decide.
The fee is not set by the decision. It is set by how long the decision takes.
Example: SHP-001 moved to Rotterdam the day the strike hit. Two days longer, inside its four days of spare time. synthetic booking
SQRlane drafts the customer email the moment it makes the call. A person sends it.
The fee is not set by the decision. It is set by how long the decision takes.
SHP-001 is a synthetic booking from the Hamburg scenario. See the four scenarios.
Read the world, decide against the booking, draft the mail, queue the change. Every step happens on the same record.
Sixty sources across six families, all read on every cycle.
The model weighs each booking's slack against the delay.
Carrier and customer mail, in the two voices they need.
Every decision is a change ready to write on the booking.
Nothing lands and nothing is sent until you sign off.
The TMS link is a demo connector. Nothing is ever written.
None of these is connected. SQRlane reads the booking through one demo connector and writes nothing — no vendor, no credential, no endpoint, and nothing is ever written. The marks are generic pictograms, not anyone's logo.
Every one of them is somewhere a decision gets typed again. That re-typing is the job SQRlane takes.
Forwarding platform
Logistics platform
Built to point at the system of record you already run. None of these is connected in this build: no vendor, no credential, no endpoint, and nothing is ever written.
Seven it should answer without one. If yours isn’t here, book one and ask it.
Risk platforms stop at the alert. Your TMS starts after the decision. Between them a person re-keys the consequences — a booking amendment, a discharge port change, a customer email — one booking at a time.
SQRlane closes that gap from both sides. The everyday desk works the inbox — quotes, bookings, documents, milestones, invoices, customs — and the risk layer reads the world, reasons against the booking, drafts the mail, and hands the consequences to the same desk. Same record at both ends, one gate on every write. How a decision is actually made.
The risk detection is real. On every run the terminal reads sixty free, keyless sources across six families — regional wires, river gauges, port weather and sea state, seismic and natural-hazard feeds, government filings and reference rates. The reasoning is a real model call against a real event.
The everyday desk is real too: its agents genuinely read, route and work every mail on every run, and check each result against the customer’s standing instructions. The mail they work is a synthetic morning, like the shipments.
Shipments are synthetic, so a disruption can be shown on demand instead of waiting for one. The TMS link is a demo connector: the near end is built, the far end is the integration work. Nothing is ever sent, and nothing is ever written. The full ledger of what is real here.
Not today. The connector is modelled end to end — the read path is the only door to the book, and every Worker’s action is queued as a change to the booking it came from — but no vendor is contacted, no credential is stored, and no endpoint is called.
The systems it is built to point at are named on the product page. Wiring a real one is the single highest-value piece of work on the far side of the integration wall.
No. Every outbound action — carrier mail, customer mail, booking amendment, queued field change — carries a DRAFT / QUEUED status until you approve it, one item or a selected batch at a time.
There is no email library, no SMTP and no TMS endpoint anywhere in the code for a rogue send or write to reach. A test fails the build if one appears. The gate, and what sits behind it.
Yes, and in a way you can check. A correction — a re-quote read as a booking, a document label it did not know — becomes a lesson the agents read on every later run. The whole inbox is replayed with it, and it is kept only if it fixes the mail it came from without undoing an earlier correction. You see every other mail it fixed.
No model is retrained. A lesson is a rule and a line of context you can read, date and delete. How the agents work together.
The prototype calls a US inference provider today. The whitepaper covers what shipping this on a per-token serverless provider in Europe would take — with the specific models and prices we would run against.
There is no customer data on this build. Shipments are synthetic and the reasoning trail is discarded with the run.
The prototype is not for sale. What’s worth showing is the shape of the workflow when reading, deciding, drafting and writing back are one loop — before pricing, before integrations, and before a pilot.
Book a call and we’ll walk through what a pilot would look like against your own book: which lanes, which TMS, and which Workers would ship live first.
Half an hour, your corridors, your disruption. Leave an address and we will come back to arrange it — or open the demo now and run the Hamburg strike yourself.
Placeholder. Not wired to anything — no form element here, and no transport anywhere in the app.
Rather not wait? Open the demo yourself → · Check what it can see →