Product descriptions generated from a photo

This process begins every time a new product is added to Shopify and needs a published description before it can sell. A team member picks up the task, reviews the product image and spec sheet for completeness, writes the listing copy, and then creates SEO-optimised variants for each target market and language. Once a draft clears a quality check for factual accuracy and distinctiveness, it is published to Shopify. Any product with an incomplete spec, an unusual format, or copy that sounds too similar to an existing listing is handled as an exception and reworked manually. The whole cycle currently takes around fourteen minutes per product.

The team runs this process several times a day, adding up to roughly 5,000 products a year. At that volume the cumulative manual effort exceeds 1,100 hours annually, and the bottleneck means new products sit unlisted while the queue is worked through. The two ops team members and the founder share the load, and the founder also maintains the custom scripts and Shopify integrations the business already relies on.

The end outcome is a published Shopify listing with market-ready copy and language-specific SEO variants. The inputs are always the same: a product image and a structured spec. The outputs follow a consistent template for the large majority of products, with a minority requiring more judgement because they fall outside the standard pattern or arrive with incomplete data.

The recommended path is an AI Workflow, and the case for it here is unusually clear. The two inputs, a product image and a structured spec, are exactly what vision-capable language models like GPT-4o are designed to process. The output is natural-language copy that follows a consistent template, which is precisely what a well-engineered prompt produces reliably at scale. The high annual volume means even a modestly priced LLM API call per product will cost a fraction of the manual equivalent, and the Shopify Admin API means the pipeline can pull inputs and push draft descriptions without any screen-scraping or brittle UI automation. This is not a case where AI is being reached for because it sounds modern; it is the right tool because the task is structurally a vision-to-text generation problem with clear inputs and outputs.

The recommended AI Workflow aligns directly with the preferred tech stack the founder described. The orchestration layer is Python, the integration is the Shopify API the team already uses, and there is no need for a third-party RPA platform or a low-code tool that adds vendor dependency and licensing cost. The founder's ability to code is a genuine asset here, not just a nice-to-have: it means the team can own, maintain, and iterate the pipeline without relying on an external vendor for every prompt update or threshold adjustment.

The AI Agent path scored reasonably but is not the right call at this stage. An autonomous agent could in principle handle the full loop from spec retrieval through to publishing, but the process is linear enough and the exception rate low enough that the added complexity of agentic autonomy creates more risk than benefit. Agents are harder to audit, harder to debug when they go wrong, and introduce unpredictability into a workflow where consistency is the whole point. A structured AI Workflow with a defined exception gate achieves everything the client described as the goal without those downsides.

Traditional Code and RPA are not viable here for a simple reason: neither can generate natural-language copy from an image. Traditional code could handle the Shopify API calls and data validation at either end of the pipeline, and indeed it does exactly that as the orchestration layer in the recommended approach. But writing deterministic rules to produce varied, market-specific, on-brand product descriptions is not feasible. RPA adds nothing in a process that already has API access and requires language generation. Both paths would solve only a fraction of the problem and leave the hardest part, the writing, still manual.

The human-in-the-loop element built into the recommended workflow is not a compromise or a workaround. It is the right design for a process where factual accuracy in published copy carries a compliance obligation. Roughly 85% of products will clear the confidence threshold and publish as drafts that have passed a quality bar; the remaining 10 to 15% route to a lightweight review queue where a team member makes the call. This matches the way the team already works: humans stay on exceptions and edge cases, and the pipeline handles the repeatable volume. The Hybrid path in the assessment is essentially this same architecture described from a different angle, which is why it scores close to the AI Workflow but does not warrant a separate implementation.

The two paths worth comparing seriously are AI Workflow and Hybrid. The honest answer is that they are nearly the same thing: a well-designed AI Workflow already embeds a human review gate for low-confidence outputs, which is precisely what a Hybrid label implies. The reason AI Workflow scores higher is that framing the architecture as a workflow from the start keeps the design clean and the exception handling deliberate, rather than bolting a human layer onto something that was conceived as fully autonomous. For this specific process, where roughly 85% of products follow a clear, repeatable description pattern and the inputs are a structured image plus a spec, a workflow with a confidence-threshold gate is the right shape. The human is not in the loop for every run; they are called in only when the pipeline itself signals uncertainty.

The AI Agent path is genuinely viable but is not the right call here. An agent could in principle retrieve specs, analyse the image, generate copy, optimise for each market, and push to Shopify in a single autonomous loop. The problem is that this process does not need that flexibility. The steps are linear, the decision points are well-understood, and the exception rate is low enough that the added unpredictability of an agent-style architecture would create maintenance overhead without delivering any meaningful benefit over a structured workflow. Agents earn their complexity when a process requires dynamic decision-making or tool-chaining that cannot be anticipated at design time. This process does not meet that bar.

Traditional Code and RPA can be dismissed quickly. Traditional code could automate the Shopify API publish step and validate incoming spec data, but it cannot generate varied, market-specific natural-language copy from a product image without embedding a language model anyway. RPA is irrelevant here: the process requires language understanding and creative variation, not UI-level screen interaction, and the Shopify API makes any UI automation redundant. Both paths solve a small fraction of the problem and leave the hard part, which is the copy generation itself, entirely untouched.

The pipeline starts at a Shopify webhook. When a new product is created or moves into a designated "awaiting description" status, the Shopify Admin API fires an event that triggers the orchestration layer, which is a Python script running on a lightweight cloud host such as a Railway or Render service, or simply a scheduled job if a polling approach is preferred. The script pulls the product image URL and the structured spec fields directly from the Shopify product record, then passes both to a vision-capable language model. GPT-4o is the natural choice here given its image understanding and instruction-following reliability at scale, though Claude 3.5 Sonnet is a close alternative worth benchmarking against during the prompt design phase. The prompt template is not a single generic instruction; it is a library of templates keyed by product category and target market, so a tool listing for the German market gets a different tone and SEO keyword structure than a home goods listing for the UK. The model returns structured JSON containing the main description, a set of SEO-optimised variants for each requested market and language, and a confidence score derived from how completely the image and spec data matched the expected inputs for that category.

The confidence score drives the routing decision. Outputs above the threshold are formatted and written back to Shopify as a published draft via the Admin API, flagged for a light-touch quality spot-check but not held in a queue. Outputs below the threshold, typically products with incomplete specs, ambiguous images, or categories the prompt library does not yet cover well, are written to Shopify as unpublished drafts and simultaneously logged to a simple review queue. That queue can be as lightweight as a tagged Shopify metafield combined with a filtered view in the Shopify admin, or a small internal web form if the team prefers a dedicated interface. A team member reviews the flagged items, edits the draft directly in Shopify, and publishes. The threshold itself is not fixed at launch; it is calibrated during the two-week parallel pilot, where the pipeline runs alongside the manual process and the team scores outputs to find the right cut-off point between acceptable auto-publish quality and genuine exception cases.

The prompt library is the most important ongoing asset in the system. It should be stored in version control from day one, not as an environment variable or a hardcoded string, because it will need to change as the product catalogue evolves and new categories are introduced. The founder's existing Python scripting capability means the orchestration layer can be built and owned internally without dependency on a third-party automation platform. That said, a thin wrapper around the LLM calls using a library such as LangChain or LiteLLM is worth considering, not for agent features but for the practical benefits of prompt versioning, retry logic, and straightforward model-switching if the API cost or quality picture changes.

Monitoring is simple but should not be skipped. A log of every pipeline run, recording the product ID, the confidence score, whether the output was auto-published or queued, and the LLM API cost per call, gives the team the data they need for the monthly quality review. At 5,000 runs per year the API costs are modest at current GPT-4o pricing, somewhere in the range of a few hundred pounds annually depending on image size and output length, but logging costs per run means there are no surprises if volume grows or a new category requires substantially longer prompts. The monthly review cadence should check output quality against a random sample, review the exception rate trend, and update any prompts that are producing repetitive or off-brand copy.