# AI Procurement Automation: From Purchase Request to Delivery

URL: https://firestarter.network/blog/ai-procurement-automation
Published: 2026-06-11
Author: Victor Young

AI procurement automation covers the full B2B buying lifecycle—RFQ, quote comparison, approval, PO, and delivery. Here's how a real agent handles it end to end.

AI procurement automation means an agent handles the full buying lifecycle—from interpreting a purchase request to confirming delivery—without a human doing the manual steps in between. Most tools marketed as "AI procurement" only handle intake: they help someone fill out a purchase request form or route an approval. The harder problem is executing the purchase itself: finding suppliers, comparing quotes, managing approval, releasing payment, and tracking delivery. This post walks through how that works end to end, using a real scenario as the thread.

## What B2B Procurement Actually Involves

A standard B2B procurement cycle has seven stages, each of which has historically required human coordination:

1. **Purchase request** — Someone identifies a need and submits a request with quantity, specs, and delivery constraints.
2. **RFQ (request for quotation)** — The procurement team reaches out to approved suppliers for pricing.
3. **Quote comparison** — Quotes come back at different prices, lead times, and terms. Someone compares them.
4. **Approval** — The order is reviewed against policy (budget, supplier approval, category rules) and signed off.
5. **Purchase order** — A PO is issued to the selected supplier.
6. **Delivery** — Goods ship and are received at the destination.
7. **Invoice reconciliation** — The invoice is matched to the PO and the receipt, then paid.

The failure mode in most "AI procurement" tools is covering step 1 (intake) and sometimes step 4 (routing an approval), but leaving steps 2, 3, 5, 6, and 7 to manual processes. The result is a faster form, not a faster procurement cycle.

A commerce execution API like Firestarter handles the full cycle programmatically. For background on what that means architecturally, see [what is a commerce execution API](/what-is-commerce-execution-api) and how it compares to [Zip and traditional procurement tools](/compare/firestarter-vs-zip).

## A Real Scenario: 500 Kraft Mailer Boxes for Austin TX

Here is the scenario: a logistics operations agent receives a request to stock 500 kraft mailer boxes (10×8×4 inches) for a warehouse in Austin, TX. Delivery is needed within one week. The budget is $250 all-in.

This is a realistic B2B procurement task. The agent needs to find packaging suppliers who sell in bulk, get accurate pricing including freight to Texas, compare options, get approval from the warehouse ops contact, and release payment only after committing to delivery by the required date.

### Step 1: Intent Parsing

The agent posts the request to Firestarter:

```bash
curl -X POST https://api.firestarter.network/v1/executions \
  -H "Authorization: Bearer fs_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "request": "500 kraft mailer boxes 10x8x4 for our Austin TX warehouse, need by June 18",
    "budget": {
      "max_total": 250
    },
    "approval": {
      "required": true,
      "notify": ["warehouse-ops@example.com"]
    }
  }'
```

The execution engine parses this into structured parameters: product category (corrugated packaging), dimensions, quantity, delivery location (Austin TX zip code), deadline (June 18), and maximum total landed cost ($250). The parsed intent is recorded in the execution log—useful later if there is any question about what the agent was asked to find.

### Step 2: Supplier Search and RFQ

The agent searches Firestarter's supplier network, which includes Uline, Amazon Business, and regional packaging distributors. For each supplier, it queries pricing for the specified product at the requested quantity, including freight to the destination zip code.

This is where volume pricing enters. Many packaging suppliers have price breaks at 500 units versus 100 units versus 1,000 units. The execution engine accounts for this: it fetches the applicable bulk price tier for 500 units, not the single-unit list price. The [kraft mailer boxes scenario page](/scenarios/kraft-mailer-boxes-austin) shows the actual pricing structure the agent encounters.

All supplier queries are logged against the execution, satisfying the [audit trail requirement](/blog/ai-agent-audit-trails) for what was searched and who was contacted.

### Step 3: Quote Comparison

The execution engine scores and ranks options against the constraints: total landed cost under $250, delivery to Austin TX by June 18. Options that fail either constraint are filtered out. The remaining options are ranked by a combination of price, lead time, and supplier reliability score.

A typical comparison result at this stage:

```json
{
  "status": "pending_approval",
  "options": [
    {
      "rank": 1,
      "supplier": "PackagingDirect",
      "product": "Kraft Mailer 10x8x4 — 500ct case",
      "unit_price": 0.38,
      "freight": 14.50,
      "tax": 0,
      "total_landed": 204.50,
      "estimated_delivery": "2026-06-17",
      "in_budget": true
    },
    {
      "rank": 2,
      "supplier": "Uline",
      "product": "S-21234 Corrugated Mailer — case of 500",
      "unit_price": 0.41,
      "freight": 18.75,
      "tax": 0,
      "total_landed": 223.75,
      "estimated_delivery": "2026-06-16",
      "in_budget": true
    }
  ]
}
```

Both options are within budget and meet the delivery deadline. The faster option costs slightly more; the cheaper option arrives one day later. This is exactly the tradeoff a human approver needs to see.

### Step 4: Approval

The execution holds at `pending_approval` and notifies `warehouse-ops@example.com`. The approver sees the two options with full cost breakdowns and delivery dates. They approve the rank-1 option:

```bash
curl -X POST https://api.firestarter.network/v1/executions/exec_01HXYZ789/approve \
  -H "Authorization: Bearer fs_live_YOUR_KEY" \
  -d '{
    "selected_option_rank": 1,
    "approved_by": "sarah@example.com"
  }'
```

The approval event—including the approver's identity and the selected option—is written to the audit log. See [human-in-the-loop approval workflows](/blog/human-in-the-loop-ai-purchases) for the full approval pattern, including how to handle rejection and re-sourcing.

### Step 5: Payment and Escrow

After approval, Firestarter processes payment via Stripe. The $204.50 is authorized and held in escrow. Funds are not captured—the charge does not finalize—until delivery is confirmed. If the supplier cannot fulfill the order, the authorization is released and no charge appears.

This is a meaningful protection for B2B buyers. Traditional procurement cycles often require payment at order time with disputes handled through a returns process. Escrow-backed payment means the financial risk is contingent on delivery.

### Step 6: Shipping and Tracking

Firestarter generates a shipping label via EasyPost and instructs the supplier to use it. From this point, tracking is automated: the execution status updates as the carrier scans the package at each stage. The requester and the approver can check status via `GET /v1/executions/:id` at any time without calling a supplier or logging into a carrier portal.

### Step 7: Delivery Confirmation

When the carrier records a delivery scan at the Austin warehouse, the execution advances to `delivered` and the escrow is released. The execution record—now complete—includes every step from intent to delivery, with timestamps, amounts, and attribution throughout.

## Scaling to More Complex B2B Purchases

The kraft mailer scenario is a straightforward single-supplier order. B2B procurement gets more complex at higher values and with more stakeholders. The [ergonomic desk chairs scenario](/scenarios/ergonomic-desk-chairs) walks through a $15,000 purchase of 50 chairs with net-30 payment terms, BIFMA compliance requirements, and freight delivery—a scenario where the agent needs to issue RFQs to three suppliers, compare terms (not just price), and route to a more senior approver.

The same Firestarter API handles this. The difference is in the request parameters—a higher `max_total`, additional preference fields for compliance certification and payment terms—and in the approval configuration, which routes to a procurement manager rather than a warehouse ops contact.

For organizations building reusable agent workflows, the [developer docs](/developers) cover how to parameterize execution templates so the same workflow handles both a $200 packaging order and a $15,000 furniture purchase.

## What Most AI Procurement Tools Miss

The dominant category of "AI procurement" software—tools like intake automation and approval routing—solves the intake and routing problem. That is genuinely useful. But it leaves the agent dependent on a human to actually execute: to search suppliers, compare quotes, and place the order.

A commerce execution API closes that gap. The agent does not hand off to a human at the search stage; it completes the search, comparison, and execution programmatically, with human involvement only at the approval gate.

The other gap is fulfillment accountability. Most procurement tools issue a PO and stop. Firestarter's lifecycle continues through shipping, tracking, and delivery confirmation—so the agent can report back "the order arrived at 10:43am on June 17" rather than "the order was placed."

See [/use-cases/agent-action-api](/use-cases/agent-action-api) for more on how Firestarter fits into agentic procurement architectures, and the [OpenAPI spec](/openapi) for the full endpoint reference.

---

## FAQ

### What supplier network does Firestarter search for B2B orders?

Firestarter is a two-sided network: sellers list their catalogs and the execution engine searches available suppliers for each request. Supplier coverage varies by category. For packaging, office supplies, and business equipment, multiple suppliers are typically available. The [scenarios pages](/scenarios/kraft-mailer-boxes-austin) document typical supplier availability for common B2B categories.

### Can Firestarter handle orders that require net-30 or other payment terms?

Payment terms are expressed as preferences in the execution request. Firestarter surfaces suppliers who offer the requested terms in the options comparison. Whether a specific supplier's terms are available depends on that supplier's catalog configuration. The [ergonomic desk chairs scenario](/scenarios/ergonomic-desk-chairs) walks through a net-30 terms request in detail.

### How does Firestarter handle freight for large B2B orders?

Freight is included in the total landed cost calculation for every option. For large orders that require LTL or full-truckload freight rather than parcel shipping, the execution engine selects the appropriate shipping method and includes the freight cost in the comparison. The `max_total` budget applies to the full freight-inclusive cost.

### Can I integrate Firestarter with an existing procurement system?

Yes. Firestarter exposes a standard REST API and an [OpenAPI 3.1 spec](/openapi). You can call it from any system that can make HTTP requests. Common integrations include ERP systems, procurement platforms, and agent frameworks using the [MCP integration](/mcp) or direct API calls. The [developer docs](/developers) cover integration patterns.

### What does Firestarter cost for B2B procurement?

Each execution consumes one token regardless of order size. [Free tier: 100 tokens to start plus a 14-day Pro trial, no credit card required.](/pricing) Pro is $99/month with 10,000 tokens. Buyers pay no transaction fees. Sellers list free and pay a 3% commission on completed sales only.