E-commerce Order Support Agent A new AI agent for e-commerce order support, governed by the AgentAz specification, answers order questions and processes routine returns while escalating disputes to humans. The agent is read-only, verifies identity, and never exposes customer data, with strict cost and loop boundaries. Overview Answers order questions — status, tracking, changes — from real order data after verifying the customer. Processes routine returns, cancellations, and refunds within policy windows and configured caps. Escalates disputes, high-value cases, and unusual requests to a human agent. Defensive: verifies identity before sharing details, never over-refunds, and never exposes another customer's data. AgentAz™ specification A lightweight, design-time governance spec for security review. It documents what this agent is authorized to do — and why — and pairs with whatever policy engine you already run. It does not enforce anything at runtime. Machine-readable contract agentaz.json , validated against the open AgentAz™ JSON Schema — bundled for offline use and published at a permanent URL: { "$schema": "./agentaz.schema.json", "version": "2.0.0", "last reviewed": "2026-06-24", "agent id": "order-support-agent", "trust level": "A2", "dna pattern": "Escalation", "worst case action": "Drafts a wrong order reply, caught before send. Cannot cancel, refund, or modify orders.", "authority boundary": "Reads order status and drafts replies; order-action/send tools absent.", "tags": "ecommerce", "order-support", "read-only", "human-review" , "tool boundary": { "allowed tools": "read order status", "draft reply", "route" , "execution tools absent": true }, "output boundary": { "format": "structured json", "never emits": "cancel order", "refund", "modify order", "send" }, "cost boundary": { "max usd per trace loop": 0.2, "alert threshold usd": 0.14 }, "loop boundary": { "max reasoning turns": 8 }, "human handoff": { "triggers": "account action needed", "sensitive issue", "low confidence" , "destination": "support agent" }, "audit": { "append only": true, "logs": "lookups", "drafts" } } New to this? Read the AgentAz specification guide /agentaz-specifications — Trust Levels, DNA patterns, and how it complements your runtime. AgentAz™ is open source under Apache-2.0 https://www.apache.org/licenses/LICENSE-2.0 — schema frozen v1.0.0 and source on GitHub https://github.com/agent-kits/agentaz . Governance matrix A scannable summary of this blueprint's governance coverage, derived from its AgentAz™ specification. It documents the boundaries that already ship — not new functionality. | Agent goal | Bounded by the authority spec above | |---|---| | Trust Level | A2 — Recommend | | Tool access | Least privilege — execution tools absent read-only | | Context handling | Grounded in provided inputs; cites or flags rather than guessing | | Memory strategy | Task-scoped; no persistent cross-session memory | | Human approval | Required on account action needed, sensitive issue, low confidence → support agent | | Audit trail | Append-only log lookups, drafts | | Cost & loop bounds | ≤ $0.2 per loop · ≤ 8 reasoning turns | | Recovery / escalation | Escalates to support agent | Agent component mapping A framework-neutral view of how this blueprint maps to standard agent-architecture components the vocabulary common to ADK-style frameworks . It describes structure for clarity — not an official integration or certified compatibility. | Agent | Primary reasoner — Recommend authority A2 | |---|---| | Tools | read order status, draft reply, route — execution tools absent read-only | | Memory | Task-scoped working context; no persistent cross-session memory | | Guardrails | Worst-case classified A2 ; no execution tools; ≤ $0.2/loop · ≤ 8 turns | | Evaluator | Confidence and authority-boundary checks; low-confidence or out-of-bounds results are flagged, not actioned | | Handoff | Escalates to support agent on account action needed, sensitive issue, low confidence | Failure modes Specific ways this blueprint can fail, and how it is designed to detect, contain, and recover from each — the boundaries that make it safe to run, stated plainly. Quotes a wrong order status or delivery date from stale data. - Detection - Order data is read fresh and its timestamp is checked. - Mitigation - It is read-only on order status and the draft is reviewed before sending. - Recovery - The human verifies status before replying. Drafts a promise it can't keep, such as a refund or expedite the company must honor. - Detection - Commitment language is flagged and the agent has no refund or cancel tools. - Mitigation - It never makes commitments or takes account actions. - Recovery - The human removes or approves the commitment. Misidentifies the order, matching the wrong customer or order. - Detection - The order-to-customer match is verified before drafting. - Mitigation - Ambiguous matches are flagged, not assumed. - Recovery - The agent confirms the order with the customer. Evaluation Answer accuracy against live order data, with zero unauthorized commitments, is what matters. | Status accuracy | Share of order-status answers matching the system of record. | |---|---| | Groundedness | Share of replies supported by order data, with no fabricated dates. | | Commitment-leak rate | Frequency of drafted promises it isn't authorized to make — should be near zero. | | Order-match accuracy | Share where the correct order and customer are identified. | | Latency | Time to a drafted reply. | Recommended approach. Use a set of order queries with known correct answers and current order data; measure status accuracy and groundedness, and audit for commitment language. Include ambiguous order matches as traps. When to use Use it when - You field high volumes of routine post-purchase questions where's my order, returns, refunds . - You have order, tracking, and policy data the agent can act from. - You want routine returns/refunds handled within caps and exceptions escalated. - You want consistent, policy-bound support with identity verification built in. Avoid it when - You expect it to issue refunds or cancellations beyond policy without human review. - You can't verify customer identity, so order data can't be shared safely. - Your cases are mostly complex disputes needing a human from the start. - You can't integrate order/tracking systems for grounded answers. System prompt You are an E-commerce Order Support Agent. You help customers with orders — status, tracking, changes, returns, refunds — using real order data, acting only within policy. You are judged on resolving routine requests well and on never sharing the wrong person's data or moving money outside policy. == CORE PRINCIPLES == 1. Verify before you reveal. Confirm the customer is associated with the order via your verification method before sharing order details, address, or status. Never expose order or personal data to an unverified or mismatched requester. 2. Policy-bound actions. Returns, cancellations, and refunds happen only within the policy window and configured caps. Beyond that, escalate — don't improvise goodwill outside your limits. 3. Honest and grounded. Answer from actual order/tracking data. Never fabricate a tracking number, delivery date, or promise. If you don't know or can't do something, say so. == HARD RULES NON-NEGOTIABLE == - IDENTITY FIRST: No order details, address, or account info to anyone not verified as associated with that order. A mismatch = do not reveal, escalate. - REFUND/CANCEL CAPS: Auto-issue refunds or cancellations only within the policy window AND at/under the configured cap. Over cap, outside window, or disputed = escalate to a human. - NO CROSS-CUSTOMER DATA: Never reveal or act on another customer's order/data. - NO FABRICATION: Never invent tracking numbers, delivery dates, stock, or promises. Use real data or state it's unavailable. - ABUSE DETECTION: Flag patterns suggesting abuse serial refunds, mismatched identity attempts for review; don't accuse, don't auto-comply. == METHOD == - Identify the order and verify the requester. Pull order status/tracking/policy. For routine in-policy requests, act within caps. For exceptions, escalate with context. == DECISION POLICY == - ANSWER: verified customer, informational request status/tracking - provide real data. - PROCESS ACTION: verified, in-policy, within cap return/cancel/refund - execute. - REQUEST VERIFICATION: identity not yet confirmed - ask for verification; reveal nothing until confirmed. - ESCALATE: over cap, outside policy, dispute, suspected abuse, mismatch, or anything unusual. == OUTPUT FORMAT return ONE JSON object == { "order id": "