Dock for Ecommerce: order pipelines your agents can update

The spine of every ecommerce ops team is the order pipeline. Not the storefront, not the warehouse, not the support queue. The pipeline. It is the row-by-row list of which orders are stuck, which are flagged, which are ready to ship, and which need a human eye before money moves. Today that pipeline lives in three places at once: the commerce platform, a Slack channel, and someone's head. AI agents already triage and summarize against it, but their output evaporates the second the thread scrolls. There is no shared truth the next shift can pick up.

The architecture in one paragraph

Your commerce platform (Shopify, BigCommerce, WooCommerce, take your pick) stays source of truth for the order itself: line items, payment status, fulfillment, customer record. Dock does not copy any of that. What Dock holds is the agent's output layered on top: the triage row, the prioritization decision, the recommended next action, who reviewed it, what they approved. Each Dock row carries an order_id pointer back to the platform. Agents read fresh from the commerce API every time, write their work into the Dock row, and Dock's consent gate fires mutations (refunds, holds, address changes) back to the platform when a human (or a policy) signs off.

The pipeline as one Dock table

One table. Seven columns. Live in the ops workspace, open all day, every agent and human writing into the same rows.

Order #	Customer	Status	Agent recommendation	Reviewer	Decision	Audit
#48211	Lin H. (3rd order)	hold	Argus: fraud risk, billing/ship mismatch	Sarah	release	argus-drafted 14:02, sarah-approved 14:07
#48212	Priya R. (new)	rush	Echo: ship today, paid express	Govind	approve	echo-drafted 14:03, govind-approved 14:04
#48213	Marco V. (VIP)	refund	Argus: damaged on arrival, refund $89	Sarah	approve	argus-drafted 14:05, sarah-approved 14:11, refund fired 14:11

The agent column is attributed by name. The reviewer column is a human. The audit column is signed and immutable. Nobody is hunting in Slack for who said what.

One worked workflow: rush-order triage during BFCM

Black Friday weekend, 12:01 p.m. EST. Shopify merchants peaked at $5.1 million per minute and moved $14.6 billion across the weekend, up 27% year over year. At that velocity, your fraud and rush queues both double. Five steps the Dock table runs:

1. Webhook fires on every new order. Dock writes a row with order_id and status: incoming.
2. The triage agent reads the live order from the platform, scores fraud risk and rush eligibility, writes its call into agent recommendation with reasoning.
3. The prioritization agent reads the row, cross-references warehouse capacity, decides whether rush is feasible, updates status to rush, hold, or standard.
4. A human reviewer (or an auto-policy under a threshold) marks decision. Dock's consent gate fires the mutation back: refund issued, hold released, ship-by date updated.
5. Audit row closes with the signed chain: agent name, timestamp, reviewer, mutation hash.

Why this matters

Handoff between shifts. A West Coast ops lead clocking on at 6 a.m. opens the same table the East Coast lead closed at 11 p.m. The pending rows are visible, the agent reasoning is right there, the decisions already made are signed. No standup needed.

Multi-region ops. Teams in three time zones writing into one table is the only model that holds up at BFCM scale. Slack does not. A doc does not. A live table where every agent writes attributed updates does.

Audit trail. When a chargeback lands six weeks after the order, the row already has the signed chain. McKinsey notes that agentic AI in operations now plans actions, processes payments, and completes shipping autonomously, but the value only lands when the work is reviewable. Dock makes it reviewable by default.

For the wider pattern, the Dock for ecommerce overview sketches the full stack and running an ecommerce stack with AI shows the operating model. For the underlying primitives, start with agent collaboration and the shared workspace as a collaboration primitive. For the compliance layer, agent audit and compliance. For the next table over, inventory tables your agents can update.

Try it

Spin up a Dock workspace, point a webhook at the order pipeline table, let one agent start writing into it. The pipeline becomes a real artifact the same afternoon.

FAQ

Will this scale to thousands of orders an hour? Yes. The Dock row is a thin pointer with agent output, not a copy of the order. At BFCM peak (millions of orders per minute on the platform side), your ops table is still the subset that needs human or agent attention. That set is typically hundreds to low thousands an hour even at peak, and Dock tables are built for that.

What happens when two agents disagree on the same row? The row keeps both recommendations, attributed by agent name. The reviewer column is where the conflict resolves, not in the agent layer. If the conflict is structural (agent A always wants to refund, agent B always wants to release), the audit trail surfaces the pattern and ops can retune the policy.

Does this work across multiple stores or regions? Yes. Each row carries a store_id or region column. Agents scoped to one store cannot write into another store's rows. A rollup workspace reads aggregates across stores for the ops lead who watches all of them.

Why a table and not a doc? A doc is the right shape for one narrative one human reads. A pipeline is the wrong shape for that: it is many rows, many agents, many updates per row, many readers. Tables sort, filter, and merge. Docs do not. The pipeline goes in a table.