AI Agents
AI agents for air cargo booking: quoting, e-AWB, and the ONE Record shift
Air freight still runs on rate emails, spreadsheets, and a legacy EDI standard IATA started retiring in January 2026. Here's where an agent quotes, books, and documents a shipment across carriers and GSAs, what stays with the carrier's capacity system and CASS, and why ONE Record is the data model that finally makes an agent viable.
A forwarder gets a shipment to quote: 400 kilos, Chicago to Frankfurt, needs to move this week. Getting a price is not one lookup. It’s a rate sheet from one carrier, an email to a general sales agent for another, a check on which airline has belly capacity, and a note about which contract rate applies.
Twenty minutes, sometimes an hour, for a number a competitor might return in two.
That gap is why air cargo is one of the most talked-about targets for AI agents in 2026. Most of those conversations skip the part that decides whether an agent works at all: the data. So let me state the shape up front.
An agent can assemble a multi-carrier quote, place a booking, and generate the documents in the time it takes to read the request. What it can’t own is the capacity, the settlement, or the acceptance of a dangerous-goods shipment. Those stay with the carrier’s systems and a human.
This is the freight desk, not the passenger cabin. Selling a seat through NDC offers and orders is a different agent on a different standard, and neither is the same as coordinating a shipper’s end-to-end supply chain. Air cargo booking is its own process, with its own documents and its own settlement system.
Why quoting a shipment is a multi-system problem
A forwarder rarely sells one airline’s capacity. They hold rate agreements and allocations with several carriers, and they work through general sales agents who represent airlines that have no direct sales presence in a given market. So the “best” answer to a quote is a combination: the right carrier, at the right contract rate, with capacity on the days the shipment can move.
Each of those inputs lives somewhere different. The rate agreements are contracts. The allocations are entitlements the forwarder negotiated. The live capacity belongs to the carrier. Pull the wrong combination and you’ve either quoted a rate you can’t honor or missed the capacity that would have won the booking.
The forwarder’s edge is knowing which of six carriers to quote, at which rate, with space on the right day. That’s a reasoning-over-many-sources problem, which is exactly the shape an agent is good at, and exactly the shape a rate spreadsheet is bad at.
Then the documents start. A booking becomes a master air waybill for the carrier and, when the forwarder consolidates, house air waybills for the underlying shippers.
The waybill has to be filed electronically, customs data has to go where the destination requires, and the shipment has to be tracked from acceptance to delivery. Every step is a data hand-off, and every hand-off is where the old way leaks time.
The standard shift that makes an agent viable
Here is the change most agent pitches gloss over. For decades the messages behind all of this ran on Cargo-IMP, a fixed-format EDI standard introduced in 1975, and later Cargo-XML from 2010. Both are message standards: you send a booking message, a waybill message, a status message, each in a rigid format. They work, and they are also exactly the kind of brittle, point-to-point plumbing that makes automation expensive.
In 2026 that starts to change. IATA made ONE Record its preferred standard for air cargo data sharing as of 1 January 2026, and on the same date Cargo-IMP and Cargo-XML entered containment, meaning no further development. Preferred is not mandatory, and the older standards will run for years yet, so the practical reality through this transition is a mixed estate. But the direction is set.
ONE Record is a different idea from a message standard. Instead of sending documents back and forth, every party reads and writes a single shared shipment record through a standard RESTful API, over a linked-data model expressed in JSON-LD, with a security layer that controls who can see and change what. One source of truth per shipment, queried and updated in place.
For an agent, that distinction is the whole story. A shared, queryable, JSON-based record with a REST API is something an agent can reason over and act on directly. A stream of fixed-format EDI messages is not, at least not without a translation layer for every partner. ONE Record is what turns “call the carrier’s API” from a bespoke integration project into something closer to reading and writing a record.
The e-AWB rides on top of this. The electronic air waybill is the legal electronic contract of carriage that replaces the paper waybill, and it already covers more than two out of three shipments. Whichever standard carries it, an agent that can produce and file a correct e-AWB removes one of the most repetitive documentation steps in the process.
What the agent actually does
Salesforce has no native air-cargo product, so treat this as an architecture over the forwarder’s own systems, not a feature you enable. The carrier’s capacity and the settlement system stay where they are. The agent is the reasoning, quoting, and coordination layer in front of the forwarder’s CRM and operational stack.
Quoting is the first and clearest win. The agent takes the request in natural language, reads the forwarder’s rate agreements and allocations, checks capacity through carrier and marketplace APIs, and returns a ranked set of options with the reasoning attached: this carrier at this rate with space on Thursday, that one cheaper but tight on capacity.
Grounding this well means the agent reasons over the real rate sheets and contracts. That’s where ingesting unstructured rate documents into a governed data layer earns its place, so the agent quotes from the contract, not a stale copy of it.
Booking is the next step, behind confirmation. Once a human or the customer accepts a quote, the agent places the booking against the chosen carrier, generates the master and house waybills, and files the e-AWB.
Reaching the carrier and marketplace systems is a governed-integration job. Calling external REST APIs from the agent through a declarative action layer is how the booking and waybill calls happen without a bespoke connector for each carrier.
Tracking and reconciliation close the loop. The agent watches the shipment status and flags exceptions, a missed connection or a customs hold, to the right person before the customer asks.
On the finance side it can reconcile charges against the carrier invoice, catching where a billed rate doesn’t match the agreed one, the kind of charge audit forwarders do by hand today. That reconciliation sits alongside the payments and settlement flows already running through the business.
What stays with the carrier and the human
Three things do not move to the agent, and pretending they do is how a demo becomes an incident.
Capacity belongs to the carrier. The agent quotes against capacity and books into it, but the airline’s system owns the inventory and confirms the booking. An agent that “promises” space the carrier hasn’t confirmed is quoting fiction.
Settlement stays in CASS. The IATA Cargo Accounts Settlement System is how airlines and forwarders bill and settle: a consolidated invoice across participating carriers, one payment through CASSLink. The agent can reconcile charges against it and flag discrepancies, but the settlement mechanism itself is neutral infrastructure the agent reports on, not one it replaces.
Dangerous goods stay human. A shipment of lithium batteries or hazardous chemicals is governed by the IATA Dangerous Goods Regulations, and acceptance is a trained, accountable decision with legal weight. An agent can check declarations, flag a probable DG classification, and prepare paperwork, but it does not accept a dangerous-goods shipment. That signature belongs to a qualified person.
Where it breaks
The mixed-standard estate is the first hurdle. Through this transition an agent will meet ONE Record at some partners and Cargo-IMP or Cargo-XML at others, so the integration layer has to speak both, and the clean shared-record experience is a destination, not today’s default.
Rate accuracy is the second. A quote is a commitment, and an agent that quotes from a stale rate or misreads a contract has cost the forwarder money, not saved it. The rates and allocations the agent reasons over have to be the current ones, grounded in the system of record, and the agent should show the rate’s source so a human can check it.
Hallucinated confidence is the third, and it’s the general one. Ask a model to produce a waybill field or a customs code from memory and it will oblige, sometimes wrongly. The documentation and classification steps need validation against authoritative reference data, not the model’s recall, for the same reason an agent project fails when it trusts fluent output over grounded facts.
What to build first
Start with quoting, because it’s the highest-frequency, highest-toil step and the lowest-risk one to automate. Give a forwarder an agent that turns a shipment request into a ranked, sourced multi-carrier quote in seconds, reading the real rate agreements and live capacity, with every rate showing where it came from. That alone changes the win rate on time-sensitive business, and the agent never books anything.
Add booking and e-AWB generation next, behind a confirmation step, once the quoting layer has proven its rates are right. Keep capacity confirmation with the carrier, keep settlement in CASS, and keep dangerous-goods acceptance with a qualified human. Build the integration to speak both ONE Record and the legacy standards, because for the next few years it has to.
Do that, and the agent becomes the thing a freight desk needs: not a system that runs the airline’s business, but one that returns the quote before the customer has finished reading their inbox, and files the paperwork without a person retyping it.
Understanding the basics
What is IATA ONE Record and why does it matter for AI in air cargo?
ONE Record is IATA’s data-sharing standard for air cargo, built around a single shared shipment record that every authorized party reads and writes through a standard RESTful API, over a JSON-LD linked-data model with a security layer. IATA made it the preferred standard as of 1 January 2026, the same date the older Cargo-IMP and Cargo-XML message standards entered containment. It matters for AI because a shared, queryable, JSON-based record is something an agent can reason over and act on directly, where fixed-format EDI messages need a translation layer for every partner.
Can an AI agent book air freight end to end?
It can do most of the sequence, but not all of it autonomously. An agent can assemble a multi-carrier quote from rate agreements and live capacity, place a booking after confirmation, generate master and house air waybills, file the e-AWB, and track the shipment. What it should not own is capacity confirmation, which belongs to the carrier’s system, settlement, which runs through IATA’s CASS, and acceptance of dangerous goods, which is a qualified human’s accountable decision.
How does Salesforce fit air cargo if there’s no cargo product?
As the reasoning, quoting, and coordination layer over the forwarder’s own systems. Agentforce runs the quoting dialogue and the exception handling, MuleSoft connects the carrier, marketplace, and ONE Record APIs, and Data 360 grounds the agent in the rate agreements, allocations, and contracts it quotes from. The carrier capacity systems and CASS settlement stay where they are; the agent coordinates and documents, it doesn’t replace the airline or the settlement rails.
What is an e-AWB and does an agent replace it?
The e-AWB is the electronic air waybill, the legal electronic contract of carriage between shipper and carrier that replaces the paper waybill, and it already covers more than two thirds of shipments. An agent doesn’t replace the e-AWB; it produces and files a correct one, removing one of the most repetitive documentation steps. The waybill is still the legal document, whether it travels over the legacy standards or a ONE Record API.
Building the quoting and documentation layer over your carrier, marketplace, and settlement systems, grounded in your real rate agreements and drawn so the agent coordinates without pretending to own the capacity or the settlement? Talk to us, getting the grounding right and the integration honest is exactly the work we do. Our Agentforce practice builds this kind of thing.
