If you run BigCommerce at enterprise scale, you are probably running it as several stores at once. A US storefront, a UK storefront, a B2B portal, a headless DTC build on Catalyst, plus a couple of marketplace channels piped through Channel Manager. The platform handles that fan-out well. What it does not handle is the agent work that sits across the fan-out: the rollup someone's agent did at 2am to reconcile inventory across three regions, the pricing brief half-drafted for the EU relaunch, the partial decision about which SKUs to retire on channel six.
That work needs somewhere to live. Right now it lives in chat logs nobody can find.
What Dock is, and is not
Dock does not replace BigCommerce. BigCommerce stays the system of record for catalog, orders, customers across storefronts. Dock holds what agents interpret: the multi-store rollup, the cross-channel brief, partial decisions. Each row carries bc_order_id or bc_channel_id pointers. Agents read fresh from BigCommerce REST and GraphQL APIs; Dock's consent gate fires mutations back. Data loops through Dock; data never leaves BigCommerce.
That distinction is the whole point. The catalog is sacred. The agent's interpretation of the catalog is the thing that keeps getting lost.
One workflow: cross-channel inventory and pricing
Pick a workflow most enterprise BigCommerce teams know. Friday afternoon, the merchandising lead asks an agent to coordinate inventory and pricing across five storefronts for a Monday promo. The agent needs to pull live stock, compare price points across channels, flag SKUs with thin coverage, and stage updates per storefront.
In Dock, that becomes a workspace. One sheet per storefront, rows pointing at bc_channel_id and bc_product_id. The agent fills in proposed prices and reserve quantities. Govind walks in Monday morning, sees the proposed edits attributed to the agent, approves a subset, sends the rest back with a comment. The consent gate fires the approved writes through the Catalog and Pricing APIs. The unapproved rows sit there, resumable, until someone makes the call.
Data flow
- Agent reads catalog, channels, inventory live from BigCommerce REST and GraphQL Storefront APIs.
- Agent writes interpretation into Dock rows with
bc_channel_idandbc_product_idpointers. - Human reviews in the Dock workspace, sees attribution per cell.
- Human approves through the consent gate.
- Dock fires the mutation back to BigCommerce; the row records who approved and when.
Same loop for B2B price lists, channel-specific product overrides, and bulk variant edits.
Why BigCommerce specifically
Two reasons. First, the multi-storefront and Channel Manager surface area is larger than most platforms. BigCommerce notes that over 90% of platform functionality is exposed via APIs, which means an agent can read and write almost anything, which means the question of where the agent's intermediate thinking lives becomes urgent, not optional. Second, the headless and composable patterns BigCommerce leans into (Catalyst, MACH Alliance membership, the REST Management, REST Storefront, and GraphQL Storefront APIs all sitting side by side) mean agents are already orchestrating across more endpoints than a human can hold in their head. Persistence and attribution stop being nice-to-haves.
CTA
If your BigCommerce stack already has agents touching catalog or channel data, the question is not whether agent state needs a home. It is whether you want that home to be a chat transcript or a workspace.
Start with Dock for ecommerce. The architectural backbone lives in agents are principals, consent gates for dangerous ops, and the AI workspace, not the AI assistant. For platform-by-platform comparisons see Dock and Shopify order pipelines and Dock and Stripe payments. For the broader picture, running an ecommerce stack with AI.
FAQ
Does Dock replace BigCommerce Channel Manager? No. Channel Manager stays the routing layer between BigCommerce and your sales channels. Dock sits next to it, holding the agent's interpretation of what Channel Manager surfaces: rollups, briefs, proposed edits. The writes still flow through Channel Manager and the BigCommerce APIs.
How does multi-store sync work?
Agents read live from each storefront's APIs (no copy of the catalog lives in Dock). Rows carry bc_channel_id so a workspace can span storefronts without losing which row belongs to which store. Writes go back per-channel through the consent gate.
What about headless? Headless makes this more useful, not less. A Catalyst build or a custom React storefront still talks to the BigCommerce APIs underneath. The agent's interpretive layer (which SKUs to feature, which copy to ship, which price to test) needs persistence regardless of which frontend renders the catalog.
Can agents publish to multiple storefronts at once?
Yes, with consent. A Dock workspace can stage edits across several bc_channel_id rows; the consent gate fires the approved subset in parallel. Per-channel approval is a row-level decision, not all-or-nothing.
Where does Dock store catalog data? It does not. Dock stores pointers and the agent's interpretive layer. Catalog state stays in BigCommerce. If you delete a Dock workspace, the catalog is untouched.