Designing AI product feedback loops.

What a feedback loop has to do

A feedback loop turns how people respond to AI output into specific fixes, and proves each fix worked. It has five stages: capture a signal, link it to the exact output and system version, classify it, investigate and fix, then add a regression case so the problem cannot quietly return. Most products build the first stage, a thumbs button, and stop.

Feedback from end users complements the controlled signals you already have. Reviewer decisions in a human review queue are expert labels on sampled outputs; user feedback covers the whole user base but is noisier and self-selected. Use both.

Which signals to capture

Google’s People + AI Guidebook distinguishes implicit feedback, data about user behaviour from product logs, from explicit feedback, where users deliberately comment on output. Capture both, and weight them by strength and bias.

Downstream outcomes are worth the integration effort: an invoice coded by the system and later reversed by the accountant, a support ticket reopened within a week, a drafted email the customer replied to with confusion.

A fixed feedback taxonomy

Classify every negative signal with a short, fixed set of reason codes, each mapped to the part of the system that usually owns the fix. Free text alone cannot be counted or trended.

Keep it to around ten codes. When “other” grows past a fifth of negative feedback, read it and split out a new code.

Capture design

Every feedback event must point at the exact output and configuration that produced it, or it cannot be investigated.

from dataclasses import dataclass
from difflib import SequenceMatcher
from typing import Literal

Signal = Literal["thumbs_up", "thumbs_down", "edit", "regenerate",
                 "copy", "send", "escalate", "abandon"]

@dataclass
class FeedbackEvent:
    trace_id: str              # links to input, retrieved sources and output
    config_hash: str           # prompt, model and index versions that produced it
    signal: Signal
    reason_code: str | None    # from the fixed taxonomy
    comment: str | None
    final_text: str | None     # the user's edited version, for edit events

def edit_ratio(ai_text: str, final_text: str) -> float:
    """0.0 means sent unchanged; 1.0 means fully rewritten."""
    return 1.0 - SequenceMatcher(None, ai_text, final_text).ratio()

Interface choices decide data quality. Offer reason codes as one-tap options after a thumbs-down rather than a form. Capture edits automatically wherever the user can modify output before it goes anywhere. Do not interrupt every interaction to ask for a rating; a small random sample of prompts gives better data than constant nagging. Trace linkage depends on the logging covered in AI audit logs.

Measure the quality of the feedback itself

Feedback is data with its own error rate. Measure it before you trust it.

If negative feedback does not move when audited error rates do, the channel is measuring mood rather than quality. The audit side needs a consistent standard too; our AI quality review checklist gives reviewers one to score against. Report these alongside the quality metrics in monitoring AI quality.

Closing the loop

1. Triage weekly. Cluster new negative signals by reason code and configuration hash; read a sample from each cluster.
2. Confirm. Reproduce the problem from the trace. Many complaints are about expectations, not errors, and those go to product or training.
3. Fix at the right layer. Data, retrieval, prompt, tools or model, guided by the reason code.
4. Add a regression case. The confirmed example, anonymised where needed, joins the evaluation set as a new dataset version; see versioning prompts and evaluations.
5. Release and verify. Ship through the normal gates, then check that the signal for that cluster actually fell.

Illustrative example: a quoting assistant’s weekly triage shows a cluster of edits where staff change the GST line. The traces show the assistant treating supplier prices as GST-exclusive when the price list states them inclusive. The fix belongs in the data (label the price list) and the prompt (state the rule), and twenty confirmed cases join the evaluation set. The next week, edits on GST lines should fall; if they do not, the fix was wrong.

Building the evaluation set that receives these cases is covered in AI agent evaluations.

Training on feedback: consent, bias and poisoning

Feeding feedback straight into model training is usually the wrong first move. It inherits every bias in who gives feedback, it can be gamed, and OWASP’s 2026 Top 10 for LLM applications lists data and model poisoning as a risk in its own right. Optimising for thumbs-up also tends to reward agreeable, longer answers over correct ones.

Consent matters as much as technique. Under the Privacy Act 2020, people should be told what their information will be used for, and reusing it for a different purpose raises its own questions. Singing Coach AI, Levy Street’s vocal coaching app, takes the conservative route: model training is opt-in and off by default.

Where feedback loops go wrong

Running this loop week to week is a core part of managed AI operations.

• Explicit and implicit signals are both captured, including edits and downstream outcomes
• Every feedback event carries a trace ID and configuration hash
• A fixed taxonomy of about ten reason codes is in use, each mapped to a fix owner
• Reason codes are one tap away after a negative signal; ratings are sampled, not constant
• Coverage, representativeness, triage precision and agreement with audits are measured
• Negative feedback is triaged weekly, with alerts for sudden spikes
• Every confirmed issue ends with a fix and a regression case in a new dataset version
• Users are told how feedback is used; any training use is opt-in, filtered and tested
• Feedback comments are protected and retained like other personal information

Written by the Levy Street team in Wellington. Last updated 19 October 2026.