Building AI Agents for Supply Chain
This is the developer guide for building an AI agent that interacts with freight and supply chain APIs. You will learn how to wire a language model to a freight API, define tools, build the agentic loop, add guardrails, and go from a basic quoting agent to a full lifecycle freight procurement system.
What you need
LLM access
Claude or GPT-4 API key.
You need access to a language model that supports tool use (function calling). Claude and GPT-4 both work well for freight agents. The model handles reasoning and decision making. It does not need to be fine-tuned on freight data.
Freight API
Warp API credentials.
You need API credentials for a freight API that returns structured JSON. Warp's quote endpoints are free, so you can develop and test the read-side without booking real freight. The API covers the full lifecycle: quoting, booking, tracking, invoicing, and document retrieval.
Agent framework
Optional but helpful.
You can build an agent with just the LLM SDK (Anthropic SDK or OpenAI SDK) and a loop. Agent frameworks like LangChain, CrewAI, or Anthropic's Agent SDK provide pre-built patterns for tool management, memory, and orchestration. Start simple. Add a framework when complexity demands it.
Step 1: Define your freight tools
Tools are what give your agent its capabilities. Each Warp API endpoint becomes a tool that the agent can call. Define each tool with a name, description, and parameter schema. The description is critical: it tells the language model when and why to use the tool.
get_freight_quotes
Rate shopping tool.
Parameters: origin (city, state, zip), destination (city, state, zip), items (weight, dimensions, class, quantity), pickup_date. Returns: array of rate options with carrier_name, total_cost, transit_days, service_level, quote_id. Description: "Get freight rate quotes from multiple carriers for a shipment."
book_shipment
Booking tool.
Parameters: quote_id, shipper_contact, receiver_contact. Returns: shipment_id, tracking_number, order_id, estimated_delivery_date. Description: "Book a freight shipment using a previously received quote ID."
get_tracking
Tracking tool.
Parameters: shipment_id or tracking_number. Returns: current_status, location, estimated_delivery, event_history[]. Description: "Get the current tracking status and event history for a shipment."
Step 2: Write the system prompt
The system prompt gives your agent its identity, domain knowledge, and business rules. This is where you encode the judgment that the agent applies when making decisions.
Role definition
What the agent is.
Define the agent's role clearly: "You are a freight procurement agent. You receive shipping requests and handle the full lifecycle: quoting, carrier selection, booking, tracking, and exception handling." A clear role prevents the model from drifting into irrelevant behavior.
Business rules
Decision boundaries.
Encode your business logic: "Never book above $800 without human approval. Prefer carriers with 95%+ on-time rate on this lane. If transit time exceeds 5 days, check for expedited options. If no quotes are below threshold, escalate to the procurement team." These rules constrain the agent's decisions.
Domain context
Freight knowledge.
Include Warp's llms.txt content in the system prompt. It provides the agent with knowledge about freight terminology, API capabilities, common workflows, and error handling patterns. This context eliminates the need for fine-tuning and gives the agent freight literacy from day one.
Step 3: Build the agentic loop
The agentic loop is straightforward: send the conversation to the model, check if the model wants to use a tool, execute the tool if so, add the result to the conversation, and repeat. Here is the pattern.
Send
Pass conversation + tools to the model.
Send the full conversation history (system prompt, user message, previous tool calls and results) along with the tool definitions. The model decides whether to respond with text (done) or a tool call (needs to take action).
Execute
Run the tool call.
Parse the model's tool call (function name + parameters). Map it to the corresponding API call. Execute the API call. Capture the response (success or error). The runtime handles execution. The model never calls APIs directly.
Loop
Feed result back, repeat.
Add the tool result to the conversation history. Send the updated conversation back to the model. The model now has the result and can decide: call another tool, or provide a final response. Continue until the model responds with text instead of a tool call, or you hit the iteration limit.
Step 4: Add guardrails
Cost limits
Cap autonomous spending.
Set a per-shipment cost ceiling. If the best available rate exceeds the threshold, the agent pauses and requests human approval instead of booking. Start with a conservative threshold and raise it as you build confidence.
Iteration limits
Prevent runaway loops.
Set a maximum number of tool calls per task (e.g., 20). If the agent has not completed the task within that limit, it stops, reports its progress, and escalates. This prevents infinite loops and controls API costs.
Audit logging
Log every decision.
Log every tool call, every model reasoning step, and every decision point. This audit trail is essential for debugging, compliance, and improving the agent over time. You should be able to reconstruct why the agent made any given decision.
Going from prototype to production
A basic quoting agent is a starting point. To go to production, add webhook handlers so the agent can monitor tracking events in real time. Add persistent memory so the agent learns carrier performance patterns. Add exception handling workflows so the agent can rebook failed pickups. Add the settlement workflow so the agent can audit invoices after delivery. Each capability builds on the same agentic loop pattern.
Consider a multi-agent architecture as complexity grows. Instead of one agent handling everything, specialize: a quoting agent, a tracking agent, an exception agent, a settlement agent. They share the same Warp API tools but each has a focused scope and simpler reasoning requirements.
Frequently asked questions
What programming language should I use to build a freight agent?
Python and TypeScript are the most common choices. Python has the strongest LLM ecosystem (LangChain, Claude SDK, OpenAI SDK) and is the default for most agent frameworks. TypeScript works well if your existing supply chain systems are Node-based. The language matters less than the API design: your agent needs to call a freight API that returns structured JSON.
How long does it take to build a basic freight agent?
A basic freight quoting agent (call the API, compare rates, select the best option) can be built in a day with an LLM SDK and Warp's API. A production agent that handles the full lifecycle (quote, book, track, handle exceptions, audit invoices) with proper error handling, guardrails, and monitoring takes 2-4 weeks of development.
Do I need to fine-tune an LLM for freight?
No. General-purpose models like Claude and GPT-4 handle freight workflows well when given proper tool definitions and system prompts with domain context. Warp's llms.txt file provides pre-built context about freight operations that you can include in your agent's system prompt. Fine-tuning is only necessary if you need the model to internalize company-specific business logic that cannot be expressed in a prompt.
How do I test a freight agent before going to production?
Start with Warp's free quote endpoints — they return real rate data without booking real freight or charging anything. Write test scenarios for common cases (standard LTL shipment, multi-stop route) and edge cases (no carriers available, all rates above threshold, booking failure). Measure the agent's decision quality against what a human would choose. When the agent is ready, swap the booking endpoint in and add the cost ceiling guardrail.
What guardrails should a freight agent have?
At minimum: a cost ceiling per shipment (require human approval above threshold), a carrier exclusion list, a maximum number of retries before escalating, rate limiting to prevent runaway API calls, and logging of every decision for audit. Start with tight guardrails and loosen them as you build confidence in the agent's judgment.
Start building your freight agent today.
Warp provides free quote endpoints, structured JSON, webhook events, and machine-readable documentation. Everything you need to build and test a freight agent before booking any real freight.