The AI loads 18 months of order history and your supplier cost sheet to answer "where's my package?"

The situation

Why answering a tracking question costs as much as writing a strategy memo

The brand does $4M in annual revenue across Shopify DTC and Amazon FBA. Customer support handles 60–80 tickets per day, and about 70% of them are simple: where is my order, how do I return this, can I skip my next subscription shipment. The AI agent was set up by an integration partner who connected it to the Shopify API, the returns management system, and a shared Google Drive folder with internal operating docs. The setup was fast. The scoping was not.

Every support query triggers the same context-loading pipeline. The agent pulls the customer's full order history (every order, not just the relevant one), the complete product catalog (including internal-only fields like supplier name, landed cost, and margin percentage), the brand's return policy document, the subscription terms, and the FAQ. For a repeat customer with 30 orders, that is 35,000–45,000 tokens of context before the model reads the question. The model processes all of it, the API bills for all of it, and the answer uses maybe 200 tokens from one order record and one policy paragraph.

The data exposure is the sharper problem. The supplier cost sheet includes landed cost per unit, freight rates, and supplier contact information. The margin spreadsheet shows markup by product and by channel. None of this should be in the context window for a customer-facing interaction. The model is instructed not to reveal internal data, but instruction-following is probabilistic — if a customer asks "how much do you pay for this?" in a creative enough way, the model has the answer in its context. The brand is one adversarial prompt away from leaking its cost structure to a customer, a competitor, or a social media post.

The work

What Taz actually audits and delivers

Taz maps every piece of data the AI agent can access, measures what it actually uses per query type, identifies what should be removed or gated, and delivers a context diet with a routing plan.

• Context inventory: Every data source connected to the AI agent is cataloged: Shopify order API (which fields, which history depth), product catalog (which fields, including internal-only fields), returns system, subscription platform, Google Drive documents, FAQ, and policy files. Each source is measured by average token count per query and classified as customer-facing, internal-operational, or sensitive.
• Query-type analysis: A sample of 200 support tickets is classified by type — tracking, return, subscription change, product question, complaint, billing dispute, and other. For each type, Taz maps exactly which data sources the model actually references in its response vs. which data sources are loaded but unused. Tracking queries need one order record and a tracking number. Return queries need the order, the return policy, and the product's return eligibility. Subscription queries need the subscription record and the subscription terms. None of them need the full order history, the product margins, or the supplier costs.
• Sensitive data exposure map: Every field the model can access that it should not be able to surface in a customer-facing response: supplier names, landed costs, margin percentages, freight rates, wholesale pricing, internal notes. Each field is risk-ranked by the consequence of exposure — competitive risk (cost structure), privacy risk (supplier contacts), or embarrassment risk (internal product notes that use candid language).
• Context diet prescription: For each query type, a minimum-viable context specification: exactly which data sources, which fields, and which history depth the model needs. Tracking queries get the most recent order and its tracking record — not 30 orders. Return queries get the relevant order and the return policy — not the product catalog. No query type gets the margin spreadsheet or supplier costs.
• Routing plan: A query classifier that routes incoming tickets to the right context profile before the model sees them. Simple tracking queries load a slim context and can use a cheaper model. Complex complaints or billing disputes load a richer context and use the primary model. The routing plan includes the classifier logic, the context profile for each route, and the fallback for queries that do not classify cleanly.

The deliverable

What the brand receives

• Context inventory spreadsheet — Every data source, every field, token count per query, classification (customer-facing / internal / sensitive), and usage frequency by query type. The brand can see at a glance which data costs the most tokens and which data the model never uses.
• Sensitive data exposure report — Each sensitive field with its risk ranking, the query types where it is currently loaded, and the recommendation: remove from context, gate behind a permission check, or move to a separate internal-only workflow. Includes a list of adversarial prompt examples that could surface the data under the current configuration.
• Context diet by query type — A specification for each of the 6–8 query types showing exactly which data sources and fields to load. Includes token-count estimates for the slim context vs. the current bloated context and the per-query cost difference.
• Routing plan with classifier logic — The query classification rules, the context profile for each route, the model tier for each route, and the fallback behavior. Written as a specification the brand's integration partner can implement without interpretation.
• Implementation ticket list — Prioritized changes: API field filtering (stop loading internal fields), history depth limits (last 3 orders, not all orders), sensitive document removal (unlink the margin spreadsheet), and routing classifier setup. Each ticket has the effort level, the token savings, and the risk reduction.