AI Agent Workflows: Define the Trigger Before the Prompt

You ask an AI agent to watch inventory and help prevent stockouts. The prompt explains how to read sales velocity, supplier lead time, and inbound units. A week later, the agent creates the same replenishment task twice because the inventory alert fired twice. Another SKU never reaches the workflow because its low-stock flag changed before the nightly run.

The prompt may be sound. The workflow still fails because the team never defined exactly when the agent should start. Before you tune instructions, write the trigger: the business event, the records it applies to, and the conditions that make the work necessary.

Ecommerce agent workflows usually begin in one of four ways. A person starts a manual workflow when the work depends on a current question. A schedule starts recurring reviews such as a weekday ad-spend check. A system event starts work after one record changes. A threshold starts work when a metric crosses a business limit.

Match the trigger to the reason the work exists. A weekly margin report belongs on a schedule because the team reviews it at a known cadence. A damaged-order request belongs to an event because one customer case needs attention. A reorder investigation belongs to a threshold because the agent should act only when inventory position falls below the SKU's reorder point.

Avoid using a schedule to imitate an event unless the source system cannot send one. A nightly sweep can delay urgent work and repeatedly inspect unchanged records. Avoid firing on every update when the job needs one specific change. An order may receive several updates during payment and fulfillment, while only a failed fulfillment needs the exception workflow.

A trigger needs more detail than "when inventory is low." Write the source, event, scope, qualifying condition, and stable identifier. For example: when the inventory position for an active SKU at the main warehouse moves from above its reorder point to at or below it, start one replenishment review for that SKU and threshold-crossing event.

The contract should also say what does not start the workflow. A manual spreadsheet correction may move the number without changing physical stock. A SKU marked discontinued should not create a new purchase recommendation. An alert for a location that the buying team does not replenish should go to its owner instead.

Treat the trigger as a reason to read current state, not permission to act. The agent still needs live inventory, open purchase orders, recent demand, supplier lead time, and product status before it proposes anything. Events can arrive late, and the business record may have changed between the event and the agent run.

Consider a skincare brand that sells a cleanser from one Shopify store and fulfills it from a primary warehouse. The buying team has already set a reorder point for the SKU. The agent's job is to investigate a threshold crossing and prepare a purchase recommendation for review.

The workflow begins when inventory position moves below the reorder point. It uses inventory position rather than physical on-hand units because open customer orders and confirmed inbound stock affect the decision. The trigger carries the SKU, location, time, and event ID into the run.

The agent reads the current inventory record first. It then checks open purchase orders, recent sales, known promotions, supplier lead time, and case-pack rules. If a confirmed inbound shipment restores adequate cover, the agent closes the alert with the evidence. If the shortage remains, it calculates a proposed quantity and drafts the purchase request.

The buying manager approves the first orders. The workflow stops when the SKU is discontinued, the supplier record is missing, two sources disagree, or the proposed order exceeds the team's value limit. Each stopped run names the missing fact and sends the case to the buyer who can resolve it.

Event delivery systems retry work when a network request times out or a receiver fails to confirm it. That means the same event can reach your workflow more than once. Shopify tells app developers to use idempotent operations and the X-Shopify-Webhook-Id header to detect duplicate webhook deliveries.

Your workflow needs the same protection even when another system provides the trigger. Save a stable event or task ID before the agent writes anything. On a retry, check whether that ID already produced a completed action or an open approval. If it did, return the existing result instead of creating another task, refund, message, or purchase order.

Separate event receipt from business completion. The workflow may receive one inventory update, fail while reading the supplier record, and retry later. The second run should continue the same job. It should not create a second job because the first attempt has no finished recommendation.

ShopDucky gives ecommerce teams AI employees that can run on requests, schedules, and events across tools such as Shopify, Meta Ads, support systems, and Slack. Each workflow can gather live evidence, pause for approval, and leave a work record before an action reaches a connected system. See the AI employee directory or explore store operations workflows.