AgentReady — Project Story

Inspiration

Shoppers are quietly changing how they buy things. Instead of typing "running shoes size 10" into a search bar, they're asking AI assistants real questions — "I'm training for a half marathon in Singapore's humid weather and need lightweight shoes under S$200." That's not a keyword. It's a full sentence with a use case, a constraint, and a climate condition baked in.

Most brand content was never written to answer that. It was written for a human skimming a product page, or for SEO. The gap between how products are marketed and how AI agents actually reason about them is the exact problem we set out to close — not by writing better marketing copy, but by giving brands a way to see how ready their content is for an agent, fix it, and prove it's trustworthy enough to publish.

What it does

AgentReady is a pipeline, not a single feature:

Scores every product's AI-readiness — completeness, intent coverage, evidence, freshness — with a transparent, checkable number instead of a black box.
Reasons over real shopping questions live, using AI to judge fit against a product's actual structured content (personas, use cases, benefits, trade-offs) instead of keyword matching — and it's honest enough to say "no confident match" rather than force a bad recommendation.
Fills gaps in a raw, bare-bones catalog using AI, then shows exactly what it drafted in an editable table before anything is treated as final — a human stays in the loop by design.
Finds patterns across many shopping questions at once, surfacing the specific content gaps that block the most queries, so a brand knows what to fix first.
Publishes the result the compliant way — real schema.org JSON-LD, a neutral agent-readable feed, and an adapter aligned to OpenAI's Agentic Commerce fields — with a trust checklist confirming nothing published is hidden or invented.

How we built it

The frontend is React 19 + Vite, with its own scoped design system for the AgentReady feature so it never collides with the rest of the app. The backend is a small Express server whose only job is being a safe, stateless bridge to OpenAI — every catalog and product lives in the client, nothing sensitive or heavy sits server-side.

Four distinct AI calls power the pipeline: intent extraction from a query, relevance judgment against real product content, one-sentence recommendation summaries, and catalog field drafting on import. Every single one of them has a deterministic fallback wired in — if a network call fails or times out, the feature degrades gracefully instead of breaking, which mattered enormously for a live demo.

The Publish layer reuses the same product data everything else in the app already has — no separate database, no duplicated catalog — it's generated on the fly from whatever's currently loaded, so what you publish is provably the same thing the rest of the app is showing you.

Challenges we ran into

The hardest problem wasn't calling an LLM — it was deciding what an LLM should never be allowed to do on its own. Early on, the ranking engine matched queries against a fixed, hand-coded vocabulary of signals. It worked for the demo catalog, but the moment we imported a new product with content in its own words, none of it matched — the system had no way to reason about content it hadn't been explicitly coded to recognize. We rebuilt the ranking step to judge relevance against a product's actual content directly, which meant solving a harder problem: how do you let AI reason freely without letting it invent facts about a product that aren't there? The answer was strict, over-specified prompts, server-side validation with safe defaults instead of hard failures, and keeping every AI-drafted field visibly marked as such until a human confirms it.

We also had to get comfortable with AI saying "I don't know." An earlier version of the scoring formula quietly treated an unrecognized shopping category as a match for everything, which meant a completely unrelated question would still confidently recommend a product. Catching that meant deciding that an honest "no match" is a better outcome than a confident wrong one — even though it's a harder thing to demo.

Accomplishments that we're proud of

Every part of this actually runs on live AI, tested against real queries, including ones nobody wrote in advance — and it never hard-fails, because every AI-powered step has a working fallback behind it. We watched a bare-bones imported catalog's readiness score jump from the 30s into the 90s live, driven entirely by AI-drafted content a human could still inspect and edit before trusting it. And the Publish page generates real, valid structured data — not a mockup of what publishing might look like, but the actual JSON-LD and feed formats a brand's engineering team could use today.

What we learned

The line between a genuinely useful AI-commerce tool and a manipulative one isn't about how much content AI generates — it's about whether that content matches what's visibly true, stays inspectable, and never asks an agent to trust something a human hasn't seen. We considered and rejected a version of this feature that would have hidden AI-generated text from human shoppers, and that decision shaped everything that came after it. A tool that helps agents find products responsibly has to be honest with the agent, honest with the shopper, and honest with the brand — all three, all the time.

What's next

Real persistence and a brand's actual PIM/commerce connector instead of a stateless demo. A proper approval workflow so AI-drafted content has a real sign-off step before publishing, not just a visible flag. Scaling the query-simulation step from a handful of golden queries to real logged shopper questions. And extending the relevance engine with semantic retrieval so it scales to catalogs far larger than a demo can show.