FAXP
FAQ
FAQ on FAXP scope, trust, workflows, and adoption for AI Freight Agents in freight booking.
FAXP is designed to make freight booking between AI agents understandable, auditable, and interoperable. This FAQ explains what FAXP does, what it does not do, and how it fits into real freight workflows.
Scope
What does FAXP actually do?
FAXP is an open messaging protocol for AI freight agents to discover opportunities, negotiate terms, exchange booking decisions, and confirm a freight booking in a structured, auditable way.
Example: A broker agent posts a refrigerated load. A carrier agent finds it, submits a bid, receives acceptance, and gets an ExecutionReport confirming the booking.
Scope note: FAXP covers booking-plane communication, not dispatch execution or payment.
What does FAXP not do?
FAXP does not run dispatch, live tracking, POD/BOL workflows, invoicing, remittance, or payment rails. It also does not replace a company’s TMS, load board, or operations team.
Example: FAXP can confirm that a load was booked at $2.62 per mile with agreed commercial terms. It does not send the pickup number, assign the driver, or move money.
Scope note: FAXP is the booking and agreement layer, not the full freight operating system.
Does FAXP replace my TMS or load board?
No. FAXP is meant to sit between systems, not replace them. A TMS or load board can use FAXP as the standardized language for agent-to-agent booking.
Example: A load board still lists freight. A broker TMS still manages internal workflow. FAXP gives the broker agent and carrier agent a shared format to negotiate and confirm the booking.
Scope note: FAXP is an interoperability layer.
Is FAXP a protocol or an API?
FAXP is a protocol. It defines message structure, semantics, and conformance rules. APIs can implement or transport FAXP, but FAXP itself is not tied to a single API design.
Example: A TMS vendor could expose a REST API that sends and receives FAXP messages. The API is the transport. FAXP is the message contract.
Scope note: FAXP defines the language, not a single transport implementation.
Is FAXP only for AI agents, or can existing software use it too?
FAXP is designed for AI agents, but existing software platforms like TMSs, load boards, and portals can implement it as a standardized booking language between systems.
Example: A brokerage TMS can use FAXP to let its internal agent negotiate with a carrier platform, even if the rest of the TMS remains unchanged.
Scope note: FAXP is compatible with both agent-native and legacy-integrated environments.
Is FAXP intended to replace EDI?
Not directly. FAXP is better understood as a modern, agent-native booking protocol that can coexist with legacy EDI and gradually reduce dependence on brittle, fragmented workflows.
Example: A company might continue using EDI for downstream invoicing or status updates while using FAXP for agent-to-agent booking.
Scope note: FAXP modernizes booking interoperability without requiring immediate replacement of every legacy workflow.
Workflow
What happens after a booking is confirmed?
After a valid ExecutionReport, the booking is confirmed at the protocol level. Then the receiving company’s TMS, portal, ops agent, or human team takes over the next step.
Example: A broker agent books a carrier through FAXP. The broker’s TMS receives the ExecutionReport, sees that the carrier is already onboarded, and opens the dispatch and rate confirmation workflow.
Scope note: FAXP ends at booking confirmation. Operational follow-through happens outside core FAXP.
How do dispatch and rate confirmations happen if FAXP stops at booking?
Dispatch and rate confirmations happen through the company’s existing systems and workflows after the booking handoff.
Example: A broker agent and carrier agent agree on a load. The broker system then generates a rate confirmation and sends dispatch information through the broker’s TMS, portal, email workflow, or ops team.
Scope note: FAXP confirms the deal. The company’s systems execute the deal.
When is a load considered officially booked in FAXP?
A load is booked when both parties have agreed on terms and a valid ExecutionReport confirms the booking outcome.
Example: A carrier submits a bid, the broker accepts, required policy checks pass, and the ExecutionReport marks the status as booked.
Scope note: The ExecutionReport is the protocol-level booking confirmation point.
Is an ExecutionReport legally binding by itself?
Not necessarily. FAXP confirms machine-readable agreement. Legal enforceability still depends on the participants’ contracts, rate confirmations, TMS records, portals, email trails, or other existing business and legal processes.
Example: A broker and carrier may use the ExecutionReport to auto-populate a traditional rate confirmation that becomes part of their existing legal workflow.
Scope note: FAXP supports auditable agreement, but it does not replace each party’s legal framework.
Can a load be booked if the parties do not already know each other?
Yes, as long as the booking has sufficient counterparty identity and agreement details. But whether the company allows auto-booking with a new counterparty is a policy decision.
Example: A broker agent books a first-time carrier through FAXP. The booking may be valid, but the broker’s internal policy may require carrier setup before dispatch can proceed.
Scope note: FAXP can support first-time bookings, but onboarding and risk rules stay with the participants.
Can FAXP support both load posting and truck posting?
Yes. FAXP supports both broker/load flows and carrier/truck-capacity flows.
Example: A broker can post a load for carriers to find, and a carrier can post truck capacity for brokers to search and book.
Scope note: FAXP supports both sides of freight matching within booking scope.
Can all parties do all actions?
No. Role boundaries matter.
Example: A shipper can post a load tender, a broker can negotiate and route the booking, and a carrier can post available truck capacity. Those are not all the same permissions.
Scope note: FAXP supports role-aware workflows, not unlimited role overlap.
What happens if the parties agree in FAXP but are not fully setup to work together yet?
The booking can still be valid, but downstream systems may hold dispatch until onboarding, billing setup, insurance checks, or human review is complete.
Example: A broker agent books a carrier, but the carrier is not yet fully onboarded in the broker’s TMS. The booking stands, but the TMS routes the file into setup workflow before dispatch is issued.
Scope note: Commercial agreement and operational readiness are related, but not identical.
Trust and Verification
Does FAXP verify MC authority or insurance itself?
No. FAXP does not directly own or operate compliance verification. FAXP does not determine regulatory eligibility; it authenticates protocol messages and can transport optional verifier evidence. It can transport optional verifier evidence from trusted outside services, but the actual verification is done by external providers or builder-hosted systems.
Example: A broker may rely on a trusted compliance provider for MC authority and insurance checks. FAXP can carry the signed result of that check, but FAXP itself is not the verification service.
Scope note: FAXP authenticates messages and can carry evidence. It does not become the compliance provider.
What is the difference between protocol trust and business trust?
Protocol trust means the message is authentic and came from the agent it claims to come from. Business trust means the company is commercially comfortable doing business with that counterparty.
Example: A carrier agent may be cryptographically authentic at the protocol level, but a broker may still decide not to auto-book because the carrier is new, not onboarded, or has no prior relationship.
Scope note: FAXP handles protocol trust. Business trust is a local policy decision.
How does FAXP know who an agent is?
FAXP relies on authenticated protocol messages, agent identity references, signatures, and trusted policy validation. It is not based on anonymous messaging.
Example: A broker system accepts a booking message because it can validate who sent it and whether that sender is permitted under the current trust policy.
Scope note: Identity is established through protocol controls and local trust policy, not guesswork.
Does FAXP maintain a central registry of all agents?
No. FAXP does not operate as a central directory of all market participants. Identity and trust are established through protocol controls, local policy, and optional trusted verifier evidence.
Example: Two companies can exchange FAXP messages without FAXP itself maintaining a universal list of all carriers or brokers in the market.
Scope note: FAXP is not intended to become a centralized market authority.
Does FAXP assign a universal trust score?
No. FAXP does not own a universal commercial trust score. Companies can use their own internal relationship, onboarding, risk, and performance data in local decision logic.
Example: A broker may allow straight-through automation for one carrier and require human review for another, even if both speak valid FAXP.
Scope note: Trust scoring is participant-side policy, not protocol-owned truth.
Can prior relationship with a counterparty affect booking decisions?
Yes. Prior relationship, payment setup, onboarding status, and service history can influence automation and local trust decisions, but those remain participant-side policy inputs.
Example: If a carrier has already completed setup and performed successfully on prior loads, the broker may auto-advance post-booking workflow after the ExecutionReport.
Scope note: FAXP allows this logic around the protocol, but does not prescribe the score itself.
What is the difference between identity verification and compliance verification?
Identity verification answers “is this human or agent really who they claim to be?” Compliance verification answers “does this business or entity meet required regulatory or commercial criteria?” FAXP may carry evidence for both, but does not own either service.
Example: A company may use one outside provider for identity checks and another for MC authority and insurance checks, then transport both results as optional evidence.
Scope note: FAXP stays neutral across verifier categories and vendors.
Does FAXP require a specific verifier like FMCSA, MyCarrierPackets, RMIS, Highway, or ID.me?
No. FAXP is verifier-neutral. It can support trusted outside verifier evidence without mandating a single vendor.
Example: One implementer may use RMIS, another may use MyCarrierPackets, and a third may use a builder-hosted adapter that normalizes trusted evidence into FAXP-compatible form.
Scope note: FAXP standardizes how evidence is carried, not who must provide it.
Commercial Terms
Can FAXP support more than per-mile and flat rates?
Yes. FAXP already supports PerMile, Flat, PerPallet, CWT, PerHour, and LaneMinimum, with future expansion possible through RFC-governed changes.
Example: A local dedicated move might use PerHour, while a produce shipment might use PerMile, and a warehouse transfer could use a lane minimum.
Scope note: Commercial model expansion is governed through explicit profiles and RFCs.
How are miles handled in a per-mile booking?
Per-mile bookings use explicit agreed-mile semantics and source attribution. Disputes over miles are treated as commercial negotiation issues, not hidden assumptions.
Example: If two agents disagree on mileage, the booking logic can counter or reject based on policy rather than silently accepting mismatched numbers.
Scope note: FAXP makes mileage assumptions visible and auditable.
Can the parties negotiate detention terms up front?
Yes. Booking-time commercial terms can include detention structure, such as grace period, hourly rate, increment, payer responsibility, and basic evidence intent.
Example: A broker and carrier can agree to “$25 per hour after 2 hours, documented delay required” as part of the booking terms.
Scope note: The commercial rule can be modeled in FAXP, even though final proof adjudication remains external.
Can accessorials be agreed up front even if final amounts are unknown?
Yes. FAXP can model booking-time commercial responsibility and allowed patterns without trying to adjudicate final receipts or settlement.
Example: A load may allow reimbursable unloading fees, permits, or escort costs, while leaving the final amount to be determined later outside core protocol scope.
Scope note: FAXP can capture terms and responsibility, not final settlement workflow.
Can FAXP handle specialized trailer requirements and service instructions?
Yes. Equipment taxonomy, trailer subclasses, trailer length ranges, and special instructions are part of the booking-plane commercial model.
Example: A load can specify a step deck, reefer temperature range, tarping requirement, or other service instruction as part of booking-time agreement.
Scope note: FAXP can standardize booking-time requirements without becoming an execution monitoring system.
Can FAXP carry external reference numbers from existing systems?
Yes. Neutral reference numbers can be included so TMSs, shippers, brokers, and carriers can correlate a FAXP booking with their own system records.
Example: A broker can attach its internal load reference while the protocol still uses LoadID as the canonical protocol identifier.
Scope note: FAXP supports external system correlation without replacing local system IDs.
Operations and Handoff
If FAXP stops at booking, how does dispatch actually start?
After ExecutionReport, the booking result is handed to the participant’s TMS, ops agent, portal, or human team. That downstream system handles dispatch execution.
Example: A carrier receives a confirmed booking, and its internal dispatch workflow opens the load in its TMS queue for follow-up.
Scope note: FAXP confirms the booking. The participant’s operations stack executes the next step.
Does FAXP require structured handoff metadata?
Not universally. A valid booking must identify the counterparty, the agent context, and the booking references. Additional operational routing metadata can remain optional in core, while enterprise automation profiles may require it.
Example: A manual workflow can still proceed without a formal handoff endpoint, but a straight-through enterprise flow may require structured routing fields for automation.
Scope note: Identity is mandatory for booking. Routing metadata can be policy-driven.
What is the difference between required counterparty identity and optional handoff metadata?
Counterparty identity is required for a meaningful booking. Handoff metadata is optional routing information that helps downstream systems know what to do next.
Example: A booking must identify who the broker is, who the carrier is, which agent represented them, and what booking reference applies. But the exact dispatch endpoint or portal reference can be optional unless a company’s automation policy requires it.
Scope note: Identity is required for booking. Operational routing may be required by profile or policy, not by universal protocol core.
How does FAXP work with manual workflows versus automated enterprise workflows?
FAXP supports both. A smaller operation may book through FAXP and handle follow-up manually. A larger enterprise may use the same booking result to trigger automated internal workflows.
Example: A small broker may receive an ExecutionReport and then call or email the carrier manually. A larger broker may receive the same ExecutionReport and immediately open an internal TMS workflow for dispatch and rate con generation.
Scope note: FAXP standardizes the booking result, not the required level of downstream automation.
Could a TMS act as the operational handoff target after booking?
Yes. That is one of the most practical outcomes. After booking, the TMS can become the downstream system-of-record for dispatch, rate confirmation generation, setup tasks, and related operations.
Example: A broker TMS receives the booking confirmation and uses the booking references and counterparty identity to route the file into the correct dispatch or setup queue.
Scope note: This is exactly the kind of downstream handoff FAXP is meant to support without owning it.
Integrations and Adoption
How does FAXP relate to A2A and MCP?
FAXP is the freight-specific booking protocol. A2A and MCP are broader interoperability standards that can complement it.
Example: An agent could use A2A to communicate with another agent, MCP to access tools or data, and FAXP to structure the actual freight booking negotiation and confirmation.
Scope note: FAXP is the freight booking language. A2A and MCP are optional surrounding interoperability layers, not required core dependencies.
Is FAXP competing with A2A?
No. A2A is a general agent interoperability framework. FAXP is a freight-specific booking protocol. They are complementary.
Example: A2A can help agents discover and communicate broadly. FAXP defines what a freight booking negotiation actually looks like.
Scope note: FAXP adds domain-specific value without trying to replace general agent standards.
Is FAXP competing with MCP?
No. MCP is for tool and data access. FAXP is for freight booking semantics. They solve different problems.
Example: An agent might use MCP to query a TMS or pricing dataset, then use FAXP to negotiate the actual load booking with another agent.
Scope note: FAXP is not a tool-access standard.
Can a FAXP agent also use A2A and MCP?
Yes. A FAXP agent can use A2A for agent-to-agent interoperability, MCP for tool access, and FAXP for freight booking messages.
Example: A broker agent can use MCP to fetch load details, A2A to coordinate with another agent ecosystem, and FAXP to finalize the booking contract.
Scope note: These standards can be used together.
Who is FAXP for first?
Early adopters are likely to be TMS vendors, load board developers, agent builders, and brokerage software teams. Carriers and shippers benefit most once those tools exist.
Example: A TMS or load board can integrate FAXP first, then expose that capability to brokers, carriers, and eventually shippers.
Scope note: FAXP adoption is likely to start with software and platform builders.
Governance and Project Model
Is FAXP open source?
Yes. The direction is an open, vendor-neutral standard with public protocol, conformance, and governance artifacts.
Example: A builder should be able to implement FAXP without needing permission from a single proprietary platform owner.
Scope note: Openness and neutrality are core strategic goals.
Will FAXP certify implementations?
That is the intended model. FAXP should define conformance and certification criteria, while implementers build and host their own systems.
Example: A builder-hosted adapter or booking implementation could earn a certification level by passing the required FAXP conformance and governance checks.
Scope note: FAXP defines the rules and tests, not the hosted service itself.
What does a certified implementation mean?
It means the implementation passed FAXP-defined conformance, trust, and governance requirements for the scope being claimed.
Example: A certified implementation may prove that it correctly handles booking messages, validation, policy behavior, and approved evidence transport according to the profiles it claims.
Scope note: Certification is evidence-based, not marketing-based.
Will FAXP become a nonprofit foundation or consortium standard?
That is the strategic direction under discussion. The goal is neutral governance, broad industry adoption, and no vendor lock-in.
Example: Instead of a single vendor controlling the standard, FAXP would evolve through open governance and shared industry stewardship.
Scope note: Governance neutrality matters as much as technical neutrality.
Demo and Testing
Is the Streamlit app the protocol itself?
No. The Streamlit app is a demo and testing surface for the protocol logic.
Example: The Streamlit app lets users run booking flows and inspect message behavior, but the protocol itself is the underlying message contract and validation logic.
Scope note: The demo is a learning and validation tool, not the standard itself.
Is the simulation only for testing?
Yes. The simulation and demo exist to test message flows, conformance, policy behavior, and developer understanding before broader adoption.
Example: A developer can run the happy path, review validation results, and confirm profile behavior without needing a full production deployment.
Scope note: The simulation is a proving ground for protocol logic.
Can FAXP be tested manually before there are full autonomous production agents?
Yes. Manual and simulated testing are appropriate and necessary at this stage.
Example: A developer or operator can run a booking flow through the demo, inspect the resulting messages, and validate that the protocol behaves as expected.
Scope note: FAXP is intentionally testable before full production agent ecosystems exist.