Your.Store
An operations copilot for Shopify stores, built so that the language model never holds the pen. It proposes; deterministic Python decides whether the proposal is even executable; a human approves before anything is written.
The problem
Giving a language model write access to a live store is the point at which demos stop being interesting and start being dangerous. A hallucinated price update is not a bad answer; it is a bad state change, and it persists after the conversation ends.
The design rule
The model plans. Deterministic Python executes. Those are separate stages with a typed boundary between them, and the model has no path that reaches a write without passing through a human-approval interrupt.
That last part is structural rather than instructed. The approval is a node in the graph, not a line in a prompt telling the model to ask first. There is no prompt phrasing that routes around it, because the edge does not exist.
Architecture
An 18-node supervisor graph splits read and write paths, so the read side stays fast and unblocked while writes queue behind approval. Thirteen tools are exposed over MCP at /mcp. Cross-session state persists to Shopify metaobjects, which means the store itself carries the copilot’s memory rather than a separate database.
The codebase keeps a hard split: core/ contains orchestration with no Shopify knowledge at all, app/ contains the Shopify layer. The intent is that core/ outlives this particular integration.
Current state
Working and in active development, with known open bugs rather than a claim of stability. The one I care most about is a regression on the MCP approval path, where a write approved through MCP does not execute afterwards, the same failure shape as an earlier hallucinated-write bug, which suggests a shared root cause around unrecognised intent degrading to a stale default rather than an honest failure.
