How I Automated a Freight Brokerage End-to-End
And What I Learned Building It for Real
By Joe Entelisano · Fulton Street Labs
Moving a single truck typically takes 15–20 manual steps and ~90 minutes of active coordination. This means that a single freight broker or logistics manager can move a maximum of ~27 trucks in a 40 hour work week. This is a scalability ceiling, where moving more freight requires hiring more people.
Reading emails. Looking up rates. Calling carriers. Checking insurance. Generating PDFs. Updating spreadsheets. Following up. Repeating.
I built a system that reduces the broker’s job to four confirmations on Telegram — and automates everything else.
This post is about what it took to build something that actually works in production, why the early architectures failed, and why this problem is bigger than freight.
The real problem with freight brokerage
On paper, freight brokerage is simple: a customer needs a truck, a carrier has one, and a broker connects them.
In reality, brokers are buried under coordination work:
- Parsing unstructured emails
- Switching between fragmented systems – TMS, Excel, Load Boards, etc.
- Matching lanes to rates
- Calling dispatch offices
- Verifying insurance and authority
- Negotiating rates
- Generating and emailing paperwork
- Tracking state across inboxes and spreadsheets
None of this is hard judgment. It’s execution — and execution doesn’t scale.
What Halibut does today
Halibut is an automation engine built at Fulton Street Labs to run a real freight brokerage end-to-end. Here’s the full flow:
- 1A customer emails: “Need a truck Dallas → Chicago, 40k lbs, dry van.”
- 2The system parses the email, extracts structured data, and matches it to a rate.
- 3The broker gets a Telegram message with a one-line summary and replies “confirm.”
- 4The system creates the load, emails the customer, and searches for carriers.
- 5An AI voice agent calls carrier dispatch offices, negotiates rates, and collects info.
- 6Compliance is verified automatically.
- 7The broker replies “confirm” again.
- 8A rate confirmation PDF is generated and emailed to the carrier.
From customer email to tendered load — minutes, not hours.
The broker stays in the loop. The system does the work.
What the communication actually looks like
Automation isn’t useful unless it shows up where people already work.
In this system, every participant — broker, customer, and carrier — stays in their existing tools. There’s no new dashboard to learn, no portal to log into.
Here’s what the communication looks like in practice.
1. Broker Communication – Telegram
Broker approval via Telegram.
A new load request arrives with customer, route, rate, and margin. The broker replies “confirm” to proceed. The system handles everything else.
2. Customer communication — Email intake + confirmation
Once the broker confirms, the system takes over communication with the customer and carrier — automatically, but transparently.
Customer email, before and after automation.
The customer sends an unstructured request by email. Once the broker approves the quote, the system replies in the same thread confirming the load and rate.
3. Carrier communication — Rate confirmation email
The final step is tendering the load. Once a carrier is selected and approved, the system generates and sends the rate confirmation automatically.
Automated rate confirmation to the carrier.
Once approved, a rate confirmation PDF is generated and emailed directly to the carrier — no manual paperwork, no copy-paste.
The key insight: separate judgment from labor
Brokers don’t add value by copying data between systems.
They add value by answering questions like:
- Is this rate good?
- Is this carrier trustworthy?
- Does this load make sense?
Halibut isolates those decisions and presents them as simple confirm / reject prompts, while automating everything in between.
That design choice shapes the entire architecture.
Three architectures. Two failures. One that works.
I didn’t get it right the first time.
LangChain agents
Great demos. Unreliable execution. Non-deterministic behavior. Broke under real volume.
Central orchestrator
Everything in one workflow. 40+ nodes. Impossible to debug or extend. One change broke three paths.
State machine (current)
- Thin trigger workflows
- One workflow per job
- One switch in the entire system
- Explicit state transitions
- Human approval gates stored as first-class records
This version is boring — and that’s the point. It’s explainable, testable, and production-ready.
Single-switch orchestration pattern.
All broker responses flow through one intent gate and one switch node, fanning out to independent workflows. This replaces agent chaining with explicit control flow and debuggable state transitions.
The stack (intentionally boring where it should be)
AI is used only where language is involved. Everything else is deterministic.
That constraint is what makes the system trustworthy.
Why this matters beyond freight
Freight brokerage is just one example of a broader pattern:
Industries still run on email, phone calls, and human glue.
AI doesn’t replace people here. It replaces the coordination tax between decisions.
Halibut is proof that:
- Human-in-the-loop systems can scale
- Voice agents are viable for real operations
- State machines beat agent chaos
- Automation is a product, not a script
What’s next
- Post-tender automation (tracking, PODs, invoicing)
- A lightweight web UI alongside Telegram
- Turning this into a repeatable system for other brokerages
This architecture is running in production today, coordinating real customer emails, carrier calls, and broker approvals.
You can see the full system in action — from customer email to tendered load — in the demo.
Built by Fulton Street Labs.
If your business runs on email, phone calls, and spreadsheets — it doesn’t have to.
Book a Free Consultation