How it works

A freight broker sits between companies that ship goods and trucking companies that move them. Every load produces a pile of paperwork: a rate confirmation, a bill of lading, a signed proof of delivery (POD), GPS pings, emails, a detention log, a carrier invoice and a bank deposit. Those sources rarely agree. Freight companies waste about $15B a year waiting at docks, and roughly half of all detention bills are never paid correctly. Today a small team reconciles all of it by hand, and that's where padded charges, duplicate invoices, double brokering and bank-change fraud slip through.

FreightLine is the agentic finance team a brokerage would hire for that work, and it runs on its own. It fills the carrier-payables clerk, payables fraud analyst and collections specialist seats at a 40-person freight brokerage, all reporting to the controller. Here's the path a single document takes.

How it works

1. Documents arrive

A live stream of brokerage activity flows in: invoices and PODs as PDFs, raw emails, BAI2 bank files and GPS pings. They come from a simulated brokerage built around real carriers and shippers. That includes 82 trucking companies confirmed against the federal FMCSA registry, plus shippers from SEC EDGAR. The company also has a past: 90 days of history, about 420 resolved loads with their journals, aging receivables and disputes. So the agents start with a real set of books, not an empty ledger.

2. Intake on the ASUS GX10

Every document lands on our ASUS GX10, which acts as the company's front desk. Local models classify the document, find the people and addresses in it, and replace all personal data with vault tokens before anything leaves the box. Exact code reads every dollar amount. Each document is checked against memory: have we seen this invoice before? Does this carrier match the verified directory? What does the carrier's history look like? Then the GX10 works out which specialist owns the case and hands it over through the A2A protocol, the open standard agents use to talk to each other. It handles 163–170 documents a minute at about 1.6 s each.

The GX10 also hosts our agents' inference in parallel. Its unified memory holds several models at once, so many agents can think at the same time on one desk-side machine, without queueing behind a cloud rate limit.

3. Nine specialists work the case on their own

FreightLine is a team of nine agents. Each runs as its own service with its own job, its own tools and its own permissions:

Agent	Job
Carrier Settlement	Matches invoices to contracts and proof of delivery, then proposes payments
Accessorial Audit	Checks detention, lumper and other extra charges against the evidence
Carrier Trust & Verification	Verifies carrier identity and bank changes with independent callbacks
POD & Document Chase	Chases missing delivery proof and receipts, then resumes waiting cases
Shipper Billing & Collections	Matches deposits to invoices and follows up on overdue balances
Load Profitability	Tracks load margins and forecasts the impact on cash
Settlement Approvals	Manages holds and posts balanced journal entries once approvals are in
Dispatcher Outreach	Phones carriers and shippers for missing proof, verification and collections
Settlement Quality Review	Reviews every financial output and turns mistakes into versioned lessons

Agents hand work to each other directly. For example, Carrier Settlement spots a detention charge and asks Accessorial Audit to check it. Accessorial Audit finds the receipt is missing and asks POD & Document Chase for it, which in turn has Dispatcher Outreach call the carrier. While a case waits on a document or an approver, its task parks; when the answer arrives days later, it resumes exactly where it stopped. Nobody prompts any of this. The stream drives the work.

4. Money moves only through controls

Agents decide what should happen. Before anything happens, a deterministic policy engine and the database's transactional rules check it. Journals must balance, periods must be open, and payments above the threshold need a human approver. The agent that requests a payment can never approve it. Each shipper invoice books revenue and each approved carrier payment books a payable, so the ledger always adds up.

5. Everything is explainable

Every change is recorded as a change set in a hash-chained audit trail, like a Git history for the books. Click any cell in the ledger and you see the source document, the agent and task that read it, the change it made, and the policy behind it. The dashboard shows all nine agents working live, keeps what needs you separate from what the agents are handling, and lets you open any case to see its documents, emails, bank lines and full decision trace.

6. It gets better over time

Settlement Quality Review checks each output. When something goes wrong, it writes a versioned lesson or instruction change, and a human can roll it back. Agents recall similar past cases before deciding, so the team learns its carriers, its lanes and its own mistakes.

What it catches: unsupported detention, rates above contract, inflated fuel surcharges, math errors, lumper charges without receipts, unsigned PODs, duplicate invoices, double brokering, unverified factoring, USDOT issues, bank-change fraud, short pays and misapplied payments.

Proof it works

The simulator plants errors at set rates and writes an answer key. An evaluator scores the agents' decisions against it for precision, recall, dollars caught and false holds. On a 300-document benchmark:

Personal-data scrubbing: 100% recall, with 0 of 1,215 planted values leaked.
Amounts: 132/132 invoice totals and line items read correctly.
Errors caught: 4/4 planted math errors, 45/45 duplicate invoices, 3/3 double-brokering cases and 15/15 factoring mismatches, with 0 false flags on 83 clean invoices.
Throughput: 163–170 documents a minute. A 14,809-item backlog drained after a router restart with nothing lost.
Cloud latency: 3.4 s from enqueue to agent acceptance on hosted SpacetimeDB, with the full chain (settlement, then quality review) visible live on the dashboard.
Tests: 800+ automated tests across the backend, the frontend and the database module.

Real: the agents, model calls, A2A messages, phone calls, FMCSA, SEC and website data, and the hosted databases. Simulated: the brokerage itself and its loads, invoices and planted errors. A teammate answers the phone as the dispatcher.

Sponsor tracks

Hyphenate: The Hyphenated Enterprise

A large freight brokerage moves thousands of loads a week, and every one of them ends up in finance. Behind that sits a big back office. Teams of payables clerks match each carrier invoice against the rate confirmation and the proof of delivery. Fraud analysts check every bank-detail change and every carrier that looks slightly off. Collections reps chase shippers who paid short or paid late. Controllers sign off on the payments that matter. The only way to handle more freight today is to hire more people into those queues, and the more volume goes through by hand, the more often a detail gets missed: a padded detention charge, an invoice paid twice, a payment sent to a fraudster's account.

FreightLine does that work with agents instead of headcount. The work starts the way it does at a real brokerage, with sources that disagree. A carrier bills $250 of detention, the GPS says the truck left at 12:15, the rate con gives two free hours, and the signed receipt is missing. Our brokerage runs live. Loads, PDFs, emails, BAI2 bank files and GPS pings stream in continuously, and the agents work them as they arrive, the same inputs a clerk would see. Its counterparties are 80 real carriers checked against FMCSA and real shippers from SEC EDGAR, and it has 90 days of books already on file.

Each agent is set up the way you'd set up a new hire. It has one job, only the tools that job needs, and its own login to the books. Settlement Approvals plays the controller: it places holds, signs off on payments and posts the journal entries, and the agent that asks for a payment can never be the one that approves it. Those rules are enforced by the database, not written into a prompt, so a model can't argue its way past them. When an agent gets something wrong, the quality reviewer catches it, re-checks the work and writes a versioned lesson that the agent uses from then on. Every number on the books traces back to the document it came from, the agent that read it, the change it made and the policy that allowed it.

The agents also work as a team, not as one assistant with a long list of tools. Nine services hand work to each other directly over the A2A protocol. A case waiting on a document or an approver parks, then resumes where it stopped when the answer arrives. When a receipt is missing, Dispatcher Outreach calls the carrier, explains the $125 calculation, asks for the receipt and holds its position when the dispatcher pushes back, with the disputed amount already on hold.

In finance, a mistake costs money. Accuracy is something we made a top priority and put a lot of work into optimizing, so we check the work in three places.

First, intake on the GX10. Every document is checked against its type before anything else happens. Dollar amounts are read by code, not a model, because when we tested it, the model got invoice totals wrong and the code didn't. Each document is also compared with what we've seen before (duplicates, the verified carrier list, the carrier's history) before it gets routed.

Second, the database. The money rules are SpacetimeDB reducers, not prompt instructions. A write to the books only goes through if the amounts are exact to the cent, the journal balances, the period is open, there's no hold, the invoice hasn't already been paid and the requester isn't the approver. If any of those fail, the whole write is rolled back. An agent can propose whatever it wants, but bad entries never land.

Third, review. Settlement Quality Review re-checks every financial output an agent produces. It recomputes the money, makes sure every citation points at a real source and checks that the decision holds up both ways. Its model can explain a failure, but it can't change the result of a check. When something fails, the reviewer writes a lesson for that agent, which is where the learning loop below comes in.

SpacetimeDB: the shared brain all nine agents coordinate through

Where it sits: at the center of the flow. Every case, task, delegation, hold, approval, journal entry, audit row and memory lives in SpacetimeDB. That's 37 tables and 43 reducers, running on Maincloud!

Why SpacetimeDB: We have a huge volume of data, and we need logic inside the database. A typical stack spreads this across a database, an API server and a websocket layer. With SpacetimeDB, our financial rules run as transactional reducers right next to the data, and clients subscribe to live SQL queries. That fits an agent team exactly with nine services acting at once.

Rules and audit in one transaction. A reducer validates amounts to the cent, checks the journal balances and the period is open, enforces requester ≠ approver, and writes the SHA-256-chained audit row, all atomically. A payment can't land without its audit trail.
Identity-based permissions. Every agent, the router and each human has its own SpacetimeDB identity, and every reducer checks that identity's role. Permissions are enforced by the database itself.
Atomic work handoffs. The first hop commits the routing outbox row and the dispatch record in one transaction. A worker claims it with a lease and delivers it over A2A, so a crash never loses or duplicates work.
Live subscriptions run the dashboard. The agent map, inboxes and case traces update as reducers commit. We scoped subscriptions to a sliding history window, with full case detail loaded on demand, so the dashboard stays fast under a continuous stream.

Pushing it: the simulator streams loads continuously and the demo console fires bursts of up to 200 loads each batch. Nine agents send heartbeat updates every 15 seconds while writing tasks, tool audits and model-call logs. It's a lot of data, but that's exactly why we need SpacetimeDB!

Elastic: memory that makes the team smarter at two points in the flow

Where it sits: at intake, before routing, and inside the agents, before they decide.

Why Elastic: finance memory is a search problem. "Have we seen this invoice before, maybe renumbered?" and "How did we resolve a case like this last month?" are fuzzy, ranked questions, and Elasticsearch answers them in milliseconds across thousands of documents.

Intake context memory (Elasticsearch 8.15 on the GX10). Every incoming document queries the carrier's history and similar past documents before routing. That runs at the full intake rate of 163–170 documents a minute. On the benchmark it surfaced the original invoice for 45/45 duplicates and raised 233/233 history warnings, with 0 false warnings across 238 clean cases. We backfilled 3,737 scrubbed records and confirmed that 0 of 20,461 planted personal values reached the index.
Agent recall (Elastic Cloud agent-memory index). Agents call find_similar_cases before they decide. We split the work so each system does what it's best at: Elastic ranks the matches, and SpacetimeDB returns the rows. Recall is therefore always fast and always current. A lesson a human reverted disappears from recall right away. A looping sync mirrors only the documents that changed, which keeps the index fresh at low cost.

Microsoft: Built for the Real World

At a big brokerage, the finance team grows with the freight. Every load ends in a carrier invoice someone has to match against the rate con and the POD, and a shipper payment someone has to apply. When the brokerage adds a thousand loads a week, the back office adds people. They work queues all day, and they still miss things, because nobody can look closely at every page when there are thousands of them.

The money that gets missed mostly isn't from obvious mistakes. A carrier bills two hours of detention when the GPS shows the truck left 47 minutes after it arrived. The same load gets invoiced again under a new invoice number, and both get paid. A "carrier" emails from a domain one letter off from the real one, asking to update the bank details, and the next payment goes to a stranger. A load gets brokered to someone else, and the company that actually hauled it shows up later asking to be paid. Each of these costs a few hundred to a few thousand dollars, and at enterprise volume they happen every day.

We wanted to see how much of that money FreightLine keeps from going out. We ran 1,002 loads through our stream, $1.96M in carrier invoices, with problems planted the way they show up in real life. $271K of it was money that shouldn't have gone out as billed, about $270 per load. Most of it wasn't overbilling. Changed bank details accounted for $63K, duplicate and renumbered invoices $69K, unsigned PODs $36K, factoring mismatches $29K and double brokering $10K. Padded linehaul, fuel, lumper and detention charges together came to about $18K. In other words, the expensive problems are fraud and paying twice, and those are the ones a busy clerk is least likely to catch, because the invoice itself looks fine.

Then we put every type of problem through the real agents. Every one was stopped before money moved. The duplicate was rejected. The bank change was blocked until the carrier could be verified on a number we already had on file. The double-brokered load was held on carrier identity. The detention was held, and Dispatcher Outreach called the carrier to ask for the receipt. The short pay went to collections. Meanwhile, the clean invoices, and the decoys that look wrong but aren't (QuickPay discounts, small detention charges with a receipt), were approved. So the carriers who billed correctly got paid without waiting behind the ones who didn't.

It also handles the volume. One GX10 takes in 163–170 documents a minute, close to 10,000 an hour. Nine agents work cases as they arrive, all day and all night, so there's no backlog building up for the morning. A short pay turns into a collections call when the bank file arrives, not at month-end. When we restarted the router with 14,809 items queued, every one of them came through. The brokerage can take on more loads without hiring more people to work the queues.

Month-end gets easier too. Every entry on the books links to the document it came from, the agent that made it and the rule that allowed it, so an auditor who asks "why did we pay this?" gets an answer right away instead of a search through someone's inbox.

None of this works if the agents get the money wrong. Dollar amounts are read by code, the payment rules live in the database where a model can't argue with them, and a separate reviewer checks every decision again before it counts. Each agent runs as its own A2A service, so a brokerage can scale the busy ones on their own machines, just like the rest of its systems.

Apify: real-world evidence on demand

Where it sits: inside the agents' fraud and identity checks, and in building the company's world.

Why Apify: public data on carriers is scattered across government registries and company websites. Apify's ready-made actors give us maintained, schema-checked scrapers we can call as tools, with each run tracked, priced and reproducible. That's exactly what an agent needs to gather evidence it can cite.

For example:

fmcsa-carrier-check confirms a carrier's USDOT and MC numbers and its operating authority. We added name matching: the registered legal or DBA name must match the carrier on the invoice. That check caught "Sierra Haul LLC" billing under a USDOT registered to a different company, which is the classic double-brokering signature.
contact-info-scraper inspects a carrier's website for its public contact details. Those are recorded as observations to verify, which strengthens our callback-verification step.
Built for agent scale. Agents pick lookups themselves. Every run has a budget cap and is recorded durably, so it's never resubmitted twice, and results are cached for 24 hours.
Pushing it: a single run checked 82 real carriers for just $0.25, and those carriers now make up the brokerage's carrier base. It's thanks to Apify that we're able to give every single agent access to real-time web data to validate cases.

Cartesia: the team's voice

Where it sits: at the end of the flow, when the paperwork runs out and a person has to answer. In freight, detention disputes, missing receipts and bank-change checks are settled by phone, so voice is how this team gets its work done.

Why Cartesia: a dispute call only works if the agent sounds natural, responds instantly and can stand firm while the other person pushes back. Cartesia's low-latency, expressive voices keep the conversation natural, and its hosted agents with in-call tools let the voice pull live case data mid-sentence. A pre-written script can't do that.

Three hosted personas, one per job: verification, collections and approvals, each with its own tone and purpose, on a real outbound number.
Five case-scoped lookup tools during the call: load, documents, case summary, invoice and payment status. Each call gets a short-lived capability token, so the voice reads only its own case. The agent works out the detention math on the call and asks for the specific missing document.
Calls are real workflow steps. Each call is a durable Verification → Dispatcher Outreach A2A task. The transcript becomes findings on the case, and the case moves forward.
Responsible by design: the agent says it's an AI at the start, dials only verified directory contacts (team numbers in demo mode), respects calling windows, and calls each company at most once an hour.

Notability

We planned FreightLine in Notability, from first sketch to final build: early architecture sketches, the agent org chart, the policy rules, and recorded mentor conversations.

Our very first architecture diagram for our project was drawn out in Notability including which sponsor tools we would include and how the end-to-end data flow would look like.

We then wrote out a high-level overview of what our project does with the most important components/sections highlighted and flows drawn out. Additionally we used Notability’s Smart Notes feature to summarize and help us better understand the project flow so we were all on the same page.

Finally, during a late-night meeting, one of our teammates used Notability’s audio recording capability to capture all of our thoughts and conversations while another one was typing out quick notes simultaneously on the same note file. Meeting Transcription

FreightLine took shape in Notability. Our sketches, rules, calculations, and mentor conversations formed the working foundation that carried the project from an initial idea into a build.

Challenges we ran into

Models misread money, for example treating "9151.8" and "9151.80" as different. We gave every amount to exact code (132/132 correct) and kept models on language.
Coordinating nine agents at once. After the first hop, agents delegate to each other directly, so work keeps flowing even if intake restarts.
Choosing models for the GX10. We benchmarked a range of open models and picked a fast lineup that fits alongside the agents' inference.
Keeping memory current. Splitting search (Elastic) from truth (SpacetimeDB) gave us fast recall that never goes stale.

Accomplishments we're proud of

We’re proud of getting an agent on a real phone call to defend its calculation using live case data. We also drained a 14,809-item backlog after a restart with zero loss and built an audit trail where any ledger cell can explain how it got there.

What we learned

We learned that autonomy in finance comes from the structure around the agent. Scoped tools define what it can do, deterministic controls enforce the rules, and durable state lets it pick up after a restart. With a record of each decision, we can let agents run on their own and still trace what happened afterwards.

What's next

Next, we’re adding email intake and replies, a reader UI for the triage queue, and richer precedents for agents to draw on. We also plan to connect sandbox banking and run a pilot with a real brokerage to see how the system holds up in day-to-day operations.