Cross-border ecommerce AI agents from zero: support, sourcing, ads, orders, and after-sales

Cross-border teams rarely lack a ChatGPT login—they suffer from five half-automated lanes: support copy-paste in the helpdesk, sourcing in spreadsheets, ad buyers watching ROAS, warehouses exporting orders from ERP, and after-sales bouncing between email and marketplace tickets. Wiring those pieces with AI Agents into one auditable pipeline comes down to three things: a unified event bus (orders, messages, and ad metrics become events), domain agents with explicit tool permissions, and human approval gates (refunds, repricing, delists, large budget moves).

Below is a zero-to-production order: architecture and data contracts first, then five agents (support, sourcing, ads, orders, after-sales), then orchestration, observability, and compliance. Examples assume Shopify + Amazon Seller + Meta/Google Ads; self-hosted stacks can use webhooks, queues, and any LLM API. If your agent gateway needs a 24/7 daemon, run orchestration workers on a fixed-region Cloud Mac for cron and local scripts while business APIs stay on official platform endpoints.

Architecture: event bus, orchestrator, tools

Do not stuff every API into one “super agent.” Maintainable design is thin orchestration, thick tools:

• Event bus: Kafka, Redis Streams, SQS, or a Postgres outbox table. Normalize inbound traffic to JSON Schema events such as order.created, ticket.opened, ads.campaign.overspend.
• Orchestrator: route by event type to agent workers; keep an order-level state machine (awaiting reply → awaiting ship → exception → closed).
• Domain agents: each agent only gets tools for its domain (support reads KB, orders read WMS); share a read-only customer profile view.
• Approval queue: refunds, repricing, delists, budget above threshold go to pending_approvals; Slack/Feishu cards must be approved before execution.

Data and credentials: nail down single source of truth

When agents hallucinate policies, data is usually forked. Before launch, align at least:

1. Product master: SKU, variants, customs declaration fields, embargo countries—ERP or PIM is authoritative; storefront admin is read-only sync.
2. Order state: marketplace order ID ↔ internal order_id ↔ tracking number needs a mapping table; agents query only through that layer.
3. Customer timeline: email, onsite messages, WhatsApp, marketplace messages under one customer_id.
4. Secret custody: Shopify Admin API, Amazon SP-API, Meta Marketing API tokens in Vault/KMS; agents exchange short-lived credentials at runtime—never embed in prompts.

Support agent: channels, intents, KB, escalation

Inputs: webhooks from Gorgias, Zendesk, Shopify Inbox, Amazon Buyer-Seller Messaging. Tools: policy KB (return window, warranty), order tracking lookup, ticket notes. Policy:

• Intent taxonomy: tracking / missing item / quality / cancel order / review threat—each intent binds an action whitelist.
• Versioned RAG KB: bump version on policy change so old threads do not mix rules.
• Low confidence or heated tone → escalate_to_human with order facts the agent already fetched.

Reply language follows the buyer’s storefront locale; use one structured intent model across languages, not one agent per language.

Sourcing agent: signals, scoring, human pool

The sourcing agent does not “approve listings”—it compresses information into a decision card from trend, competitor price, margin, and compliance risk.

• Signals: marketplace trends, third-party sales estimates, ad library creatives, basic patent/trademark search (legal still signs off).
• Scoring: rules + LLM summary; output score, risks[], suggested_moq.
• Human pool: scores above threshold go to a “buying committee” board; agent drafts competitor tables, never auto-creates POs.

Ads agent: creative, bids, circuit breakers

Ads burn cash fastest. Agent permissions should be read-heavy, write-light:

• Read-only monitoring: hourly campaign spend, CTR, ROAS; spikes or CTR cliffs emit ads.anomaly.
• Recommendation mode: cards for “cut budget / swap creative / broaden audience”—default no auto budget edits.
• Auto mode (optional): only when ROAS > target and spend < daily cap, allow ±5% budget nudges; increases still need approval.
• Run creative copy as a separate step: three headline + primary text sets; humans pick one before Meta/Google upload.

Orders agent: fulfillment, exceptions, reconciliation

The orders agent listens to order.paid, inventory.low, shipment.exception:

1. Validate address (postal code, remote surcharges), blocklists, duplicate orders.
2. Route warehouse by stock, SLA, inbound cost; stockouts trigger split shipments or support agent notifies buyer.
3. Write tracking back to storefront and marketplace; exceptions open after-sales prep tickets.
4. End-of-day reconciliation: marketplace settlement ↔ payment gateway ↔ ERP AR; alert when variance exceeds threshold.

After-sales agent: RMA, refunds, disputes

After-sales shares the customer timeline with support but tools are more sensitive:

• RMA: check return window, opened package, cross-border return path—output approve_rma suggestion; execution needs approval.
• Refunds: partial / full / shipping tiers in a policy table; agent only proposes amounts.
• Marketplace disputes: Amazon A-to-z, PayPal disputes—agent assembles evidence (delivery proof, chat logs, policy screenshots); humans submit.

Orchestration: n8n, custom FSM, agent frameworks

Suggested path: week 1 wire n8n for “new ticket → lookup order → draft reply”; weeks 2–3 move order state machine into code; week 4 add read-only ad monitoring.

Observability, cost, security baseline

• Tracing: every agent call logs trace_id, model, tokens, tool name, whether approval fired.
• Replay: store input events + structured outputs to prove “answered per policy” in disputes.
• Cost: small model for support classification, large model only for drafts; batch sourcing/ad digests.
• Compliance: GDPR/personal data minimization in prompts; marketplace rules ban fake reviews and rank manipulation—action whitelists must be lawyer-readable.

Four-week rollout

1. Week 1: event schemas + order/customer mappings; support agent read-only lookup + draft replies (human send).
2. Week 2: orders agent auto warehouse route + tracking write-back; exceptions escalate to after-sales prep.
3. Week 3: sourcing daily digest + ad anomaly alerts; approvals on Slack/Feishu.
4. Week 4: after-sales RMA suggestions + reconciliation alerts; full-chain trace and weekly ROAS/CSAT report.

FAQ

Structured FAQ is in page JSON-LD. Summary topics: one agent for everything?, shared Shopify/Amazon support?, fully automated ads?, prompt injection, where to run orchestration workers.