The Feedback Loop
Accept, modify, reject. One pattern, three signals, three simultaneous outputs. I kept collapsing this into "we have a like button" and paid for the collapse for years.
Why this is the product
I used to think of feedback as a feature — something you add after the core product works, to capture user sentiment. Then I read the thermodynamic argument and it inverted for me. The feedback interaction is not a feature bolted onto an AI product. It is the product. Everything else is scaffolding around the moment when a human decides what to do with an AI proposal.
The Demon Principle gives the thermodynamic version of this claim. This module is the operational version — what the feedback loop actually looks like in practice, and why accept/modify/reject is the specific shape that works.
The shift the pattern forces
The old interaction model: human creates the record, system stores it, AI enriches if convenient. The AI output is optional, unvalidated, and disconnected from any learning signal. This is most software with "AI features" bolted in.
The new model: AI proposes, human decides (accept, modify, or reject), system captures the decision. The AI output is primary. The human's decision is the thing that becomes the record. The delta between what the AI proposed and what the human chose is a first-class signal, not telemetry to be discarded.
This shift is load-bearing for the rest of the architecture. If the product isn't built around decision points, the feedback has nowhere to live. If the decision points exist but aren't captured, the platform has closed the loop cosmetically but not structurally. The feedback loop is a structural property, not a feature.
Three actions, three different signals
The three-action model isn't arbitrary. Each action produces a different kind of signal, and collapsing them loses information that is hard to recover.
Accept is a strong positive signal. The AI got it right. Not just "good enough" — correct, as the human assessed. Acceptance rates calibrate confidence scores (if the model says 90% confident and acceptance is 60%, the model is overconfident). Accept data validates the skill's current state.
Modify is the strongest training signal of the three. The AI was close but the human changed it. The delta between what the AI produced and what the human shipped is exactly what the model needs to learn from. Not "you failed" (weak), not "you succeeded" (no improvement signal), but "you got 70% of it right, here's what the other 30% should have been." Modify actions are where the next round of skill improvement comes from.
Reject is a negative signal. The AI output was fundamentally wrong, not salvageable by edit. Important to capture, but carrying less information than modify — it tells you the proposal failed, but not in which direction. Clustering rejection reasons reveals systematic failures and out-of-domain cases, which is useful, but the granularity is coarser than modify.
I spent a while thinking acceptance was the important metric. It turns out modify rate matters more, because it's where the improvement signal lives. High accept rate on a low-stakes skill can mean the skill is well-calibrated or that the human is rubber-stamping. High modify rate tells you the skill is in range but off in specific ways — the ways you can fix.
Three simultaneous outputs, one event
This is the pattern I covered in Triple Output from the invariant side. The operational side: a single decision event produces three artefacts in one transaction. Updated record (the canonical value changes to what the human chose). Training signal (the before/after delta goes into the optimisation corpus). Audit trail (the immutable event records who decided what, when, with what reasoning).
One event, three projections. If any projection is missing, the loop leaks. If the three are derived by separate code paths, they drift and the drift becomes undetectable until you try to use them together and find they disagree. The architectural discipline is a single write function that fans out to all three atomically.
The schema that does the work
Every feedback event captures the same shape: actor (user ID, role, org), context (case ID, entity type, entity ID), AI output (model, proposal, confidence, reasoning), human decision (action, final value, rationale, change magnitude), and signals (was it correct, what kind of correction, effort cost in seconds).
The field I see most often skipped is change magnitude. "The AI said X, the human ended up with Y" captures the fact of the delta, but magnitude — how far Y is from X — is what lets you distinguish "tweak" from "overhaul." Tweak patterns tell you the skill is close; overhaul patterns tell you it's in the wrong paradigm. Both are worth knowing.
Effort cost — seconds from the AI output appearing to the human making a decision — is another field I used to skip. It turns out to be one of the most useful metrics: a skill where acceptance is 80% but effort cost is 45 seconds is not a good skill. The human is doing work to approve it. A skill where acceptance is 75% but effort cost is 5 seconds is doing most of the work on its own.
From feedback to the optimisation loop
Every feedback event flows into three optimisation surfaces. Model selection — which LLM performs best on this decision type, at what cost. Confidence calibration — does the model's confidence score match actual agreement rate? Prompt / skill improvement — what language or context reduces the modify rate?
This is the loop from the Optimisation Loops module viewed from the input side. Feedback is the fuel. Raw traces and before/after deltas are what the meta-agent reads. Without rich feedback capture, the optimisation loop has nothing to optimise against, and the platform is stuck in whatever state it shipped in.
The investment order I now use
The counterintuitive principle: invest in feedback UX before investing in AI model quality. I got this wrong for years. I kept pushing model quality up, squeezing more accuracy from prompts and model selection, and the platform still felt stuck. Then I put the same hours into the feedback surface and everything started moving, because the optimisation loop finally had signal to work with.
Poor model quality plus rich feedback improves rapidly and becomes good. Good model quality plus poor feedback stagnates and drifts. The asymmetry is striking once you see it. If you're at the start of a new AI platform and have to pick one thing to polish, polish the feedback capture. The model can be commodity.
Anti-patterns I've now learned to spot
Accept/reject only, no modify. You lose the delta signal. Modify is ten times more valuable than accept and reject combined.
Optional feedback. If it's optional, humans skip it under time pressure. The feedback has to be required at the decision point, or it stops being a product and becomes a request.
Binary thumbs up/down. You need the rationale and the delta, not just a sentiment. Thumbs up/down is the decoration pattern from the Triple Output module in a new outfit.
Feedback without a visible optimisation loop. If users give you feedback and they never see the system get better, they stop giving feedback. Close the loop visibly — show that corrections improved the next result.
The product IS the feedback loop. Everything else is in service of it.
Want to think through how this lands in your project? Tell kr8 what you’re working with.
// Keep reading the playbook?