如何用 Claude 搭建 Amazon AI Agent：2026 完整架构指南

Claude is the right LLM for an Amazon AI agent. Its 200K-token standard context window (with a 1M-token beta tier) swallows entire search-term reports without chunking, its reasoning is sharp enough to actually catch the structural problems in a PPC account (not just the cosmetic ones), and its native tool-use makes wiring it into Amazon's Selling Partner API a clean engineering problem rather than a fragile prompt-chain. If you're a developer or a technical seller weighing whether to build your own agent versus buying one, this guide is the honest map of the territory. The first 80% comes together in a weekend and feels magical. The last 20% — the part that turns a demo into something you can actually run a business on — takes months and routinely breaks the people who try. You'll get the four-layer architecture I'd actually build, the specific APIs you'll need, the costs nobody publishes, the edge cases that take six months to discover, and an honest comparison against using something that's already built. By the end you'll know exactly what a production Claude-powered Amazon agent costs, what it can do, and whether you should write the code yourself. ## What You're Actually Building An "Amazon AI agent" sounds like one thing. In practice it's four layers stacked on top of each other, and each layer has its own failure modes. ### Layer 1: The LLM Layer (Claude) This is the brain. It handles reasoning, natural-language interaction, summarization, and judgment calls — "this campaign is structurally broken because three keywords are absorbing 70% of spend at 4% conversion." You'll use the Anthropic Messages API and lean heavily on tool use (also called function calling) so Claude can actually call your Amazon integrations rather than just talk about them. Model selection matters more than most people realize: • Claude Sonnet is the sweet spot for Amazon work. Strong reasoning on multi-step PPC analysis, fast enough for real-time chat, priced reasonably even on large search-term reports. • Claude Opus is overkill for routine tasks but earns its cost on the hardest work: drafting a Plan of Action for a complex account suspension, or reasoning across an entire ASIN catalog plus uploaded supplier contracts and customs documents. • Claude Haiku is cheap and fast but produces subtly wrong PPC recommendations often enough that you'll regret using it for anything important. Reserve it for cheap classification tasks — not for bid decisions. ### Layer 2: The Data Layer (Amazon's APIs) This is where the work lives. To build an agent that can actually run an Amazon business, you need: • Amazon Selling Partner API (SP-API) for orders, inventory, catalog, financial events, performance notifications, account health, and the dozens of report types Amazon makes you poll for. • Amazon Advertising API for Sponsored Products, Sponsored Brands, and Sponsored Display campaigns, plus the search-term reports and keyword data that any serious PPC agent needs. • The Solicitations API if you want to send review requests programmatically — the only Amazon-ToS-compliant way to do this at scale. • Third-party data sources depending on scope: Keepa for price history and BSR tracking, SmartScout or Jungle Scout for market intelligence, and currency/freight rate APIs if you're modeling international margins. Every one of these returns data in a different shape, on a different cadence, with different authentication, and different rate limits. None of them documents their edge cases honestly. ### Layer 3: The Orchestration Layer This is the glue, and it's where most DIY projects quietly die. Something has to manage: • Authentication. OAuth refresh tokens expire. Sometimes Amazon's auth server is slow and your refresh fails silently. SP-API uses Login with Amazon, the Ads API uses a separate OAuth flow, and the tokens for each have different lifetimes. • Rate limiting. SP-API uses per-endpoint token-bucket limits, and your account's usage tier affects the burst capacity. The Ads API uses a different scheme. You'll hit 429 errors regularly and you need a back-off strategy that doesn't just crash. • Report polling. Most SP-API data doesn't come from a single GET — it comes from a report request workflow: you ask for a report, wait for it to generate (anywhere from 30 seconds to 30 minutes), download the document, decompress it, and parse it. You need an async job queue, retry logic, and state management. • Data normalization. The same ASIN can have different attributes in different endpoints. Dates come back in mixed formats. PPC reports nest campaigns inside ad groups inside keywords with different date-range semantics at each level. • Memory. Claude doesn't remember between API calls. If you want a conversation that holds context across multiple turns, you're managing that state yourself. • Retrieval (RAG). When the seller has uploaded supplier contracts, freight forwarder quotes, or product liability docs, you need a vector store (pgvector or Pinecone) and a retrieval layer so Claude can ground its answers in those documents. ### Layer 4: The Action Layer The point of an agent is that it doesn't just analyze — it does things. That means writing back to Amazon and the seller's stack: adjusting PPC bids, adding negative keywords, launching campaigns, generating PDFs and PPTX decks, sending Slack alerts, updating Google Sheets, drafting customer responses, building reimbursement claim packages. Each action is its own integration. Each is one more thing that can fail. Each needs its own audit trail because "the AI changed my bids" is not a sentence anyone wants to hear without a log to back it up. A clean mental model of the full stack: That's the whole architecture. The first time you draw it, it looks tractable. It is — for 80% of it. ## Getting Started: The First 80% Is Genuinely Easy The encouraging part: a working prototype takes a weekend. Here's the path. ### Step 1: SP-API Access Register as an Amazon developer, create an app in Seller Central, and complete the developer profile. Generate your LWA (Login with Amazon) credentials, get your refresh token via the OAuth flow, and you can pull data. Plan about an hour to navigate the developer portal the first time — Amazon's docs are correct but unfriendly. ### Step 2: A First Tool Definition Write a function that pulls last-7-day sales data using the getOrders endpoint (or the Sales & Traffic report if you want item-level detail), format the result as clean JSON, and register it as a Claude tool. The tool definition looks like this: ### Step 3: Your First Real Question Ask Claude: "What were my top five products by revenue last week, and is anything trending down?" Claude calls your tool, parses the JSON, identifies the trend, and gives you a real analysis. The first time this works, it feels like you've cracked the code. ### Step 4: Add a Second Tool Pull live PPC data using the Advertising API. Now Claude can correlate: "Your top revenue ASIN is at 28% ACoS, which is fine, but your second-top is at 51% — your ads are eating the margin on that one." This is where most builders post the screenshot on LinkedIn and say "Why would anyone pay for an Amazon tool when I built this in a weekend?" The answer is in the next section. ## Then You Hit the Last 20% ### Week 2: The Token Refresh Problem Your SP-API refresh token expires at 2 a.m. on a Tuesday. Your agent silently stops working. You don't notice until Wednesday morning when you ask for a report and get a stale answer. You add refresh logic. It works, mostly — except when Amazon's auth server returns a 5xx during the refresh window, your retry logic doesn't kick in fast enough, and the agent goes offline for six hours before your monitoring catches it. (You don't have monitoring yet. You'll build that in week 4.) ### Week 3: The Advertising API Returns Nested Hell You try to pull PPC data. Amazon's Advertising API returns campaigns with ad groups with keywords with search terms — four levels deep, each with different date-range behavior. Some endpoints return data inline; others require you to request a report, poll for completion, download a gzipped file, and parse it. Campaigns with quotes or special characters in the name break your JSON parsing. You spend a Saturday writing a state machine for report polling and a normalizer for campaign names with apostrophes in them. ### Month 2: Reimbursements (The One Nobody Warns You About) You decide your agent should automatically detect reimbursable units — lost FBA inventory, damaged warehouse stock, fee overcharges. This is one of the highest-value features for any Amazon seller and one of the hardest to build correctly. Detecting a single reimbursement-eligible event requires cross-referencing at least six different report types: inventory adjustments, inbound shipment receipts, customer returns, FBA inventory ledger, fee preview reports, and reconciled financial events. The logic for "this unit was misplaced and not reimbursed within Amazon's 60-day window" requires matching an M (misplaced) event to its corresponding P (found) event, P event to a reimbursement record, and applying Amazon's evolving reimbursement policy windows (which changed materially in 2024 and again in early 2026). Get the logic wrong and you flag false positives, the seller submits bogus claims, Amazon flags the account, and you've made things worse. Get it right and the seller recovers 1–3% of revenue they otherwise would have lost forever. There's no shortcut here — just hundreds of hours of edge-case work against Amazon's reporting reality. ### Month 3: The Silent API Change Amazon deprecates an Advertising API endpoint without warning. Your PPC reports stop flowing. You don't notice for three days because you don't have proper data-freshness monitoring — the agent kept "working," it just had stale data. By the time you fix it, your agent has been making bid recommendations against last-week's numbers. You add data-freshness checks to every integration. You wish you'd done it from day one. ### Month 4: Rate Limiting Is Actually Hard The SP-API rate-limit story is much more complex than the docs suggest. Different endpoints have different limits. Your "usage plan" tier (which Amazon assigns based on account history) caps burst capacity. The Reports endpoint has different throttling than the Catalog endpoint, which is different from the Orders endpoint. Without a per-endpoint token-bucket implementation and graceful exponential back-off, your agent crashes with 429 errors during high-volume periods — which, ironically, are exactly when you need it most. ### Month 5: It Worked for Your Account A friend asks if they can use it for theirs. Their account is in a different marketplace (UK instead of US), with different product categories, different PPC structures, more FBM orders than FBA, and a much larger catalog. Suddenly you're dealing with currency conversion, marketplace ID handling, category-specific keyword normalization, and edge cases your code never imagined. The "general-purpose Amazon agent" is an order of magnitude harder than the "my specific account" agent. ### Month 6: Account Health and Compliance You realize the agent should also monitor Account Health, parse performance notifications, and surface compliance issues before they become suspensions. You start building POA support. You discover Amazon's deactivation system has its own quirks: notifications arrive in unstructured prose, the appeal portal accepts different formats depending on the violation type, and the line between a warning and a full suspension is rarely clear. Drafting a POA that actually gets accepted requires domain knowledge that took years to acquire — and Claude can do it in 60 seconds only if you've structured the prompt with the right framing, the right examples, and the right document templates. Building that prompt library is its own multi-week project. ## The Costs Nobody Publishes Beyond engineering time, here's what running a serious Claude-powered Amazon agent actually costs: [Hard total: $200–$500/month in recurring costs, plus 5–10 hours/month of maintenance. For something that handles roughly 60–70% of what a production Amazon platform does, against a single account.] ## SellerForge: Everything Above, Already Built Status, checked September 25, 2026: some of those modules are held back while SellerForge verifies the underlying data. Amazon Ads performance ratios, waste review, and bid or budget changes are paused while Amazon Ads data is verified; the Profit & Loss view and deliverable generation are temporarily withheld; and reimbursement detection flags potential discrepancies for your review (estimated, not confirmed as owed) rather than preparing claims. An illustrative example of one conversation (the account and figures are made up): The thing the demos never show: every recommendation is traceable to the underlying data. When SellerForge says "B0BFR4 lost revenue because of a new competitor," you can click through to the Keepa price history, the Buy Box win-rate data, and the timestamp of when the competitor appeared. Build that traceability layer yourself and you've added another month of work. ## Build vs. Buy: The Honest Math ## When Building Your Own Still Makes Sense Despite all of the above, building your own Claude-powered Amazon agent is a legitimate choice in three scenarios: If you're going to build anyway, here's what I'd tell you: • Start with Claude Sonnet, not Haiku. The quality difference on Amazon data analysis is meaningful and worth the cost. • Build rate limiting from day one. Per-endpoint token buckets, exponential back-off, and the assumption that Amazon will throttle you when it matters most. • Use prompt caching aggressively. Anthropic's prompt caching can cut your Claude API spend by 40–60% on repeated workflows. Set up cache breakpoints at the system prompt level immediately. • Use a message queue. Don't try to call Amazon's APIs synchronously from your web app. A proper job queue with idempotent handlers is essential for anything beyond a prototype. • Build data-freshness monitoring. The worst failures are the silent ones — the agent that keeps "working" but with stale data. Every integration should report when it last successfully ingested, and you should alert on staleness, not just errors. • Monitor your Anthropic API spend weekly. It's easy to introduce a regression that doubles your token usage. • Build the reimbursement module last. It's the highest-value feature and the easiest one to get wrong. Wait until you have rock-solid data infrastructure before attempting it.