I gave an AI agent a simple task: add three fields to an existing database model and write a calculation method. One model, three fields, one method. That's it.

The agent came back with a full architectural document: a new database model, a REST API with three endpoints, a Google Maps integration, a JavaScript frontend widget, and a geocoding service with Haversine distance calculations.

I rejected it. "Don't create new models. Don't create endpoints. Just the fields and the method."

The agent tried again. This time: two new models, a configuration singleton, and a public API controller.

Five iterations. Five rejections. Same fundamental mistake every time.

The Problem Isn't Intelligence — It's Memory

The agent wasn't stupid. Each design was technically sound, well-structured, even elegant. The problem was simpler and more frustrating: it couldn't learn from rejection.

Every time the agent started a new iteration, it read the original task description and the previous analysis document. What it didn't read was the conversation where I explicitly said what NOT to do.

Think about that. A human designer who gets feedback like "don't create new models" will never propose new models again. Not in the next iteration, not in the next project. That lesson is permanent. But for an AI agent operating in a pipeline, each run is a blank slate unless you explicitly wire the feedback back in.

The Gold-Plating Instinct

There's a deeper issue at play. Language models have been trained on vast amounts of technical documentation, architecture documents, and design specs. The "good" examples in that training data tend to be comprehensive, thorough, enterprise-grade designs.

So when you ask an agent to design a solution, its instinct is to produce something that looks like a proper architecture document: multiple components, clean separation of concerns, API layers, configuration models. It's optimizing for what a "good design" looks like in its training distribution.

But a good design isn't always a big design. Sometimes the right architecture is three fields and a method. The agent doesn't know that unless you tell it — and unless it remembers being told.

The Fix: Mandatory Feedback Ingestion

The solution we implemented has three parts:

1. Read the conversation, not just the documents

Before producing any output, the agent now reads the last 10 messages in the task's comment thread. This is where the human reviewer leaves feedback — the rejections, the corrections, the "I told you not to do X."

# Pseudocode
feedback = read_task_comments(task_id, limit=10)
constraints = extract_constraints(feedback)

This seems obvious in retrospect. But in a pipeline where agents pass artifacts (documents, code) to each other, it's easy to forget that the most valuable information lives in the informal channel — the comments, the back-and-forth, the human saying "no, not like that."

2. Explicit constraint sections

The agent's output template now requires two sections at the top:

  • "Constraints from the reviewer" — copy the human's feedback verbatim
  • "What this design does NOT include (and why)" — explicitly list what was excluded

This forces the agent to acknowledge the boundaries before it starts designing. It's the equivalent of a developer writing "out of scope" at the top of a design doc. If you don't write it down, it doesn't exist.

3. Self-verification checklist

Before submitting, the agent runs through a checklist:

  • Did I create any new models? Was that requested?
  • Did I create any API endpoints? Was that requested?
  • Did I add external dependencies? Were they in the requirements?
  • Does the reviewer's feedback prohibit anything I included?
  • Does this fit in 3 pages? If not, am I overdesigning?

This is crude but effective. It catches the gold-plating instinct before it reaches the reviewer.

The Bigger Lesson

We talk a lot about AI agents being "autonomous" — capable of completing tasks end-to-end without human intervention. But autonomy without feedback integration is just a loop. The agent does the thing, the human rejects it, the agent does the same thing again.

Real autonomy requires three capabilities:

  1. Do the work — generate the output
  2. Receive feedback — read and understand the correction
  3. Internalize the lesson — apply it to the next iteration AND to future tasks

Most agent frameworks nail #1, partially handle #2, and completely ignore #3.

The agents that will actually replace human workflows aren't the ones that produce the most impressive first drafts. They're the ones that never make the same mistake twice.

Practical Takeaways

If you're building agent pipelines:

  • Wire feedback into the input, not just artifacts. Comments, rejections, and corrections are first-class data. Your agent should read them before reading the spec.
  • Make constraints explicit in the output format. If the agent has to write "I was told not to do X" at the top of its document, it's less likely to do X.
  • Add self-verification steps. A simple checklist before submission catches 80% of scope creep.
  • Prefer small over comprehensive. Train your prompts to value minimalism. "If your design is more than 3 pages, you're probably overdesigning" is a surprisingly effective instruction.
  • Track rejection patterns. If the same agent gets rejected for the same reason across different tasks, the problem is in the prompt, not in the task.

The five-iteration failure I described wasn't a model limitation. It was an architecture limitation — a pipeline that passed documents forward but dropped feedback on the floor. Once we fixed the plumbing, the agent got it right.

Sometimes the smartest thing you can teach an AI is how to listen.

Building AI agent pipelines that actually learn from mistakes. More at [blog link].