Overview
Revenue Recovery Engine (RRE) turns a slow, manual product-listing audit into a paste-a-URL workflow that gives a merchant specific description fixes to reduce returns. It runs as a multi-agent pipeline — scrape, critique, prescribe — built at PM Accelerator, where I served as Technical Lead.
The Problem
Auditing a product listing for the kind of gaps that lead to returns — missing details, ambiguous sizing, unclear specifications — is slow and inconsistent when done manually. Merchants needed something faster than a manual review, but generic AI feedback isn't useful either: what actually helps is specific, actionable description fixes tied to real evidence from the listing and its reviews.
Architecture
Scraping (via Apify), critique, and prescription run as a scrape → critique → prescribe pipeline, with Gemini powering the LLM reasoning and Supabase/pgvector plus Zod schemas underpinning the data and validation layer. Because the full multi-agent workflow risked exceeding the serverless platform's execution-time limit, the pipeline runs as a series of durable Inngest steps rather than a single long-running request — each stage executes independently while Inngest coordinates the overall process.
Approach & My Role
As Technical Lead, I defined the boundary between LLM reasoning and deterministic logic, and set the step-based pipeline pattern the team built around. That included helping structure the workflow into durable Inngest steps so the pipeline could operate within the platform's execution constraints, and coordinating the implementation across the team so everyone understood the stage boundaries, inputs/outputs, and responsibilities of each part of the workflow.
Technical Decisions
Keeping scoring and yes/no decisions in code, not the LLM
Scoring and pass/fail decisions run in code rather than being left to the LLM, so results can't be invented — the model contributes reasoning and drafting, but the decision that has to be right stays deterministic and auditable.
Splitting the workflow into durable Inngest steps
Running the entire multi-agent workflow inside a single request risked hitting the serverless platform's execution-time limit. Structuring it as durable Inngest steps let each stage execute independently while the overall process stayed coordinated — the harder part wasn't adopting Inngest, it was deciding where the step boundaries should go so the workflow stayed understandable and reliable without turning every small operation into its own step.
Challenges
The main challenge was designing the multi-agent workflow around the platform's hard execution-time constraint. With scraping, critique, and prescription as separate stages, trying to run the whole thing inside one request risked exceeding the limit — so as Technical Lead, I had to help decide where the step boundaries should sit, balancing reliability against turning the workflow into an unmanageable number of tiny steps.
That decision also had to be communicated and coordinated across the team, so everyone building different parts of the pipeline understood the stage boundaries, inputs and outputs, and where their piece's responsibility started and ended.
Results
RRE was successfully structured as an end-to-end multi-stage system rather than a single long-running request — the scrape → critique → prescribe pipeline could move through durable Inngest steps, letting the multi-agent workflow operate within the serverless platform's execution constraints. As Technical Lead, the outcome I'd point to is the workflow structure itself: a workable agentic architecture with clear stage boundaries, coordinated reliably across a team.
Lessons Learned
The biggest lesson was that workflow architecture matters as much as agent design in a production-oriented agentic system — the LLM agents were only one part of the problem; the system also needed clear stage boundaries, durable execution, well-defined inputs and outputs, and coordination across the team building it.
If I did this again, I'd define the workflow boundaries and contracts between stages even earlier, which would make parallel development easier and reduce ambiguity about where responsibilities belong. Leading the project also taught me that being Technical Lead isn't just making technical decisions — it's making the architecture understandable enough that multiple people can implement different parts of it consistently. The broader lesson: agentic systems need orchestration designed around the constraints of the runtime, not just around what the agents can theoretically do.
Tech Stack
GitHub & Demo
Private project — built for PM Accelerator, code isn't publicly shared.