Ask any ecommerce ops lead where they would most like to point an agent, and the answer comes back the same: inventory. Cycle counts, variance investigation, restock math, vendor chase-downs. It is the place a well-scoped agent saves the most hours per week. It is also the place a sloppy agent does the most damage, because an unattributed quantity edit in a live inventory system is indistinguishable from shrinkage. The NRF's most recent National Retail Security Survey put 2022 shrink at roughly $112B against a 1.6% shrink rate, and the line between "missing stock" and "untracked adjustment" is exactly where that number gets argued. If you want agents in the inventory loop, the audit trail has to be load-bearing, not decorative.
Architecture: platform stays source of truth, Dock holds the agent output
Shopify, BigCommerce, NetSuite, and Cin7 remain the system of record for on-hand quantities. Dock does not replace them. Dock holds the agent's work product: variance rows, reconciliation drafts, restock recommendations, vendor follow-up tickets. Every row in a Dock inventory table carries sku_id and platform_inventory_id pointers back to the source platform. Agents read fresh quantities from the platform's inventory endpoints (Shopify's GraphQL Admin API for inventory levels, NetSuite's SuiteQL, Cin7's stock endpoints) on every run, so the table reflects current state. When a human approves an adjustment, the Dock consent gate fires the write back to the platform with the reviewer's identity stamped on it. Reads are continuous. Writes are gated. The platform owns truth. Dock owns the paper trail. See the agent collaboration primer for the broader pattern.
The table shape
One table, eight columns:
| SKU | Platform qty | Counted qty | Variance | Agent recommendation | Reviewer | Decision | Audit |
The first three are facts. Variance is computed. Agent recommendation is a structured suggestion (adjust to counted, hold pending recount, escalate to vendor). Reviewer is the human who owns the row. Decision is the gated action. Audit is the immutable trail: which agent wrote what, when, against which platform read, and which human approved.
Worked workflow: multi-warehouse reconciliation
A merchant runs three warehouses on Shopify with Cin7 underneath. The restock agent wakes up nightly, pulls on-hand from each location, compares against the most recent cycle count, and writes variance rows to a Dock table. For each variance over threshold, it proposes an action: counted-qty adjustment, transfer-in-flight reconciliation, or vendor short-ship ticket. The ops lead opens the table in the morning, filters to variance over 5 units, and walks the list. Approving a row fires the dangerous-ops contract: Dock writes the adjustment to Shopify's inventory mutation with the reviewer's user ID in the metadata. Rejecting a row keeps platform quantities untouched and logs the rejection. Restock recommendations flow into the same pipeline covered in ecommerce order pipelines.
Why this matters
Shrinkage is only investigable if you can separate counted loss from untracked edits. Vendor accountability only holds if short-ship claims trace to specific receipts. Auditors only sign off if every quantity change has a name on it. A Dock table with attributed rows gives you all three for free, as covered in agent audit and compliance. For the wider ecommerce stack pattern, see running an ecommerce stack with AI and the Dock for Ecommerce overview.
CTA
If your inventory variance lives in a spreadsheet and your agent edits live nowhere, the fix is one table away. Start with the Dock for Ecommerce overview.
FAQ
How does this handle multi-warehouse setups? Each location gets its own platform_inventory_id and rows are tagged by warehouse. The agent reconciles per-location and surfaces transfer-in-flight as a distinct recommendation type, so a unit in transit does not look like shrink at the destination or surplus at the origin.
Where does vendor data live? Vendor purchase orders, lead times, and short-ship history sit in a sibling Dock table joined on sku_id. The restock agent pulls from both when proposing reorder quantities, and vendor follow-up tickets get created as rows in a third table the buyer owns.
What about cycle counts? Counted quantities flow in from whatever counting tool the warehouse uses (handheld scanners, Cin7 cycle count exports, manual entry). The Dock table treats counted_qty as a typed input column with the counter's identity attached, so the audit row shows both who counted and who approved the resulting adjustment.
How do partial fulfillments and split shipments not pollute the variance signal? The agent reads open fulfillment state alongside on-hand quantities and excludes committed-but-unshipped units from the variance calculation. Rows where fulfillment state is ambiguous are flagged for human review rather than auto-recommended, which keeps the false-positive rate low enough that reviewers trust the queue.