How AI Agents Work
An AI agent is a language model connected to tools, running in a loop. The model reasons about what to do next. The tools let it take action in the real world. The loop continues until the goal is met. This page explains the mechanics: how the agentic loop works, how tool use operates, how memory persists across steps, and how these concepts apply to building agents that interact with freight APIs.
The agentic loop
Every AI agent runs the same fundamental loop. Understanding this loop is the key to understanding how agents work, regardless of domain or architecture.
Step 1: Observe
Gather context.
The agent receives the current state: the user goal, results from previous tool calls, error messages, new data from webhooks or events. All of this goes into the model context window. The agent now has a picture of where it stands.
Step 2: Reason
Decide the next action.
The language model processes the context and decides what to do next. This is where the model applies its training: understanding the domain, evaluating options, considering constraints. The output is either a tool call (an action to take) or a final response (the task is done).
Step 3: Act
Execute the tool call.
The runtime executes the tool call: makes an API request, reads a file, runs a command, queries a database. The tool returns a result. This result becomes new context for the next iteration of the loop.
The loop repeats: observe the tool result, reason about the next step, act again. It continues until the agent determines the goal is met, encounters a situation that requires human input, or hits a safety limit (maximum iterations, cost threshold, time limit). The simplicity of this loop is what makes agents so versatile. The same pattern handles bug fixes, freight procurement, data analysis, and customer support.
How tool use works
Tools are what give agents their power. Without tools, a language model can only generate text. With tools, it can interact with the real world.
Tool definition
Structured schema.
Each tool is defined by a schema: its name, a description of what it does, and the parameters it accepts (with types and descriptions). The language model uses this schema to decide when and how to call the tool. A well-written tool description is as important as the tool implementation itself.
Tool call
Structured function call.
When the model decides to use a tool, it generates a structured JSON object: the tool name and its parameters. The runtime parses this, validates the parameters against the schema, and executes the tool. The model never executes code directly. The runtime mediates every interaction.
Tool result
Back into context.
The tool returns its result (success or error) as structured data. This result is added to the conversation context. The model now reasons about the result: did the action succeed? What should happen next? This observation step closes the loop and starts the next iteration.
Freight API endpoints as agent tools
In a freight agent, the Warp API endpoints become the tools. Each endpoint maps to a capability the agent can use.
Quote tool
POST /freights/quote
The agent sends origin, destination, items, and pickup date. The API returns structured rate options with carrier names, costs, transit times, and quote IDs. The agent evaluates these options against business rules and selects the best one. This single tool call replaces logging into multiple carrier portals.
Book tool
POST /freights/booking
The agent passes the selected quote ID. The API returns a shipment ID, tracking number, and order ID. The agent updates internal systems with the booking confirmation. One tool call replaces phone calls, emails, and portal submissions.
Track tool
Webhook events
Tracking is event-driven, not tool-driven. The agent registers a webhook URL and receives events as the shipment moves: pickup, transit, cross dock, delivery. Each event becomes new context. The agent monitors for exceptions and acts on them using other tools.
Memory: how agents retain and use information
Working memory
The conversation context.
Everything the agent has seen in the current session: the original goal, tool calls and their results, errors encountered, intermediate decisions. This is the context window of the language model. It has a fixed size, so agents must be strategic about what information to retain.
Persistent memory
Files, databases, vector stores.
Information that persists across sessions. A freight agent might store carrier performance data in a database, lane-specific preferences in a configuration file, and historical rate benchmarks in a vector store for retrieval. Persistent memory is what makes agents improve over time.
Retrieval
Pull relevant context on demand.
When an agent encounters a new task, it retrieves relevant information from persistent memory. Shipping to Phoenix? Pull the carrier performance history for that lane. Booking with Carrier X? Pull the last 10 shipments with them. Retrieval augments the working memory with relevant historical data.
Guardrails and safety
Autonomous agents need guardrails. In freight, this means cost limits (do not book above a threshold without human approval), carrier restrictions (never book with a carrier on the exclusion list), scope limits (handle quoting and booking but escalate claims to a human), and iteration limits (stop after N tool calls and report status). Guardrails are what make the difference between a useful agent and a liability. They define the boundary of autonomous action.
Frequently asked questions
What is the agentic loop?
The agentic loop is the core execution pattern of an AI agent. The agent receives a goal, reasons about what action to take, executes the action using a tool (API call, file edit, shell command), observes the result, and decides whether to continue or stop. This loop repeats until the goal is achieved or the agent determines it needs human input. The loop is what makes agents autonomous rather than single-shot.
What is tool use in AI agents?
Tool use is how agents interact with the real world. The language model generates a structured function call (a JSON object specifying the tool name and parameters), the runtime executes the tool, and the result is returned to the model as context for the next reasoning step. Tools can be APIs, file operations, shell commands, database queries, or browser interactions. Without tools, an agent is just a chatbot.
What is the ReAct pattern?
ReAct (Reason + Act) is the most common agent architecture. The agent alternates between reasoning steps (thinking about what to do) and action steps (calling a tool). Each reasoning step produces a thought about the current state and what should happen next. Each action step executes a tool call. The cycle repeats until the task is complete. This interleaving produces more reliable behavior than pure reasoning or pure action.
How do agents handle errors?
When a tool call returns an error, the agent treats it as new information. It reads the error message, reasons about what went wrong, and decides on a corrective action: retry with different parameters, try a different tool, or adjust the overall approach. This error-handling capability is built into the agentic loop itself. There is no separate error-handling code. The agent reasons about errors the same way it reasons about any other observation.
How does this apply to freight APIs?
A freight agent uses Warp's API as its primary toolset. The quoting endpoint is one tool, the booking endpoint is another, webhooks provide observation data, and the invoice endpoint enables settlement. The agent's agentic loop becomes: receive a shipping request, call the quote tool, reason about the best option, call the booking tool, monitor webhook events, handle exceptions by calling tools again. The freight API is the tool layer that gives the agent its capabilities.
Build agents on freight infrastructure that works.
Warp's API is designed as an agent tool layer. Structured JSON responses, explicit field names, full lifecycle coverage, real-time webhooks. Everything an agent needs to operate autonomously.