HolloEngine: 6 agents. 3 minutes. One less VA on payroll.

Every e-commerce operator knows the catalog quality cliff.

When you launch an eCommerce store, the first 50 products look incredible. The descriptions are sharp, the images are perfectly sized, and the SEO metadata is dialed in.

Then the reality of scale sets in, fatigue takes over, and your listings become a copy-paste graveyard.

When I asked the Founder of a luxury e-commerce store what his biggest bottleneck was, this is what he described to me.

They were paying a Virtual Assistant to manually move inventory from Yupoo, which is a gated Chinese supplier photo platform, to their storefront.

It took the VA 45 to 60 minutes to process a single product end-to-end.

Why? Because the hardest part wasn't just downloading images. It was reverse-engineering the data.

As you can see in the screenshot below, the suppliers provide untitled JPGs and a messy block of Chinese text that might reference three different brands in one field.

To actually sell the item, the VA wasn't just guessing. They were forced to play digital detective, executing a tedious, manual forensic process for every single SKU.

First, they used a browser extension to translate the Chinese text just to extract a baseline brand name. Then, they ran the main product photo through Google Lens, filtering the visual search with that brand to narrow the field.

This was the massive bottleneck.

Google Lens spits back dozens of similar-looking retail listings. The VA had to manually scrutinize the results, using deep visual discernment and reasoning to match the supplier's photo perfectly with verified online stores.

Moreover, they had to cross-reference tiny details, such as hardware, stitching, and monograms, to figure out if they were looking at the official "Gucci Jordy Monogram Bit Loafer" or just a generic slip-on.

For some products, it was quick. For others, it was a 20-minute rabbit hole of opening tabs and comparing pixels.

But this exhaustive research was mandatory. Finding that exact official model name is what drives the business.

That name becomes your primary SEO keyword. When you optimize your descriptions, JSON-LD schema, and image filenames around the exact phrase a high-intent buyer is searching for, you capture the purchase.

If the VA got fatigued and picked the wrong variation, the product was functionally invisible. A slight misclassification meant a lost customer and zero organic traffic.

Furthermore, managing this manually meant there was zero pipeline visibility. If a product got stuck in this research phase, or an image link broke during upload, it failed silently. They only found out when a listing was missing.

So, we built a system to take the human out of the data-moving business entirely.

The first decision we made was that we weren't going to automate the VA's workflow. We were going to replace the need for the role entirely.

That meant the system had to do everything end-to-end. Not just assist a human through the process, but own the process from the moment a URL is pasted to the moment a live product appears in the store.

So we mapped every step the VA was doing manually and assigned it to an agent.

Six agents. Each one does exactly one job and hands off cleanly to the next one in the chain.

To make sure each agent was doing its job correctly, we scoped the projects and then had the client verify what needed to happen at each turn.

Our client doesn't run one store but runs several across both Shopify and WooCommerce. From the beginning, we knew we weren't building a one-off tool for one store.

We were building something that needed to work across multiple brands, multiple storefronts, and multiple product catalogues without anyone having to reconfigure it each time.

That's why the first thing we built wasn't an agent that processes products. It was an agent that studies the store.

We call it Agent 0: The Apprentice.

Before a single product gets touched, Agent 0 scrapes the client's existing storefront. It reads through live product pages, category pages, and how the store’s SKUs are currently named and described.

It picks up the vocabulary the brand already uses, what materials they call out, how they label product types, which categories exist in the store, and how products are sorted into them.

The output is a structured reference file that captures all of that juicy info, and every agent that generates content later reads this file first.

This matters for two reasons.

And the cost to run Agent 0? Roughly a one-time payment of $0.002 per storefront, not per product. Once it's done, it's done. Unless the store changes significantly overnight, of course, in which case it reruns in seconds.

After Agent 0 runs, that’s when the real fun begins.

In my experience, when you scope a project, it all seems so easy! I mean, Agent 1 just downloads the images and loads them to GPT Vision, right? Eazeeee.

Wrong.

Each website is built with its own complexities and nuances. Yupoo protects its images at the infrastructure level.

If anything tries to download them the normal way (the way any standard automation tool would,) the request gets rejected with an error, and the images simply don't load.

This is exactly why off-the-shelf scrapers don't work on Yupoo, and why the VA was handling this step manually in the first place.

We needed a different approach.

Instead of trying to download images from outside the platform, we built something that behaves like a real user sitting inside an authenticated Yupoo session.

It opens the album page the same way a browser would, and intercepts each image as it loads, picking it up before it even fully renders on screen.

The images never touch a third-party server. They go directly from Yupoo into Cloudinary, Luxearchive's image hosting platform, where every asset lives under the client’s own account.

[SCREENSHOT: Cloudinary library showing uploaded product images]

Alt for screenshot: In the old workflow, every image had to be downloaded individually, renamed manually, and organized in Google Drive before it could go anywhere. Now, a few lines of code handle the entire retrieval and upload process automatically — at a tenth of a cent per product.

Because this step uses no AI at all (pure mechanical retrieval with code and logic), it costs almost nothing. A tenth of a cent per product.

These images then become the foundation for everything that follows.

Agent 2 picks them up and starts answering the question the VA used to spend 15 minutes on: what exactly is this product?

Remember the part where the VA spent 10 to 15 minutes on Google Lens trying to figure out if they were looking at an official Gucci Monogram Bit Loafer or just a generic slip-on?

This is the agent that replaces that entire process, and it does it in 18 seconds.

But here's what makes it interesting: it doesn't just guess from the image; it builds a case.

The first thing Agent 2 does is send the hero image to Google Lens programmatically via SerpAPI.

We chose SerpAPI specifically because it's the most reliable way to run Google Lens searches through code.

Additionally, because Cloudinary already hosts every image with a clean public URL from Agent 1, the image goes straight into the search with no file transfers or authentication steps in between. That Cloudinary decision from the previous agent wasn't accidental.

If Agent 1 found a brand hint buried in the Chinese supplier text — something like [Brand: Gucci] that gets passed into the search too, narrowing the results toward the right brand from the start. If we were doing it manually, it would look like this:

Google Lens comes back with up to 10 visual matches, usually pages across the web that contain similar images.

It also returns a knowledge graph entry, an AI overview, and sometimes a direct answer box. The agent reads all four.

At this point, the agent has raw material. What it doesn't have yet is a conclusion.

Not all search results are equal. A match from Hugo Boss’ official website tells you something very different from a match from DHgate.

So before anything gets passed to AI, every source that came back from Google Lens gets scored. We built a reputation system with four tiers, hardcoded directly into the pipeline:

No AI makes these calls. It's a straight lookup against a curated list of URLs returned from the SERP API call: fast, consistent, impossible to hallucinate.

Here's why this matters in practice.

Take this BOSS shoe from the screenshot above. The raw supplier album title is "2026 New Casual Shoes." The description is a block of translated Chinese text referencing 【BOSS】 and Italian flyknit fabric. That's all the system has to work with going in.

Google Lens comes back with 10 visual matches. Among them: hugoboss.com, farfetch.com, and ssense.com, all scoring 1.0. The knowledge graph returns the exact product name: BOSS Motion Sneaker, White, Knit Upper.

That name is now the SEO foundation for the entire listing. The product title, the meta description, the image filenames, the JSON-LD schema, everything downstream gets built around "Hugo BOSS Motion Men's Sneaker White."

That's one of the phrases a buyer might type into Google when they're ready to purchase. And because that name came from the official brand site and two Tier 1 authorized retailers, the system knows it's right.

If the agent had trusted the supplier text alone, the listing would have gone up as "BOSS Casual Men's Shoe," a keyword no human would ever type into Google and that ranks for nothing and captures zero organic traffic.

The domain scoring is what closes that gap. It's not just accuracy for accuracy's sake. It's the difference between a listing that gets found and one that doesn't.

Every field below gets extracted from two sources working together: the translated Chinese supplier text and the verified visual search results.

Where they conflict, the visual evidence wins.

This is the SKU identity, AKA the single verified record that every downstream agent builds from.

By the time Agent 2 is done, the pipeline has something the VA spent 20 minutes hunting for manually, a verified, evidence-backed product identity package. All of it checked against the highest-credibility pages on the web.

Agent 3 picks that up and has one job: to turn it into SEO Optimised copy that ranks and converts.

By the time Agent 3 runs, the hard work is already done. The product has a verified identity, the brand is confirmed, the model name, color, material, and size range are all sitting in the database, sourced from Tier 1 pages on the web.

Agent 3 has one job: turn that into copy that gets found and converts.

It does it in a single GPT-4o call. Everything goes in (the verified product identity from Agent 2, the supplier's translated text, the research sources), and everything comes out in one structured response.

Here's exactly what that one call produces:

The JSON-LD schema, the structured data that powers rich snippets in search results, is built entirely in Python from the verified fields. GPT never touches it.

That's a deliberate call: schema markup needs to be precise and consistent, and templating it in code guarantees that every single product gets a valid, correctly structured schema every time.

Two other decisions worth noting:

One, the focus keyword, the primary SEO term that Rank Math targets on the live listing, is not something GPT decides. It's constructed directly from the verified product name that came out of Agent 2. For the BOSS Motion sneaker, that's exactly "Hugo Boss BOSS Motion Men's Sneaker White." That's the phrase buyers search for. That's what the listing targets.

Secondly, the pricing fields in the final listing are left intentionally empty. The system extracts the supplier's Chinese price for reference, but the client sets their own retail pricing. The system doesn't guess.

Agent 4 picks up from here and handles the one thing copy can't do: make the images production-ready.

Agent 2 needed images for visual search. Agent 3 needed verified product data to write copy. Agent 4 is the one that actually makes the images ready for a live store, and it has four distinct jobs to do on every single one.

Before anything gets renamed or compressed, Agent 4 looks at each image and answers one question: what angle is this shot from?

It sends each image to GPT-4o Vision individually and gets back a single label:

That label determines both the filename and where the image sits in the final gallery.

Here's the decision that made this affordable: the classification runs at the lowest possible image resolution.

For this task (distinguishing a front shot from a sole shot), the system doesn't need to read text or examine fine stitching detail.

It just needs to identify the camera angle. Running at low resolution costs roughly $0.00046 per image. For a product with 8 images, the entire classification pass costs less than half a cent.

If two images come back with the same label (two shots from the front, for example), the second one gets numbered automatically.

The first stays as boss-motion-sneaker-white-front-view.webp, the second becomes boss-motion-sneaker-white-front-view-2.webp. Nothing gets overwritten.

Every image gets compressed, regardless of its original size. The client was very keen on this, so the site doesn’t load too slowly.

The target is under 100KB at 1000px wide. The system starts at quality 80 and works downward in steps of 5 until the image fits, stopping at a floor of 40 if needed.

In production, a batch of 8 images went from 4,171KB of raw JPEGs to under 500KB of WebP files. That's an 88% reduction in page load weight per product.

Faster load times. Better Core Web Vitals. Better SEO.

The final filename is built from two agents working together without directly communicating.

Agent 3 already produced a clean SEO slug from the verified product identity, something like hugo-boss-motion-mens-white-sneaker. Agent 4 appends the viewpoint label that it just classified. The result:

hugo-boss-motion-mens-white-sneaker-front-view.webp

That filename is a keyword.

When Google crawls the image, it reads that string. It confirms the page is about exactly what the title and meta description say it's about. Every image in the gallery reinforces the same signal.

Before anything gets uploaded, Agent 4 sorts every image in a fixed priority: front-view first, then overhead, side, back, sole, inside, on-feet, and detail. The front-view becomes the featured product image.

Agent 5 applies the same sort again at publish time, so the gallery always leads with the right shot regardless of what happened in between.

The upload follows a precise path structure we locked in after an early mistake: giving Cloudinary both a folder name and a file path causes it to combine them, doubling the directory. The fix is one parameter, not two.

Okay! Now, we have the grand finale!

Agent 5 is the only agent with no AI in it. No GPT calls, no vision models, no language generation. By this point, the pipeline has done all the thinking; Agent 5 just pushes everything to the storefront.

Here's exactly what it does, in order.

When Agent 5 finishes, two things happen: the Supabase status flips to PENDING_APPROVAL, and a Slack notification fires to let the team know a product is waiting to go live.

The remaining human step is straightforward. The operator clicks through to the WordPress admin edit screen, enters the retail price for each size variation, and hits publish.

One limitation worth naming: if Agent 5 fails partway through, say, after images are already uploaded but before the product is created, there's no automatic rollback. Orphaned media files stay in WordPress, and a re-run creates a new product.

It surfaces clearly in the dashboard as PUBLISH_FAILED with the error logged, and a Slack alert fires immediately.

Also, once the client publishes in WordPress, that status doesn't sync back to HolloEngine, the Supabase row stays at PENDING_APPROVAL. It's a known gap, not a hidden one.

At $0.00 per product, Agent 5 is the most cost-efficient step in the pipeline. The entire system, six agents, from raw Yupoo URL to WordPress draft — costs $0.023.

When you build a six-agent pipeline, you have two options. You can hand the client a technical system and hope they figure it out. Or you can build them an interface so clean that the complexity disappears entirely.

We chose the second one.

Every agent in HolloEngine runs in the background. On servers the client never sees, writing logs he'll never need to read.

Our job was to make sure none of that complexity leaked through to the people actually using the tool.

So we built a dashboard that sits on top of the entire pipeline and translates everything happening underneath into something anyone can understand and act on.

The client pastes a URL. The dashboard shows him what's processing, what's ready, what needs his attention, and what it's costing, in plain language, in real time, without a single technical term in sight.

The Overview page shows everything at a glance: total products processed, how many are pending approval, estimated time savings, recent product thumbnails, and live integration statuses. It's the first thing the operator sees when they open the tool.

The Pipeline page is where every product lives. Each row shows the product name, brand, status, and timestamps. The operator can filter by status, bulk approve, retry, or delete without leaving the page.

The Automation page is where the pipeline runs. Each agent has its own run button, or the operator can trigger the full pipeline in one click. Live logs stream below in real time, color-coded by severity. A stop button exits gracefully after the current item finishes; nothing gets cut mid-process.

Every integration the pipeline depends on is visible in one place, with live connection status. Supabase, Cloudinary, GPT-4o, SerpAPI, WooCommerce, and Yupoo — all green, all live.

The operator can adjust batch size, toggle auto-advance, and set the confidence threshold that determines when Agent 2 flags a product for human review — all without touching the code.

Team access is managed directly from the dashboard. The client runs the tool. We stay in as admins.

HolloEngine isn't a chatbot. It isn't a prompt. It's a production system — six agents, each with one job, each handing off cleanly to the next, each failing loudly when something goes wrong.

Before it existed, getting one product from a Yupoo album into a live WooCommerce listing took a skilled person 45 to 60 minutes. It required translating Chinese text, running manual reverse image searches, downloading and renaming images one by one, writing copy from scratch, and building a WooCommerce payload by hand.

Every single time.

Now it takes under three minutes, and most of that is the client entering his own prices.

67 products processed. 61 live in the store. 11 luxury brands correctly identified. 88% average image size reduction. $0.023 average cost per product. A full-time VA workflow replaced by a URL and a button.

The most important number isn't any of those. It's the one that doesn't appear in any dashboard, the hours the client got back every single week, permanently, to spend on the parts of his business that actually need a human.

That's what we build at LiftFlows. Not automation for automation's sake. Systems that take the work that shouldn't require a person and make sure it never reaches one.

If you're running a product-heavy e-commerce operation and drowning in manual content workflows, we'd like to hear about it.