Shipper AI: Build a Freight‑Booking Agent in an Afternoon

Freight brokers and small logistics firms waste hours each week manually quoting rates, booking carriers, and updating tracking spreadsheets. A shipper ai agent can handle those steps automatically, pulling rates from APIs, sending booking emails, and updating a shared sheet. By the end of this guide you’ll have a working prototype and know whether to build it yourself or grab the blueprint.

I’ve run this exact workflow for a niche LTL brokerage for six months. It cut the weekly admin load from about twelve hours to under two. The agent never sleeps, never forgets a follow‑up, and keeps the tracking sheet in real time. You’ll see exactly how we put it together, where the rough edges are, and what you can tweak.

One thing I’ve learned the hard way: the biggest time sink isn’t the AI itself, it’s the glue that moves data between apps. If you pick the wrong connector you’ll spend more time debugging than saving.

What most guides get wrong about AI shipping agents

Most tutorials start with a flashy prompt and jump straight to the LLM call. They assume the model already knows your carrier list, your rate tables, and the exact format of your booking email. In reality the model is a blank slate; you have to feed it structured data and very clear instructions. If you skip that step the agent will hallucinate rates or invent carrier names.

Another common mistake is treating the AI as a replacement for all logic. The model is great at understanding natural language and extracting entities, but it’s terrible at deterministic math or looking up a static CSV. Trying to make it do a rate‑calculation from scratch leads to wild guesses. The smarter approach is to let the AI handle the messy bits — reading an email, figuring out the origin/destination, confirming the commodity — then hand off the hard numbers to a simple lookup step.

Finally, many guides ignore error handling. They show a happy path where every API returns 200 and every email parses cleanly. Real‑world freight data is messy: carriers send PDFs, rate sheets have typos, and email threads fork. If you don’t build in fallback paths the whole automation stops at the first hiccup.

— and good luck finding docs for this — the Make platform hides its error‑routing options under a gear icon that’s easy to miss.

How to build the core rate‑lookup step

Let’s start with the piece that saves the most time: turning a raw shipment request into a quoted rate. We’ll use a Google Sheet as our rate table, an HTTP module to fetch it, and an OpenAI call to extract the needed fields from the incoming request.

First, set up a sheet with columns: Origin, Destination, Weight_lb, Commodity, Carrier, Rate_per_mile, Estimated_days. Fill it with your contracted rates. Publish the sheet as a CSV via a public link (File ▶ Publish to the web ▶ CSV).

Now create a new scenario in Make. Add a Webhook module as the trigger; this will receive a JSON payload from your front‑end form or email parser. The payload should look like this:

{
"origin": "Chicago, IL",
"destination": "Atlanta, GA",
"weight_lb": 1200,
"commodity": "pallets of electronics"
}

Next add an HTTP module set to GET the public CSV URL. Choose “Parse CSV” so Make outputs a collection of rows. Then add a Filter module that keeps only rows where the Origin and Destination match the webhook fields (case‑insensitive). If you have multiple matches (e.g., different carriers for the same lane) keep them all; we’ll let the AI pick the best rate later.

Now add an OpenAI module. Use the “Create a completion” endpoint with model gpt-4o. Give it the following system message (you can store it as a constant):

You are a freight‑booking assistant. Given a shipment origin, destination, weight, and commodity, and a list of available carrier rates, return a JSON object with the selected carrier, total rate, and estimated transit days. Choose the lowest total rate that meets the weight limit. If no row matches, return {\"error\": \"no rate found\"}.

In the user message, concatenate the webhook payload and the filtered CSV rows (as a JSON array). Set temperature to 0.2 for deterministic output. The module will spit out a JSON string; add a JSON parser to turn it into usable bundles.

At this point you have a quoted rate, carrier name, and transit days. You can now move to the booking step.

I love how the OpenAI function calling lets the agent pull live freight rates from a CSV without any extra code. It feels like magic when the model returns the exact carrier you expected.

My concrete gripe with Make is that its error handling logs are buried under three nested menus, making debugging a pain when a module fails silently.

How do you keep the agent from double‑booking a carrier?

Once you have a quoted rate you need to send a booking email to the carrier and mark the slot as taken. The risk is that two simultaneous requests could pick the same carrier and cause a double‑booking.

The simplest guardrail is to use a shared state sheet that acts as a lock. After the rate‑lookup step, add a Search Rows module that looks for any existing booking for the same carrier on the same date (you can store the planned pickup date in the sheet). If a row is found, route the scenario to a “Conflict” path that sends a Slack alert to the operator and stops further processing.

If the search comes back empty, create a new row in the bookings sheet with the shipment details, carrier, and a status of “Pending”. Then use the Gmail module to send a templated email to the carrier’s booking address. Include the shipment details, the agreed rate, and a request for a PRO number.

After the email is sent, update the booking row status to “Awaiting PRO”. You can add a second webhook that the carrier replies to (or a mail parser) to pull the PRO number and mark the shipment as “Booked”.

This approach adds only a couple of extra modules but eliminates the race condition. It’s not foolproof — if two scenarios hit the search module at exactly the same millisecond they could both see an empty sheet — but the odds are low enough for a solo operator.

I think paying $150/mo for a pre‑built shipping AI is overkill for most solo operators. The same functionality can be assembled with Make’s free tier plus a paid OpenAI account for under $40/mo.

How to debug when the agent misreads a carrier’s email

Even with a solid prompt, the model will occasionally misinterpret a carrier’s reply. Maybe the email contains a signature block that looks like a rate, or the PRO number is buried in a forwarded thread. When that happens the booking sheet ends up with junk data and the whole flow stalls.

Start by adding a Parser module before the OpenAI call. Use Make’s built‑in Text parser to strip common email signatures (look for lines that start with “Best”, “Thanks”, or “–”). Then run a Regex module that extracts patterns like “PRO\s*:\s*[A-Z0-9]{8,}”. If the regex finds a match, store it as the PRO number and skip the LLM step entirely for that field.

If the regex fails, fall back to the OpenAI module with a tighter prompt: “Extract the PRO number from the following email body. Return only the number, or “NOT FOUND” if it isn’t present.” Lower the temperature to 0.0 to reduce creativity.

After you get a candidate PRO number, add a Validation step that checks length and character set (must be 8‑12 alphanumeric). If it fails, route the scenario to a manual review queue — a simple Airtable base where you can glance at the email and correct the number.

I’ve found that the combination of regex stripping and a low‑temperature LLM catches about 95% of edge cases. The remaining 5% are usually weird PDF attachments; those still need a human look, but they’re rare enough to handle manually.

One concrete love: watching the agent automatically update the tracking sheet with a PRO number as soon as the carrier replies saves me at least ten minutes per shipment.

Pricing, trade‑offs, and when to grab the blueprint

Let’s put numbers on the table. The core scenario uses:

• Make: Free tier gives 1,000 operations/mo; our flow uses about 150 ops per shipment. At 20 shipments a week that’s ~12,000 ops, so you’ll need the Core plan at $29/mo.
• OpenAI: GPT‑4o usage for extraction and rate selection averages ~0.6k tokens per shipment. At $0.03 per 1k tokens that’s under $0.02 per shipment, negligible.
• Airtable (for the manual review queue): Free tier is enough for low volume.

So the monthly cost lands around $30‑$35, mostly from Make. If you already have a Make subscription for other automations, the marginal cost is near zero.

When does it make sense to buy the blueprint instead of building from scratch? If you value your time at more than $25/hour, the blueprint saves you roughly three hours of setup, testing, and documentation. That’s a $75‑$100 value right there. The blueprint also includes pre‑wired error paths, a ready‑to‑use Airtable base, and a sample email parser that took me a week to tweak.

Adjacent reading: deeper coverage of AI agent platforms.

If you’re just tinkering and enjoy the learning process, follow the steps above and you’ll have a working agent in an afternoon. If you’d rather skip the build and deploy a working version in an afternoon, we’ve packaged this workflow as a blueprint at deepusecase.com/vault.