Agent 13 · Customer Review Intelligence Agent
How a three-block output schema and a stateless single-turn architecture transforms unstructured customer feedback into a prioritised product report — every time, without analyst overhead.
The Problem
Customer reviews are one of the richest and most underused data sources in retail. A product with 200 reviews contains granular, unsolicited feedback on quality, sizing, delivery, and customer service — but extracting actionable signal from that volume requires either an analyst's time or a purpose-built NLP pipeline.
Most product teams end up reading reviews manually, eyeballing a star rating, and trusting instinct for prioritisation. The pattern recognition is slow, the clustering is inconsistent, and the business actions are rarely written down in a way that connects cause to consequence. High-signal feedback becomes low-impact noise.
Design Approach
Agent 13 is deliberately stateless — no conversation history, no follow-up turns. Each batch of reviews is a single API call that returns a complete, self-contained insight report. This keeps the architecture simple, the latency low, and the output predictable.
The core design decision was to enforce three output blocks, always: a sentiment summary, a ranked list of clustered themes, and a set of recommended actions. These map directly to the three questions a product manager actually needs answered — what is the overall mood, where are the recurring patterns, and what should we do about it.
PERCENT field — an integer representing each theme's share of total reviews. This drives the proportional frequency bar rendered in the UI, giving teams an immediate visual read on relative issue weight without needing a data visualisation tool.
The input is a textarea rather than a single-line field — a deliberate departure from Agent 11's pattern. Review batches are multi-line by nature, and the UX should reflect that. The send button is labelled "Analyse" rather than "Send" to signal that this is an analysis task, not a conversation.
System Prompt Architecture
The system prompt defines three delimiter blocks — ===SUMMARY===, ===THEME===, and ===ACTIONS=== — each with explicit named fields. The frontend parses each block independently and renders them as distinct UI components: sentiment pills, frequency-bar theme cards, and a gold-accented action panel.
Summary Block
POSITIVE / NEGATIVE / MIXED counts plus a HEADLINE — one sentence that captures the dominant signal across the full batch. This gives stakeholders a one-glance read before diving into themes.
Theme Block
Repeated 3–5 times, ranked by frequency. Each theme carries a NAME, FREQUENCY (human-readable), PERCENT (integer for the UI bar), SENTIMENT, and a FINDING capped at 40 words — enough to explain without burying the point.
Actions Block
2–3 bullet-point actions written in business language. The prompt instructs each action to start with a verb, name the theme it addresses, and state the expected impact — preventing vague recommendations like "improve quality."
Theme Deduplication Rule
An explicit prompt rule prevents semantic duplicates — "Delivery Speed" and "Shipping" cannot both appear as themes. Without this constraint, the model produces overlapping clusters that inflate theme count and dilute signal.
What I Learned
Batch input changes the UX contract. When input is long-form rather than conversational, the interface needs to reflect that — the textarea, the "Analyse" button label, and the user message preview (showing a review count rather than raw text) all reinforce that this is a structured analysis task, not a chat.
Frequency bars are earned, not free. The proportional bar visualisation requires the model to output a numeric PERCENT field in addition to the human-readable FREQUENCY string. This is a deliberate split — one field for display logic, one for humans — and it has to be specified explicitly in the system prompt or the model conflates them.
The deduplication rule is load-bearing. Without it, the model consistently produces near-duplicate themes in testing — particularly around quality, durability, and materials, or delivery, shipping, and fulfilment. A single explicit constraint in the prompt eliminates the problem entirely.
Stateless is a feature here. Unlike a conversational agent, review analysis doesn't benefit from multi-turn context. Each batch is independent. Keeping it stateless reduces complexity, improves latency, and makes the output more predictable — every run is a clean slate.
Typical Token Profile
A batch of 10–12 reviews analysed in a single call typically produces: