Product listing

Period 2026.07 — 2026.08

The listing agent handles one product from planning to confirmed publishing. From real product photos and the backend's price calculations, it drafts the product plan and detail page assets. The plan covers the product name, options and search terms. Once the defined procedure passes, the backend lists the product on Coupang and Toss Shopping. The agent then confirms the actual listing state through official channel lookups. The first real product was listed on both channels and its publishing confirmed.

The listing agent drafts the plan and detail page assets,
then products that pass the checks are published on two channels and confirmed through official lookups

Team: Solo
Role: Listing agent designListing state flowDetail page generation and checksChannel publishing and verification

GoPostgreSQLMinIOHermes AgentNode.jsPlaywrightJSON Schema

A state flow that ties the plan draft, detail page assets, publishing on two channels and official lookup checks to the same listing
Planning based on three different real product photos, with unsuitable photos swapped for other candidates
A precondition that each option has at least two purchase routes before automatic listing
Agent permissions that block bypassing the defined procedure, direct database or channel writes and supplier orders
Manual listing records that keep the operator's chosen photos and listing inputs with hashes

Detail images that looked like different products

Problem: Each detail page image was generated separately, so the same fruit could look like a different variety from one image to the next.
Solution: The researched variety, skin and shape went into every image instruction unchanged. Each generated image was checked with a vision model to confirm it showed the same product. A job completed only when every image passed the check.

Image jobs that could start without evidence

Problem: Without enough real photos, images could be generated from a different variety or a synthetic image.
Solution: Before queuing an image job, the backend checked that the same listing had at least three different real photos. It stopped the job when the evidence was synthetic or generic, or when the research had changed. Jobs with mismatched evidence stopped before any paid generation.

Paid retries with unknown outcomes

Problem: If a job finished but its completion response was lost, the same images could be generated and paid for again.
Solution: Before a retry, the worker first checked the job state in the backend and the stored result. With a stored result it resent only the completion report, and with an unknown outcome it did not rerun paid generation automatically. Jobs with a stored result were not generated again.

Edits that changed untouched images

Problem: Even a request to fix only the copy could change images and composition, and regenerating cost money again.
Solution: Edits were split into three modes: chosen images, automatic selection and copy only. Unselected images were copied unchanged from the existing result, and only failed images were regenerated. Copy edits required no image generation, and hash checks confirmed that the original images were unchanged.