Multi-Agent Orchestration for Commerce: The Five-Stage Pipeline That Actually Ships Transactions

The problem

A single AI agent can answer questions, write code, and place simple orders. Commerce is none of those. Commerce is a chain of interdependent decisions: parse the user’s intent, find providers that can satisfy it, agree on price and terms, execute the transaction, verify completion. A monolithic agent attempting to do all five collapses under the first real-world edge case — the matcher returns no providers, the negotiator runs out of mandate, the fulfillment hits an idempotency conflict — and the agent has nowhere to recover because every concern is tangled.

The AI agent market projects from $7.84B in 2025 to $52.62B by 2030 (46.3% CAGR). Most of that growth is not better individual agents. It is multi-agent orchestration. Organizations using multi-agent architectures report 45% faster problem resolution and 60% more accurate outcomes than single-agent systems. The shift from monolith to chain is architectural, not incremental — the same separation-of-concerns pattern that converted backend monoliths into microservices.

This walks through what an actual production agent chain looks like for a commerce transaction: five specialized agents, the orchestrator pattern that coordinates them, the A2A protocol integration that gives the chain protocol compliance for free, and the error-handling patterns that keep money safe when any single agent fails.

What most people get wrong

Mistake one: building a single agent with a giant system prompt. The first instinct of most teams is to write one prompt that says “you are an autonomous commerce agent — find products, negotiate prices, process payments, verify delivery.” This works in a demo. It fails the moment a real provider responds with a counter-offer that contains a unit-price discrepancy versus the listed price, because the agent has no separation between “compare offers” and “validate offers against the cart total.” One slip in the conditional logic and the system authorizes a transaction it should have flagged.

The fix is mechanical. Split the chain into five agents, each with its own scope, its own input schema, and its own structured output. The interpretation agent does one thing: turn raw user text into a typed StructuredIntent. The matching agent does one thing: query providers and return a ranked ProviderCandidate[]. The negotiation agent does one thing: produce a signed Offer within the mandate envelope. Fulfillment executes. Verification confirms. The error surface shrinks because each agent has one job and one failure mode.

Mistake two: choosing mesh orchestration when hub-and-spoke is the right call. Mesh orchestration (agents talking peer-to-peer) is appealing — it’s resilient, low-latency, and reads as “modern.” For the critical commerce path it is the wrong choice. When real money moves, you need a single authoritative state machine, a single audit trail, and a single point of recovery on failure. That is hub-and-spoke. Mesh belongs on the supplementary paths — recommendation enrichment, analytics, notification fanout — where eventual consistency is acceptable and the cost of a lost message is a re-run, not a duplicate charge.

The decision criterion is simple: financial path, hub-and-spoke; auxiliary path, mesh. Get the two crossed and you discover the cost six months later when an audit reveals that three transactions completed but only two have receipts.

A working approach

The five-stage commerce pipeline maps directly to Google’s A2A protocol task lifecycle (submitted → working → input-required → completed). Aligning your chain with this state machine gives you protocol compliance and audit shape for free.

Stage	Agent	Responsibility
1	Interpretation	Parse natural language intent into structured constraints
2	Matching	Find providers that satisfy those constraints
3	Negotiation	Agree on price, terms, timeline with selected providers
4	Fulfillment	Execute the transaction and coordinate delivery
5	Verification	Confirm completion, collect feedback, update trust scores

The orchestrator that wires the five stages together is shorter than most teams expect. It mixes sequential execution (where one stage strictly depends on the previous) with parallel execution (where matching and initial negotiation can fan out across candidate providers):

interface AgentChainConfig {
  interpretation: InterpretationAgent;
  matching: MatchingAgent;
  negotiation: NegotiationAgent;
  fulfillment: FulfillmentAgent;
  verification: VerificationAgent;
}

async function executeWishChain(
  wish: RawWish,
  config: AgentChainConfig
): Promise<FulfillmentResult> {
  // Stage 1: Sequential — must complete before matching
  const structured = await config.interpretation.parse(wish);

  // Stage 2: Query providers in parallel
  const candidates = await config.matching.findProviders(structured);

  // Stage 3: Parallel negotiation across top candidates
  const offers = await Promise.all(
    candidates.slice(0, 5).map(candidate =>
      config.negotiation.negotiate(structured, candidate)
    )
  );

  // Stage 4: Sequential — execute the best offer
  const selected = selectBestOffer(offers);
  const result = await config.fulfillment.execute(structured, selected);

  // Stage 5: Sequential — verify and close
  const verified = await config.verification.confirm(result);
  return verified;
}

Each agent in the chain publishes an Agent Card — a JSON document declaring its capabilities, authentication scheme, and supported state transitions. The orchestrator discovers agents by reading their cards and routes tasks to the most capable one for each stage. This is what A2A integration actually looks like at the wire level:

const matchingAgentCard = {
  name: "wish-now-matching-agent",
  description: "Finds and ranks providers for wish fulfillment",
  url: "https://api.wish.now/a2a/matching",
  version: "1.0.0",
  capabilities: {
    streaming: true,
    pushNotifications: true,
    stateTransitions: [
      "submitted -> working",
      "working -> completed",
      "working -> failed"
    ]
  },
  authentication: {
    schemes: ["bearer"],
    credentials: "oauth2"
  },
  skills: [
    {
      id: "provider-matching",
      name: "Provider Matching",
      description: "Match wishes to optimal providers",
      inputModes: ["application/json"],
      outputModes: ["application/json"]
    }
  ]
};

The interpretation agent is short. Its only job is to convert a raw user wish into structured constraints — recipient, occasion, budget range, urgency, category preferences. The matching agent uses those constraints to query the three-tier provider system: tier 1 verified partners (A2A broadcast), tier 2 marketplace providers (database scan), tier 3 long-tail providers (federated search). The negotiation agent operates inside a mandate envelope — a cryptographically signed authorization defining the maximum spend, allowed categories, and expiration. It will never produce an offer outside the envelope, regardless of what the model proposes, because the mandate check runs server-side after the agent’s output.

The fulfillment agent is where the dual-protocol payment story matters. Every transaction must verify both classical signatures (ECDSA/HMAC) and quantum-safe signatures (ML-DSA-65) before money moves. The agent does not skip this. It cannot. The signature check is a tool call, the tool refuses on mismatch, and the agent’s only response is to escalate to the user. Verification closes the loop — confirms delivery, collects feedback, updates trust scores in the unified database for next time.

State management across the five stages is the part most teams underestimate. The orchestrator persists state after every transition so that any failure can be recovered from the last checkpoint:

State	A2A Status	Agent	Description
CREATED	submitted	—	Wish received, not yet parsed
PARSED	working	Interpretation	Structured intent extracted
MATCHED	working	Matching	Providers identified and ranked
NEGOTIATING	working	Negotiation	Offers being collected
AWAITING_APPROVAL	input-required	—	User confirmation needed
FULFILLING	working	Fulfillment	Payment + delivery in progress
VERIFIED	completed	Verification	Transaction closed

Where this scales

The article above is the spine. The book covers four more layers that turn the chain into a system that survives real traffic:

• Error handling and resilience — circuit breakers per agent, timeout management that propagates through the chain, fallback agent registries (if the primary matching agent fails, fall back to a slower but more accurate one), dead-letter queues for stages that can’t recover, and cost caps that prevent a runaway loop from burning through your token budget. The patterns are field-tested; the chapter has the TypeScript.
• Cost modeling and optimization — per-agent token costs, model selection per stage (use the cheap fast model for interpretation, the expensive smart model for negotiation), caching strategies for repeated intent patterns, the trade-off between combining agents and splitting them, and a monitoring dashboard that surfaces per-stage cost trends so you can spot regressions before they hit your invoice.
• The interpretation agent — natural language to structured intent is the foundation of the chain. The chapter covers constraint extraction patterns, handling ambiguity, multi-turn clarification flows, and the schema design that lets downstream agents consume the output without conditional logic.
• The negotiation agent — three strategies (first acceptable offer, competitive bidding, iterative counter-offers), mandate-based authorization at every layer, approval gates that escalate to the user when the offer exceeds an automated threshold, and the cryptographic plumbing that makes the offer itself a signed artifact.

The book is built around what survives production agent chains, not what compiles. Every code sample has been tested against real A2A endpoints and real LLM providers.

Included with the book

• agent-chain-design-template.md — a fill-in-the-blanks template for designing a new agent chain. Five sections matching the pipeline stages, with prompt scaffolds, input/output schemas, and a decision rubric for sequential-versus-parallel execution at each stage.
• TypeScript orchestrator skeleton — the chain executor pattern from the article above, plus error handling, state persistence, and A2A agent-card publishing — ready to drop into a Cloudflare Workers project.
• Five system prompts — the production prompts for interpretation, matching, negotiation, fulfillment, and verification agents, with the mandate-envelope plumbing already wired.

Get the full picture

Readers of this also chose

Questions readers ask

Do I need to use Google A2A — or can I run this on a custom protocol?

The chain pattern is protocol-agnostic. A2A gives you discoverability (agent cards), state machine compliance, and free interop with the fifty-plus vendors supporting the standard (Salesforce, SAP, PayPal, others). If you control both ends and don't need vendor interop, a custom JSON-RPC protocol works. The book's TypeScript code abstracts the transport so you can swap A2A for an internal RPC without touching the orchestrator logic.

How do I avoid runaway costs when one agent loops?

Cost caps are first-class in the orchestrator. Every chain execution carries a token budget and a wall-clock budget; either limit terminates the run with a structured failure that the caller can retry with a fresh budget. Chapter 7 covers the implementation, including per-agent cost attribution so you can identify which stage is responsible.

What model should I use for each agent?

The book has the trade-off matrix. Short version: a small fast model (Claude Haiku, Gemini Flash, GPT-4o-mini) for interpretation. A medium model for matching. The strongest reasoning model you can afford for negotiation. The same medium model for fulfillment. A small model for verification. The cost split lands around 5-20-55-15-5 across the five stages.

Does this work for non-commerce chains?

The five-stage pattern generalizes — interpret → discover → negotiate → execute → verify is a structure that appears in customer service triage, content production pipelines, and DevOps incident response. The book's code is commerce-flavored because the protocol requirements (mandates, dual-protocol signatures, idempotency) are most demanding there. Strip out the cryptographic plumbing and the chain works for any structured workflow.

What's the refund policy?

Lemon Squeezy's standard refund window applies. If the patterns don't fit your use case, the refund link is in the receipt email.