Designing Industrial-Grade Cross-Border E-Commerce AI Customer Service Agents: The Skills+Workflow Architecture

Project Background: Why Cross-Border Customer Service Needs Agents

Cross-border e-commerce customer service faces four simultaneous pressures: time-zone gaps between users and domestic teams, multi-team collaboration across in-house and outsourced staff, complex business actions (refunds, returns, cancellations, address changes) that mutate order state, and high per-ticket costs for overseas agents. These tickets are repetitive but automation is constrained by risk boundaries — a single wrong refund, cancellation, or address change causes direct loss and new after-sales issues. The project goal is controllable processing, stable collaboration, and sustainable operations, not just a Q&A bot.

Business Positioning and Core Capabilities

The agent is defined as a controllable decision-and-execution system embedded in the service platform. It must: (1) understand user intent, (2) read current business state, (3) judge against preset rules, (4) trigger allowed processes within permission boundaries, and (5) record the full handling chain. The core value lies in organizing dialogue into a governable business processing chain, not merely answering questions.

Ticket Classification: Four Types Drive Architecture

Tickets are split into four categories, each dictating system dependencies, automation approach, and risk control intensity:

Answer (policy, sizing, promotions, care) — knowledge retrieval + NLG, low risk.

Query (order status, logistics, refund progress) — read-only system calls, medium risk.

Judgment (timeout eligibility, refund eligibility, cancellation eligibility) — real-time state + rules + context, high risk.

Execution (address change, initiate refund, cancel order, intercept parcel) — write to business systems, highest risk.

This classification lets the team configure different model permissions, system permissions, confirmation steps, and human fallback per type. Answer-type suits high automation; execution-type demands confirmation, review, idempotency, and audit first.

Five Required Capabilities

Intent Recognition — combine current query with context to distinguish consultation, query, judgment, execution.

Rule Understanding — know processable conditions, prohibitions, exceptions, and human-intervention standards; prevent model from hallucinating business rules.

System Invocation — query order, logistics, refund real-time state so every judgment has data backing.

Risk Control — user confirmation, human review, permission checks, duplicate-submission protection, exception fallback for sensitive actions.

Operational Loop — persist results, failure reasons, human feedback, rule hits to enable continuous optimization and capability expansion.

These five map to five architectural layers, each independently evolvable and testable.

Core Architecture: Skill + Workflow Dual Layer

The scenario demands both model understanding and stable business control. The design separates concerns:

Skill Layer : understands intent, completes context, interprets rules, judges processing path. Outputs structured intent, key facts, risk level, suggested action. Governance focuses on prompt/rule versions, confidence, citation.

Workflow Layer : orchestrates steps, validates permissions, calls systems, controls state. Outputs execution status, system results, exceptions, audit logs. Governance focuses on confirmation/review, idempotency, retry, timeout, rollback, human takeover.

Handoff uses structured contracts: Skill emits intent, facts, evidence, risk, next-step suggestion; Workflow only accepts contract-compliant results and advances per predefined permissions. This prevents model free-wheeling from affecting production flows. Write operations are locked inside Workflow, not left to model self-discipline.

End-to-End Example: Address Modification (9 Steps)

Identify intent & context — confirm target order, check dialogue for order clues.

Query order state — existence, payment, shipment, current fulfillment node.

Judge modification conditions — based on state and business rules.

Collect new address — validate country, province, city, zip, street, contact, phone completeness.

Verify fulfillment reachability — call logistics/address validation, confirm serviceability, identify extra costs.

Request user confirmation — show proposed changes and impacts, obtain explicit consent.

Execute or escalate — low risk & permitted: call system; high risk, rule conflict, or missing info: hand to human.

Write back & notify — log operator, inputs, rule version, system result, exceptions; inform user of final state.

Design rule: Skill judges "whether conditions allow modification"; Workflow owns "how to complete modification safely". Model must not bypass confirmation, review, or permission checks to perform writes.

Risk Governance Embedded in Process Design

Risk varies with business action; the team configures four automation levels with permissions enforced outside the model:

L1 Knowledge Answer : auto-reply allowed, retain source/version, low-confidence fallback to human.

L2 State Query : read-only system calls, avoid stale cache, minimize sensitive field exposure.

L3 Rule Judgment : output judgment basis and hit rules; pause auto-handling on unclear boundaries, insufficient evidence, or rule conflicts.

L4 Business Execution : require identity verification, user confirmation, permission check, human review policy, idempotency, audit log, failure fallback.

Humans take over at L3 ambiguity and L4 high-risk; gates are code-enforced, not model-enforced. This lets automation and human teams hand off seamlessly at each tier.

Operational Loop for Sustainable Expansion

Business and policies evolve continuously; the agent must be operated as a long-lived system:

Full-chain logs: intent, context summary, retrieval content, system calls, rule versions, confirmation process, execution result, human takeover reason.

Failure taxonomy: intent errors, knowledge gaps, data anomalies, rule conflicts, system failures, permission gaps, incomplete user info.

Human feedback recycling: manual rewrites, final actions, conclusions become samples for Skill, rule, and eval-set iteration.

Version governance: Skills, business rules, Workflows independently versioned; support canary, rollback, traceability.

Operational metrics: auto-resolution rate, handoff rate, action success rate, repeat ticket rate, human rework rate, anomaly rate, user confirmation cancellation rate.

Phased Construction Roadmap

Capability rollout must match data quality, rule completeness, and governance maturity. Five phases, each with independent evaluation and explicit exit criteria:

Phase 1 Knowledge Answer : unify service knowledge tone, validate retrieval quality, reply quality, low-confidence handoff.

Phase 2 State Query : integrate order/logistics/after-sales systems, establish read-only permissions, field protection, system exception fallback.

Phase 3 Rule Judgment : structure return/exchange/cancellation/timeout rules; require model to output evidence; stability-test via historical tickets.

Phase 4 Controlled Execution : open low-risk actions first, incrementally add user confirmation, human review, idempotency, audit, rollback.

Phase 5 Operational Expansion : add Skills, tools, flows based on real failure samples; continuously shorten eval-iteration cycles.

Phased delivery breaks uncertainty into verifiable, reversible steps.

Cross-border e-commerce customer service agent construction boils down to one sentence: Let AI understand the problem, let process constrain the action, let operations continuously calibrate the system.