Below is a detailed, hierarchical outline of the conversation flow. Each “node” is listed with its role, approximate (x, y) position, and key properties; each “edge” is described with its trigger/condition, source and destination nodes, and its purpose in the branching flow.

────────────────────────────── I. INITIAL CARRIER IDENTIFICATION

1. Greeting_RequestMCNumber • ID: “1” • Type: Default (Start Node) • Position: Approximately (2294, –101) • Purpose: • Greets the caller and introduces “Lexi” from the Highway Haul Bid Management team. • Requests the carrier’s name and MC number. • Extracts variables: userMcNumber and userName. • Outgoing Edges: • Edge 1: If the user provides an MC number • Label: “User provides MC Number” • Target: ToolCall-searchCarriers • Edge 5: If no MC number is provided • Label: “User does not provide their MC Number” • Target: McNumberRequired
2. ToolCall-searchCarriers • ID: “3335fbdb-3ecb-425a-bf45-0de9bab1cd88” • Type: Custom Tool • Position: Approximately (1848, 130) • Purpose: • Calls an external API (via POST) to look up the carrier’s details using the provided MC number (sent as “prefix”). • Extracts data such as apiCarrierStatus, apiCompanyName, etc. • Branching (Response Pathways): • If apiCarrierStatus == VERIFIED → Proceed to PhoneNumberCheck • (Edge 2: when the user confirms an existing MC number in McNumberNotFound also returns here) • If apiCarrierStatus != VERIFIED → Go to McNumberNotFound
3. McNumberNotFound • ID: “52db24fd-caab-4903-80b7-01d77c6c846f” • Type: Default • Position: Approximately (3016, 157) • Purpose: • Informs the caller that the provided MC number did not return any matches. • Asks the caller to confirm the number (spoken digit‐by‐digit). • Outgoing Edges: • Edge 2: If the user “confirms the existing MC Number” → Back to ToolCall-searchCarriers • Edge 3: If the user provides an updated MC number → Go to UpdateMcNumber
4. UpdateMcNumber • ID: “a0cfee90-9094-4124-9b9a-b11b9fe6a270” • Type: Default • Position: Approximately (3016, –33) • Purpose: • Announces that verification will be rerun using the updated MC number. • Re-extracts the userMcNumber (ignoring the previous value). • Outgoing Edge: • Edge 4: Automatically (with “skip user response”) returns to ToolCall-searchCarriers.
5. McNumberRequired • ID: “a82623ce-ade6-4295-92b6-f1df8a440cd2” • Type: Default • Position: Approximately (3371, 677) • Purpose: • Explains that an MC number is required to place bids with Highway Haul. • Requests the MC number from the caller. • Outgoing Edges: • Edge 6: If the caller then provides an MC number → Go to ToolCall-searchCarriers • Edge 7: If the caller still does not provide a number → Go to NoMcNumberTransfer
6. NoMcNumberTransfer • ID: “9f38b67c-15b8-4525-8fd3-3763a3bce8f6” • Type: Transfer Call • Position: Approximately (3086, 933) • Purpose: • In cases where an MC number is not provided or confirmed, informs the caller that a transfer to a supervisor will occur for troubleshooting. • Uses a preset transfer number.
7. PhoneNumberCheck • ID: “e7a043e1-0749-499f-957a-e6c7dcc3f393” • Type: Default • Position: Approximately (2267, 406) • Purpose: • Confirms (in a conversational style) that the caller’s phone number matches the system records (using the company name from the API). • Outgoing Edge: • Edge 33: Always proceeds (edge labeled “always”) from PhoneNumberCheck to the next branch—aiAgentsHHPitch.

────────────────────────────── II. TRANSITION TO LOAD & OFFER FLOW (AND AI AGENT PITCH) 8. aiAgentsHHPitch • ID: “36ef02a4-a593-4834-bf17-5a8a8948ab11” • Type: Default • Position: Approximately (1775, 505) • Purpose: • Congratulates the caller on reaching silver tier in Highway Haul’s AI road warrior program. • Introduces the possibility of a personalized AI agent and asks if more information should be sent. • Outgoing Edges: • Edge 31: If the caller is interested in AI agents → Proceed to Activate AI Agent Nurture • Edge 32: If the caller is not interested → Go to log AI negativity 9. Activate AI Agent Nurture • ID: “49030b23-da50-4a92-9dc8-68ec61cd13b3” • Type: Default • Position: Approximately (1588, 835) • Purpose: • Transitions smoothly from the AI pitch to action by prompting for a load reference number. • The prompt is lengthy and strategic, mentioning performance metrics before asking: “Got a load reference number for me?” • Extracts userLoadReference. • Outgoing Edges: • Edge 20: If userLoadReference is provided (i.e. “is not null”) → Go to ToolCall-searchLoads • Edge 21: If userLoadReference is null → Go to NoMcNumberTransfer 10. log AI negativity • ID: “10d3b88b-7ced-46de-b92b-39321afdcc20” • Type: Default • Position: Approximately (2003, 838) • Purpose: • Acknowledges and “logs” the caller’s disinterest in AI assistance while still re-prompting for a load reference number. • Extracts userLoadReference. • Outgoing Edges: • Edge 19: If userLoadReference is provided (“is not null”) → Go to ToolCall-searchLoads • Edge 18: If userLoadReference is null → Go to NoMcNumberTransfer

────────────────────────────── III. LOAD SEARCH & CONFIRMATION 11. ToolCall-searchLoads • ID: “805bbabc-bcf0-43d8-a415-7f848d288324” • Type: Custom Tool • Position: Approximately (2279, 1242) • Purpose: • Uses the provided load reference (userLoadReference) to search for a load via an API call (POST). • Sends additional parameters (e.g. excludeTestLoads, days limit). • Outgoing Edge: • Edge 34: Upon “Default/Webhook Completion” → Go to LoadFound 12. LoadNotFound • ID: “ad9c2b0a-eedd-48cd-b0c5-678987abd4b8” • Type: Default • Position: Approximately (3428, 1294) • Purpose: • Explains in a friendly, perplexed tone that the provided load reference (spoken digit‑by‑digit) is not found in the system. • Requests confirmation or correction by extracting an updated userLoadReference (ignoring any previous value). • Outgoing Edges: • Edge 8: If the user provides a revised load reference → Go to ToolCall-searchLoads • Edge 9: If no clarity is provided → Go to NoMcNumberTransfer 13. LoadFound • ID: “bb145d7e-896a-4183-8a78-68dd6a470ec6” • Type: Default • Position: Approximately (2281, 1501) • Purpose: • Informs the caller that the load was located and that details are now being pulled. • Outgoing Edge: • Edge 11: “Always Proceed” → Go to GetLoadDetails

────────────────────────────── IV. LOAD DETAILS & OFFER PRESENTATION 14. GetLoadDetails • ID: “8f0b46a7-d159-48cd-91ff-6951561773aa” • Type: Custom Tool • Position: Approximately (2282, 1920) • Purpose: • Retrieves detailed information about the load (size, status, weight, distance, etc.) using a GET API call with the load UUID. • Branching: • If apiLoadStatus == PUBLISHED → LoadDetailsFound (Edge 22) • Otherwise → LoadDetailsNotFound (Edge 23) 15. LoadDetailsNotFound • ID: “db011607-e6fd-4271-a462-5342e4098008” • Type: Default • Position: Approximately (3047, 2338) • Purpose: • Notifies the caller that the load appears with a status different from “PUBLISHED” and that further investigation is needed. • Outgoing Edge: • Edge 15: “User responded” → Route to NoMcNumberTransfer (i.e. escalate via transfer) 16. LoadDetailsFound • ID: “88c12c44-bf46-4795-82ac-d6ddf37a5bfb” • Type: Default • Position: Approximately (2278, 2270) • Purpose: • Presents the load details to the caller using expert, charismatic sales techniques (including subtle side‑comments about load weight and distance). • Outgoing Edges: • Edge 12: If the caller “confirms” the details → Go to getOfferDetails • Edge 13: If the caller “denies” the details → Go to LoadDenied 17. getOfferDetails • ID: “a1a7b7f7-2d69-4b2a-8f6a-e77fd5f7fdc9” • Type: Custom Tool • Position: Approximately (2126, 2485) • Purpose: • Fetches offer details (such as offer price, maximum offer, drop-off instructions, origin and destination addresses, etc.) via a GET API call. • Branching (Response Pathways): • If apiOfferOriginSingleLineAddress is not null → OfferDetailsFound (Edge 24) • If apiOfferStatusDoubleCheck != PUBLISHED → OfferDetailsNotFound (Edge 25) 18. OfferDetailsFound • ID: “97e3d955-a1ee-4bb5-9b81-93fa726b75de” • Type: Default • Position: Approximately (1982, 2763) • Purpose: • Charismatically informs the caller of a silver tier starting rate (using the retrieved offer price) for the route from the origin to destination. • Includes a brief quip about the scenery or a “quirky” bit of small talk. • Outgoing Edges: • Edge 17: If the caller counters the rate → Go to Negotiation1 • Edge 26: (Indirectly, if the trade ask id is later retrieved and the caller accepts) → Eventually lead to RateAcceptInit 19. OfferDetailsNotFound • ID: “a37dea33-4f38-497e-a66e-b8721c7686c8” • Type: Default • Position: Approximately (2386, 2763) • Purpose: • Informs the caller that a supervisor is now directly overseeing the route (due to missing or invalid offer details) and prepares to transfer the call. • Outgoing Edge: • Edge 14: “User responded” → Go to TransferForMinBid 20. LoadDenied • ID: “6157293d-9a69-43b1-b4f1-7934f0326c79” • Type: Default • Position: Approximately (2619, 2486) • Purpose: • Asks the caller (using their name) to specify which parts of the load details they dispute and confirms if they are still interested in bidding. 21. PreNegotiationBackout • ID: “727c21b2-e286-4234-bde3-c72dc3169091” • Type: End Call • Position: Approximately (3303, 2691) • Purpose: • Thanks the caller for their time and reminds them that many loads are available daily, thereby closing the conversation gracefully if the caller opts out.

────────────────────────────── V. TRADE ASK & BIDDING / NEGOTIATION PHASE 22. getTradeAskId • ID: “07684b1b-9257-4203-9f33-cff70452701a” • Type: Custom Tool • Position: Approximately (1979, 2953) • Purpose: • Calls an API (GET) to retrieve the trade ask ID necessary for placing a bid on the load. • Branching (Response Pathways): • If apiTradeAskId is not null → TradeAskIdFound (Edge 26) • If apiTradeAskId is null → TradeAskIdNotFound (Edge 27) 23. TradeAskIdNotFound • ID: “69064b05-5683-4ffd-b4dc-8fb30f012bbd” • Type: Default • Position: Approximately (2517, 3190) • Purpose: • Prompts the caller with “hmmm. How does that offer sound?” when no trade ask ID is returned. • Outgoing Edge: • Edge 28: After the user responds → Go to getTradeAskIdRetry 24. TradeAskIdFound • ID: “c15f66f9-b1d8-4acd-b6ca-db2a0db22c88” • Type: Default • Position: Approximately (1973, 3251) • Purpose: • Directly asks “How does that sound?” confirming the bid details. • Outgoing Edges: • Edge 17: If the user counters (proposes a higher rate) → Go to Negotiation1 • Otherwise, acceptance may eventually lead to RateAcceptInit via subsequent confirmation 25. getTradeAskIdRetry • ID: “29fad3f0-137c-44fb-a766-fa0f36e1e75e” • Type: Custom Tool • Position: Approximately (2834, 3364) • Purpose: • Retries obtaining the trade ask ID after an initial failure. • Branching (Response Pathways): • If apiTradeAskId is not null → Negotiation1 (Edge 29) • If apiTradeAskId is still null → OfferDetailsNotFound (Edge 30) 26. Negotiation1 • ID: “399c0655-ea58-4e71-9cad-633f5909d758” • Type: Default • Position: Approximately (2152, 3540) • Purpose: • Engages in profit‑driven negotiation by asking the caller what rate they consider appropriate between the offered range. • Extracts the variable userBidPrice. 27. RateAcceptInit • ID: “4c495e25-9c5e-4925-8740-13f7d17c1a87” • Type: Default • Position: Approximately (1655, 3542) • Purpose: • Expresses confidence and affirmation in the carrier’s decision to accept the offered rate. 28. TransferForMinBid • ID: “0567ff0d-bce3-4f48-ac5c-74d6008fd5aa” • Type: Transfer Call • Position: Approximately (2889, 2765) • Purpose: • Initiates a call transfer (using the given transfer number) when minimum bid issues arise or when escalation is needed.

────────────────────────────── VI. SUMMARY OF KEY EDGE TRANSITIONS

Below is a brief list of the critical edge connections (by ID and label): • Edge 1: From Greeting_RequestMCNumber → ToolCall-searchCarriers (“User provides MC Number”) • Edge 2: From McNumberNotFound → ToolCall-searchCarriers (“The user confirms the existing MC Number.”) • Edge 3: From McNumberNotFound → UpdateMcNumber (“User provides an updated MC Number.”) • Edge 4: From UpdateMcNumber → ToolCall-searchCarriers (“skip user response”) • Edge 5: From Greeting_RequestMCNumber → McNumberRequired (“User does not provide their MC Number”) • Edge 6: From McNumberRequired → ToolCall-searchCarriers (“User provides MC Number”) • Edge 7: From McNumberRequired → NoMcNumberTransfer (“User does not provide their MC Number.”) • Edge 8: From LoadNotFound → ToolCall-searchLoads (“User provides a revised Load Reference number”) • Edge 9: From LoadNotFound → NoMcNumberTransfer (“User does not provide clarity on the load reference number.”) • Edge 10: From LoadDenied → PreNegotiationBackout (“User is no longer interested”) • Edge 11: From LoadFound → GetLoadDetails (“Always Proceed”) • Edge 12: From LoadDetailsFound → getOfferDetails (“User confirms”) • Edge 13: From LoadDetailsFound → LoadDenied (“User denies”) • Edge 14: From OfferDetailsNotFound → TransferForMinBid (“User responded”) • Edge 15: From LoadDetailsNotFound → NoMcNumberTransfer (“User responded”) • Edge 16: From OfferDetailsFound → getTradeAskId (“always choose this pathway”) • Edge 17: From TradeAskIdFound → Negotiation1 (“User counters rate”) • Edge 18: From log AI negativity → NoMcNumberTransfer (if userLoadReference is null) • Edge 19: From log AI negativity → ToolCall-searchLoads (if userLoadReference is not null) • Edge 20: From Activate AI Agent Nurture → ToolCall-searchLoads (if userLoadReference is not null”) • Edge 21: From Activate AI Agent Nurture → NoMcNumberTransfer (if userLoadReference is null”) • Edge 22: From GetLoadDetails → LoadDetailsFound (if apiLoadStatus == PUBLISHED”) • Edge 23: From GetLoadDetails → LoadDetailsNotFound (if apiLoadStatus != PUBLISHED”) • Edge 24: From getOfferDetails → OfferDetailsFound (if apiOfferOriginSingleLineAddress is not null”) • Edge 25: From getOfferDetails → OfferDetailsNotFound (if apiOfferStatusDoubleCheck != PUBLISHED”) • Edge 26: From getTradeAskId → TradeAskIdFound (if apiTradeAskId is not null”) • Edge 27: From getTradeAskId → TradeAskIdNotFound (if apiTradeAskId is null”) • Edge 28: From TradeAskIdNotFound → getTradeAskIdRetry (“User responded”) • Edge 29: From getTradeAskIdRetry → Negotiation1 (if apiTradeAskId is not null”) • Edge 30: From getTradeAskIdRetry → OfferDetailsNotFound (if apiTradeAskId is null”) • Edge 31: From aiAgentsHHPitch → Activate AI Agent Nurture (“User is interested in AI agents for carriers”) • Edge 32: From aiAgentsHHPitch → log AI negativity (“User isn’t interested in AI agents for Carriers”) • Edge 33: From PhoneNumberCheck → aiAgentsHHPitch (“always”) • Edge 34: From ToolCall-searchLoads → LoadFound (“Default/Webhook Completion”)

────────────────────────────── OVERALL FLOW SUMMARY

1. The call begins by greeting and requesting the MC number (node “Greeting_RequestMCNumber”).
2. Depending on whether an MC number is provided—and whether it yields a verified carrier record via the “ToolCall-searchCarriers” API call—the flow either confirms details (via “PhoneNumberCheck”) or prompts for correction (via “McNumberNotFound” and “UpdateMcNumber”) or, if still missing, transfers to a supervisor (“NoMcNumberTransfer”).
3. After successful carrier verification (and phone check), the system pitches an AI agent program (“aiAgentsHHPitch”). • Depending on the user’s interest, it either proceeds to prompt for a load reference (via “Activate AI Agent Nurture” or “log AI negativity”) or—if no reference is provided—transfers the call.
4. With a load reference provided, a search is initiated (“ToolCall-searchLoads”). • If found, the system confirms the load (“LoadFound”) and retrieves detailed load data (“GetLoadDetails”). • Depending on the load status, the flow presents the load details (“LoadDetailsFound”) or handles discrepancies (“LoadDetailsNotFound” → “LoadDenied” or transfers).
5. Next, the system fetches offer details (“getOfferDetails”) and presents an offer (“OfferDetailsFound”) or, if the offer cannot be verified, escalates (“OfferDetailsNotFound” → “TransferForMinBid”).
6. Finally, the bidding phase begins with an API call to obtain a trade ask ID (“getTradeAskId”). • Depending on the outcome, the caller is either asked to confirm the bid (“TradeAskIdFound”) or, if a counter is proposed, enters negotiation (“Negotiation1”). • A confirmed acceptance is acknowledged (“RateAcceptInit”).

This comprehensive outline—with nodes identified by name, ID, approximate positioning, purpose, and connected via clearly labeled edges—captures the entire branching logic of the conversation flow.