The Verdict: Building an AI-powered product catalog without an engagement surface is like running a factory with no feedback loop. The agents can create indefinitely, but without hearts, shares, and community signals, you're optimizing in the dark.
Shilpiworks runs 27 autonomous AI agents that generate wisdom stickers — Stoic philosophy, indigenous wisdom, mathematics, puns, Minnesota wildlife, and more. The catalog had grown past 600 designs. The agents had rich decision traces. The outcome-collector was linking products to page views and cart adds. But there was a structural gap: the site had no way for visitors to interact beyond buying.
No share buttons. No likes. No "what's new" feed. No social proof. Every product page was a distribution dead end.
The problem wasn't content creation — it was that the architecture was one-directional.
The Missing Sensor Layer
We'd already built the context graph infrastructure — every agent run captures theme candidates, style selection reasoning, OCR attempts, and quality scores in a structured decisionTrace JSON. The outcome-collector runs nightly, linking products to performance metrics. But the sensor layer was incomplete.
Views and cart adds are lagging indicators — they only fire when someone is already deep in the funnel. What was missing: lightweight engagement signals from the much larger pool of visitors who browse but don't buy. Hearts, shares, and fresh-feed visits are leading indicators of what resonates.
What We Built
Four features, shipped in a single deploy. Each designed for zero-friction anonymous interaction — no sign-in required.
-
Share buttons on every product. Pinterest, X/Twitter, WhatsApp, and copy-link. Pinterest matters most — it's the dominant discovery platform for visual and craft products. Each share fires a
ProductEventwith typeshare_pinterest,share_twitter, etc. No schema migration needed — theeventTypefield is a plain string. -
Anonymous hearts with HMAC fingerprinting. A visitor's browser generates a random UUID on first visit, stored in
localStorage. The server never sees this UUID directly — it hashes it with a secret key using HMAC-SHA256 to produce afingerprint. This fingerprint is stored in a newProductReactiontable with a unique constraint on(productId, fingerprint, reactionType). One heart per visitor per product, privacy-preserving, no authentication required. -
"Fresh from the Studio" feed. A dedicated
/freshpage showing the 30 most recent products with agent attribution — "Created by the Stoic Philosophy agent" — plus relative timestamps, hearts, and share buttons. A stats banner at the top shows total designs, new this month, and new this week. This makes the site feel alive and gives visitors a reason to return. -
Trending strip on the homepage. A weighted engagement score determines which products surface:
hearts × 3 + views × 1 + cart_adds × 5 + shares × 4. The weights reflect signal quality — a cart add is a stronger intent signal than a page view, and a share indicates someone found it worth distributing.
Key point: The engagement layer doesn't just add social proof for visitors — it creates the demand signal that the context graph was missing. When Phase 3 of the agent intelligence roadmap lands, agents will query which themes and styles produce the most hearts and shares, not just views.
The Migration Trap We Avoided
In February 2026, we lost 590+ products by running raw SQL through a Prisma Data Platform proxy. That incident established hard rules: never run prisma migrate against the proxy, never use $executeRawUnsafe, never DROP TABLE without a verified backup.
For this deploy, the new ProductReaction table needed a migration. The safe path:
- Handwrite the migration SQL —
CREATE TABLEand two indexes. Additive only, noALTERorDROPon existing tables. - Skip
prisma migrate dev— it tries to create a shadow database against the proxy and fails withP3006. - Let the build pipeline handle it — the
package.jsonbuild script already runsprisma generate && prisma migrate deploy && next build. The migration file gets picked up automatically on the next Vercel deploy. - If it fails, the old deployment stays live — Vercel only promotes a new deployment if the build succeeds.
The entire migration was three SQL statements. No drama.
Architecture Decisions Worth Noting
-
Anonymous-first, not auth-required. The existing
Usermodel with NextAuth is available, but requiring sign-in for hearts would have killed engagement. The HMAC fingerprint approach gives us deduplication without friction. Authenticated users can optionally be linked later via the nullableuserIdfield. -
ProductEventfor shares, new table for reactions. Shares are fire-and-forget events — you don't un-share something. Hearts are toggleable state. Different access patterns warranted different storage: append-only events vs. upsert/delete reactions. -
Server-side rendering for the Fresh feed, client-side for hearts. The
/freshpage is a server component that queries products joined withAgentRunfor attribution. Heart counts are fetched client-side via a batch GET endpoint to avoid hydration mismatches and keep the page statically cacheable.
What's Next
Phase 2 of the engagement roadmap adds community voice: quote submissions (visitors suggest quotes for agents to turn into stickers) and agent voting (which of the 27 agents should create next). Phase 3 adds distribution: email digest, embeddable quote widget, and a weekly agent report card.
The strategic bet is that community preference data compounds differently than AI-generated content. Any competitor can spin up image generation. What they can't replicate is a feedback loop where thousands of hearts and shares have shaped which themes, styles, and quotes the agents prioritize — over months and years.
Key Lesson: An AI product pipeline without an engagement surface is a content factory disconnected from demand. The hardest part wasn't building hearts and shares — it was recognizing that the architecture needed a return path, not just more forward throughput.