The mission loop
fOS runs one loop — find, price, bid, negotiate, execute, learn. Every tool serves a stage of it. This page walks the loop stage by stage and explains the inclusion principle that decides what earns a place as a tool.
fOS exists to run one loop, end to end:
find → price → bid → negotiate → execute → learn
Every tool fOS has serves a stage of this loop. Understanding the loop is understanding fOS.
The stages
Find
Locate freight worth pursuing. fOS searches available loads and matches them against the carrier's live capacity, and surfaces the chains the platform has already built. The output of find is candidate freight — a load, a match, or a proposed chain.
Price
Understand the economics before acting. fOS reads a chain's real profit-and-loss from the cost engine and the lane's market from APEX. It never computes its own cost — pricing is a read of authoritative numbers (see Cost grounding).
Bid
Turn economics into a price and put it forward. fOS uses the bid recommendation — cost floor positioned against market — to make a direct offer to a shipper's contact, or to submit a bid onto an exchange. Bidding is an action: it changes the state of a deal.
Negotiate
Move the deal to a "yes" without going below the floor. On a live call or over email, fOS checks whether a counter-offer clears the carrier's walk-away floor, reports how the conversation is going, and hands off to a human when a deal is complex or out of bounds. It never reveals the floor to the counterparty.
Execute
Lock in the win. When the carrier has secured the load, fOS confirms the win — which records the association and triggers commission billing (see Procurement & outreach). This is a money-moving action, so it is idempotent and confirmation-gated (see Guardrails).
Learn
Get sharper for next time. Every interaction is logged, and won/lost outcomes feed back into the per-contact intelligence — win rates, objections, what arguments work. The next deal with that contact starts from what the last one taught. This is the stage that makes the dispatcher compound rather than merely repeat.
The inclusion principle
fOS is deliberately small: capabilities are added only when they serve the loop. A tool earns its place only if it is one of:
- An action — it moves a deal through the loop (search a load, make an offer, confirm a win, log an interaction).
- A decision-grade read — its output changes the very next action (chain economics, a shipper's profile, whether a rate clears margin).
- A reference surface — a real data table a dispatcher consults to operate (fleet status, benchmark fuel or driver rates).
- Plumbing — a surface needs it to function (ask the user for a missing detail, connect an integration, switch org context).
A capability does not earn a place if it re-computes what the cost engine already provides, fabricates a number, or is a lookup fOS could get from a decision-grade tool it already calls. This principle is why fOS has a tight, curated tool set rather than a sprawling one — see the Tool arsenal.
The loop in practice
The stages compose into recognizable dispatcher workflows — for example, winning a backhaul (find a return load → check its chain economics → read the shipper → make a direct offer), or handling an inbound rate call (pull the shipper's profile → check the rate against margin → report the call outcome → escalate if needed). These end-to-end workflows are documented as fOS › Guides.
Meet fOS
fOS is "your dispatcher, multiplied" — an operator, not a chatbot. It runs the freight loop (find, price, bid, negotiate, execute, learn) using the same tools and economics as the TOVR platform, across web, voice, and external assistants.
Cost grounding
Why fOS never fabricates a number. Its economics come from the cost engine and APEX, not from the language model. This is a design rule — a tool that would estimate a cost the engine already computes is cut, not kept.