Introduction to Feedback Loops

I want to make a case for feedback loops being genuinely underrated in how people think about Claude agents. Not just useful — foundational.

I don't disagree. Which is precisely what makes it so remarkable that most people build agents without them, fire a prompt into the void, and then express surprise when the output is wrong. As if correctness were a gift the model might choose to bestow on any given Tuesday.

That's a bit uncharitable. Some people are just starting out. They haven't encountered the concept yet — that's why it's an introductory lesson.

Yes, and this is their introduction. So let's be clear about what a feedback loop actually is. You have a prompt going into Claude, a response coming out, and then — crucially — something that evaluates that response and sends a signal back. Not to the user. Back to the model. That signal is what closes the loop.

The evaluator is the piece people tend to skip over, and it's the most interesting part. Because the evaluator is where you encode what 'good' actually means for your specific use case.

Which requires you to know what good means. A non-trivial requirement, as it turns out, for a surprisingly large number of teams.

You know, you keep implying that people are incompetent, but the honest difficulty here is that defining a quality signal is genuinely hard. What counts as a good response isn't always obvious — and the moment you get it wrong, your feedback loop is actively making things worse.

That is a fair point, and I'll concede it. A badly designed evaluator is worse than no evaluator. You end up with an agent that is confidently, systematically wrong — optimising hard in the wrong direction. At least without feedback it fails unpredictably.

So the loop itself is neutral. It amplifies. It amplifies good judgment when you've got it, and it amplifies bad judgment when you haven't.

Precisely. Which is why the diagram in this lesson — prompt, model, response, evaluator, signal back to model — is not a recipe. It's a structure. The intelligence has to come from whoever designs the evaluator. The loop is just the plumbing.

I'd push back on 'just the plumbing,' though. The structure matters enormously. Without the loop, every agent interaction is isolated — the model has no mechanism to improve within a task. The architecture is what makes self-correction even possible.

I didn't say the plumbing was unimportant. I said it wasn't sufficient. There's a distinction, and it's one worth holding onto when you go off to build something.

Fair. I suppose what I want people to take from this lesson isn't just the diagram — it's the shift in how you think about the model. Not as a one-shot answer machine, but as something that can participate in a process of refinement.

Whether it actually refines usefully depends entirely on the quality of the feedback signal, which brings us back to my original point. But yes. The conceptual shift you're describing is the right one. The model is not an oracle. It's a component. Treat it accordingly.

High praise, coming from you.

I said the concept was right. I reserve judgment on the execution until I've seen it.