What Should a Freight Broker Ask Before an AI Writes to the TMS?
By Connor Miller, Founder and CEO, FreightScout. Last updated 2 November 2026.
Short answer: before any AI touches a load in your TMS, get five things in writing. Exactly which fields it writes. Who has to say yes before it writes them. Where the record of every action lives. How you undo one action, or switch the whole thing off, without breaking the rest. And how it connects when your TMS doesn't offer an API. If a vendor can't answer those on a real load in your own TMS, it isn't ready to write to your book.
Why does write-back change the buying decision?
Because reading your TMS and writing to it are two different levels of trust.
A tool that only reads your loads can be wrong and the worst case is a bad suggestion your rep ignores. A tool that writes to your loads can be wrong and the worst case is a wrong carrier on a load, a wrong rate on a rate con, or a status note that tells your customer the truck's on time when it isn't. Your billing, your customer updates and your carrier payables all run off what's on that load.
On a floor, the TMS is the one place everybody agrees is the truth. Ops reads it at 6 a.m. Billing closes off it. The owner pulls margin off it. Anything that writes there is writing into everybody's day.
That's also why write-back is worth having. If the AI does the work and the result never lands on the load, somebody re-keys it, and you've bought a second screen. So the goal isn't to avoid write-back. It's to know exactly what's being written, by whom, with whose yes.
What should you ask about what it writes?
1. "Which fields do you write, on which screen?" Don't accept "it syncs with your TMS." Ask for the list. The booked carrier? The agreed rate? The load itself, with stops and references? The check call note? Each one is a different risk. A check call note that's off is an annoyance. A rate that's off is money.
2. "Do you create records, change records, or both?" Building a new load from a tender is one thing. Changing the carrier or the rate on a load that's already booked is another. You want to know which the tool does and whether you can allow one without the other.
3. "Show me the load in my TMS after it ran." Not the vendor's dashboard. Your McLeod, Aljex or Tai screen, on a test load or a real one. If the booked carrier and the rate aren't sitting on the load where your team already looks, it didn't really write back.
4. "What happens when the data on the load is wrong to begin with?" Every book has old lanes, missing references and a carrier with two MCs on file. Ask what the tool does when what it reads doesn't add up. You want to hear that it stops and asks a person, not that it picks something and keeps going.
What should you ask about who says yes?
5. "What runs without a person on day one?" The right answer for most brokerages is: nothing that commits money or talks to a customer. Start with everything on approve. The tool drafts and stages, your people say yes, and you turn things up as you watch it work.
6. "Can I set that per team and per action?" Your night desk might be ready for check calls on their own long before your carrier sales team wants booking on autopilot. If the only setting is on or off for the whole company, you'll either never turn it on or turn it on too early.
7. "Where's the ceiling on money?" If the tool negotiates with carriers, ask what stops it from going over your max pay. There should be a hard number you set, and the tool should never go above it on its own.
8. "What happens to a carrier that doesn't clear vetting?" Ask whether vetting runs before a rate is ever discussed, and what happens when a carrier fails it. You want the carrier held, and releasing it to take a named person, on record.
What should you ask about the record and the undo?
9. "Where's the log, and who can read it?" Every action the tool takes on a load should be written down: what it did, when, on which load, and who approved it. When a customer or a carrier disputes something three weeks later, that log is your answer. If the log lives only inside the vendor's support team, it isn't yours.
10. "How do I reverse one action?" Not the whole system. One wrong carrier on one load. Ask them to show you.
11. "Can I switch off one job without breaking the others?" If check calls go sideways on a Monday, you should be able to turn off check calls and keep load building running. A tool where everything is tangled together is a tool you'll be scared to turn on.
12. "Where does my data go, and does it train anybody else's model?" Your lanes, rates, carriers and margins are the brokerage. Ask whether that data stays scoped to you, whether it's pooled with other customers to build a shared model or rate product, and how connected mailbox logins are stored.
What should you ask about how it connects?
13. "Do you connect by API, and what if my TMS doesn't have one?" Plenty of TMSs offer an API. Plenty of brokerages run on one that doesn't, or on a version where the API doesn't cover the screen that matters. Ask what the tool does in each case, and whether the answer means you're paying for a custom build.
14. "Who sets it up, and what do you need from my IT person?" Ask how long setup takes on your TMS, what access it needs, and whether anything changes for the reps who log in every day. The answer you want is that your team keeps working in the same TMS they already use.
15. "Do I have to move off my TMS?" If the honest answer is yes, you're not buying an AI layer. You're buying a TMS migration, with everything that comes with one. That can be the right call, but it's a different decision and it should be priced like one.
What does a good answer sound like?
Here's how the answers line up when you put them next to each other.
| Question | Answer that should worry you | Answer you want |
|---|---|---|
| What do you write? | "We sync with your TMS." | A named list of fields, shown on a real load in your TMS |
| Who says yes? | "It's fully autonomous." | Supervised by default, turned up per team and per action |
| What about money? | "It finds the best rate." | A max pay you set, and it never goes above it |
| Where's the record? | "Our support team can pull that." | Every action logged, on the load, where you can see it |
| How do I undo it? | "That shouldn't happen." | One action reversed, or one job switched off, on the spot |
| What if my TMS lacks an API? | "We'll scope a custom project." | A plan for both cases, set up during implementation |
| Do I switch TMS? | "Our platform replaces it." | No. Your TMS stays the system of record |
How does FreightScout answer these?
Here's what we say on freightscout.ai, so you can hold us to it.
- What it writes. FreightScout builds loads from email, PDF and EDI tenders, and writes the booked carrier and the agreed rate back into your TMS. Check call notes land on the load. Write-back is live on McLeod, Aljex and Tai.
- How it connects. By API where the TMS offers one, and by reading it in place where it doesn't, set up during implementation.
- Who says yes. It runs supervised by default, and you can switch to autopilot per team and per action. Booking the carrier and shipper outreach stay supervised by default until you change them.
- Money. It negotiates up to the max pay you set and never above it.
- Vetting. FMCSA authority, insurance and identity are checked before a rate is discussed. A carrier that doesn't clear is held, and releasing it takes a person, on record.
- The record and the undo. Every action is logged and reversible. You can turn any of it off instantly without breaking the rest.
- Your data. Your load, lane, rate, carrier, margin and contact data isn't used to train generalized models and isn't pooled with any other customer's data. Connected mailbox tokens are encrypted at rest. The detail is on our security page.
- Your TMS. FreightScout isn't a TMS and isn't a load board. The TMS stays the system of record, and there's no migration project.
If you want to see it on your own book, ask us the fifteen questions above on the demo. That's what they're for.
Questions brokers ask
Is it safe to let AI write to my TMS?
It's as safe as the controls around it. Look for named fields, a person's yes before anything that commits money, a log of every action, and a way to reverse one action or switch off one job. Without those, keep it read-only.
What should an AI tool write back to the load?
At minimum, the result of the work it did: the booked carrier and the agreed rate if it covered the load, the load itself if it built it from a tender, and the check call note if it made the call. If the result isn't on the load, somebody re-keys it.
What if my TMS doesn't have an API?
Ask the vendor directly. FreightScout connects by API where the TMS offers one, and by reading it in place where it doesn't, set up during implementation.
Should AI book carriers without a person approving?
Not on day one. Start supervised, watch it on real loads, and turn it up per team and per action when you trust it. FreightScout keeps booking the carrier supervised by default.
How do I undo something the AI did on a load?
Ask to see it before you buy. With FreightScout, every action is logged and reversible, and you can turn any job off without breaking the rest.
Do I have to switch TMSs to use AI?
No. An AI layer should work on the TMS you already run. FreightScout isn't a TMS, and your TMS stays the system of record.
What should I ask on a freight AI demo?
Ask to see your own TMS after it ran, not the vendor's screen. Then ask the questions on this page. There's more on telling real work from suggestions in how to tell if freight AI does the work.
Related
- integrations
- autonomy and trust
- security
- carrier booking
- check calls
- load building
- how to tell if freight AI does the work