How does this work when we only have a handful of carriers?

The engine is lane-aware, not carrier-count-aware. Even with two or three carriers, per-lane scoring surfaces meaningful allocation improvements because no carrier is the best everywhere.

Does the engine require us to share our rate cards with Shipsy?

Rate cards live encrypted in Shipsy's [multi-carrier module](/multi-carrier-management) and are used only for your allocation decisions. They are never shared with other shippers or used for cross-customer training.

How quickly does the performance model learn a new carrier?

The model uses Bayesian priors from similar-profile carriers, so a brand-new carrier is never stuck on zero data. Per-lane performance stabilizes inside the first couple of months of regular volume.

Can we override allocation decisions?

Yes. Operators can pin shipments to specific carriers, blacklist carriers on specific lanes, and enforce regulatory or commercial constraints. The engine honours overrides and continues scoring around them.

Where does allocation fit alongside the rest of Shipsy?

Allocation runs inside [Atlas](/insights/atlas-autonomous-control-tower-system-of-action) and is one of Astra's responsibilities in AgentFleet. See [Shipsy for retail](/industries/retail) for vertical-specific deployment patterns. --- **Request a walkthrough** on your own carrier mix.

Multi-carrier allocation: the AI decision engine behind every shipment assignment

When a retailer or marketplace has five 3PLs to choose from per shipment, the default behaviour is a rules engine written in 2018 that picks the cheapest carrier by postal code. Shipsy’s multi-carrier allocation replaces that with a live AI scoring function — SLA, cost, capacity, and carrier performance history — and re-decides in real time when a carrier misses the promise window.

This post is for retail and CEP operators who have already deployed multi-carrier but are still leaving margin on the table at allocation time.

Why we built this

Multi-carrier started as a procurement move. Shippers wanted leverage, redundancy, and tactical pricing. But the decision of which carrier gets which shipment has stayed embarrassingly crude: static rules, periodic RFP cycles, and spreadsheets. The cost of that is hidden in three places — carriers with poor track records keep earning shipments, cheaper carriers with tight capacity get overbooked and miss SLAs, and there is no way to respond intra-day when a carrier’s actual performance diverges from their contract.

Shipsy’s AI allocation engine treats every shipment as a live decision, every carrier as a live scorecard, and every outcome as training data.

How it works

The allocation engine is Astra’s allocation module inside AgentFleet, running inside Atlas. It runs four inputs into a single scoring function per shipment.

1. SLA fit

Does the carrier’s actual (not promised) transit time for this origin-destination-service-level combination meet the shipment’s required delivery date? Shipsy maintains a rolling performance window per carrier per lane — the numbers the carrier sells on and the numbers they actually deliver on are usually different, and the engine uses the latter.

2. Cost

Landed cost after all accessorials, fuel surcharges, dimensional weight, and zone adders — computed from the rate-card parsing Nexa already does. Not the headline rate on the RFP sheet.

3. Capacity

Real-time capacity signals from carrier EDI, booking APIs, and Shipsy’s own network data. A cheap carrier with no slots is not actually cheap. The engine degrades a carrier’s score when their capacity signal is constrained.

4. Performance history

Per-carrier, per-lane, per-service-level track record. First-attempt delivery rate, on-time percentage, damage ratio, customer-complaint rate, invoice-dispute rate. These are heavy inputs because they are the honest counterweight to the contracted rate.

The four inputs combine in a weighted score, with weights tunable per shipper, per SKU category, and per SLA tier. A same-day electronics shipment weights SLA and performance higher; a B2B pallet weights cost and capacity higher. The winning carrier gets the shipment, and the decision is logged for audit.

Real-time failover

When a carrier’s live capacity tightens or their intra-day performance degrades (scans not firing, hub delays, cancellations), the engine re-scores pending shipments and reassigns them before they hit the carrier’s facility. This is the difference between a daily allocation batch and a running decision loop.

Here’s the decision flow at a glance:

flowchart TD A[Incoming order] --> B[Score candidate carriers] B --> C[SLA fit] B --> D[Landed cost] B --> E[Live capacity] B --> F[Performance history] C --> G{Weighted score} D --> G E --> G F --> G G --> H[Allocate to top carrier] H --> I{Intra-day drift?} I -->|Yes| B I -->|No| J[Dispatch]

Early results

Retail customers on Shipsy’s multi-carrier stack typically see first-attempt delivery rates improve materially on problematic lanes after the allocation engine goes live. Aramex unlocked $27M in cross-border throughput partly on the back of smarter allocation decisions — cheaper lanes identified, weaker carriers deprioritized, constrained capacity redirected. IKEA runs 95% FADR on big & bulky with Shipsy, with allocation decisions routed through the same engine. CEP operators reshaping their carrier mix mid-peak using Shipsy’s engine consistently describe it as the single biggest unlock of the peak season.

The counter-intuitive finding: the cheapest carrier on paper almost never wins the most volume, because real cost is rarely what the contract said.

What’s next

The next step is carrier-facing price discovery — allowing carriers to bid on shipments in real time through a Shipsy market, with the allocation engine incorporating live bids alongside static rate cards. The design partner rollout is already underway; expect spot-rate inefficiency to compress materially for high-volume shippers once it lands broadly.