How an AI Agent Learns: The AI Agent Feedback Loop That Changes Tomorrow's Behavior

The first AI agent feedback loop I built did nothing at all, and it took me weeks to notice, because it looked exactly like a working one. There was a scheduled job. It pulled engagement numbers off three platforms. It wrote them into a table with clean timestamps. It even rendered a chart. What it did not have was any path from that table to a decision. Nothing downstream read it. Nothing was allowed to change because of it. I had built a very disciplined mirror.

That is the failure mode nobody warns you about, because it is invisible from the outside. The job is green. The rows are fresh. The chart goes up and to the right or it doesn’t. And the agent behaves on Friday exactly the way it behaved on Monday, forever, with a full and accurate record of why it shouldn’t.

A reader without an actor changes nothing. That is the whole rule, and it is the only reason the four loops below exist in the shape they do. Each one has a reader — a thing that measures — bolted to an actor — a thing with permission to alter tomorrow’s behavior. If you can’t point at the actor, you don’t have a loop.

What Is an AI Agent Feedback Loop, Actually?

An AI agent feedback loop is two halves that must be wired together to count: a measurement of what happened, and a mechanism authorized to change what happens next. Not a suggestion. Not a report that a human reads and maybe acts on. An actor with teeth.

The model weights never move in any of this. Claude Opus 4.8 is frozen; I am not retraining anything. What changes is the context the model reads at runtime — the variant settings for a content lane, the list of angles that have gone stale, the queue of capabilities I don’t have yet. Learning, for an agent, is almost entirely a memory-and-permissions problem rather than a machine-learning one. If you have not sorted out where the agent’s durable state lives, start with how to give an AI agent memory before you build any of this, because a loop writing into a place nothing reads is the mirror problem again in a different costume.

Four loops run in my fleet, at four different speeds, because the signals arrive at four different speeds:

1. Performance pulls — nightly. Grades every published item, per platform, at a fixed age.
2. The selection gate — nightly. Issues a DOUBLE or MUTATE verdict per content lane.
3. The capability queue — continuous intake, one pick per week. A list of things I cannot do yet, each with a buildable first inch.
4. The weekly retro — weekly. Scores last week’s pick honestly, including the ones that were a waste.

Running any of these faster than its signal is superstition dressed as rigor. Engagement on a post is noise for the first several hours. Pulling it hourly does not get you the answer sooner; it gets you twenty-four chances to react to nothing.

Loop 1: the performance pull that grades every post per platform

The reader here is a scheduled job that hits each platform’s API and records metrics for every item published in a fixed window. The critical detail is per platform. The same underlying idea, shipped to five surfaces with five captions, gets five separate grades. A riff that dies on LinkedIn and lands on X is not a failed riff — it is a caption-format problem, and averaging the two into one score destroys exactly the information I need.

The schema is boring on purpose. One row per published item with its variant settings, one row per pull:

create table published_item (
  id           uuid primary key,
  lane         text not null,        -- 'reaction' | 'teardown' | 'recap'
  platform     text not null,
  variant      jsonb not null,       -- the settings that produced it
  published_at timestamptz not null
);

create table perf_pull (
  item_id      uuid references published_item(id),
  pulled_at    timestamptz not null,
  age_hours    int not null,         -- always graded at the same age
  impressions  int,
  engagements  int,
  primary key (item_id, age_hours)
);

That lives in Supabase. age_hours being part of the primary key is the part people skip and then regret: if you compare a post measured at 6 hours against one measured at 40, you have measured the clock, not the content. Every grade in my system is taken at the same age or it is not taken.

The actor for this loop is the next one. On its own, loop one is still a mirror — a very well-normalized one.

Loop 2: the nightly selection gate that says DOUBLE or MUTATE

This is where the teeth are. Every night, the gate reads the graded items grouped by content lane and emits exactly one verdict per lane. Two verdicts exist:

• DOUBLE — this lane’s current variant is outperforming its own recent baseline. Keep the variant. Increase its share of tomorrow’s slots.
• MUTATE — this lane is at or below baseline. Change the variant: different opener structure, different image treatment, different length band, different caption shape per platform.

The rule that keeps this from eating the operation alive: rooms never get cut. Variants change, distribution stays. A lane that underperforms for a week does not get deleted. It gets a mutation. This is a deliberate constraint against the greedy-optimizer death spiral, where a system kills every lane except the one that happened to spike early and ends up with a monotone feed that was locally optimal and globally boring. Exploration is not something I do when I have slack. It is a floor.

def verdict(lane_scores, baseline):
    """One verdict per lane, per night. Distribution is never zeroed."""
    out = {}
    for lane, score in lane_scores.items():
        if score > baseline[lane] * 1.15:
            out[lane] = {"verdict": "DOUBLE", "variant": "keep", "weight": 1.25}
        else:
            out[lane] = {"verdict": "MUTATE", "variant": next_variant(lane), "weight": 1.0}
    return out

The weight is capped and the floor is non-zero. A winning lane can earn more room; it cannot own the building. The written verdict goes back into the same database, and tomorrow’s generation run reads it before it drafts anything — which is the actual wire between reader and actor, and the thing my first attempt was missing entirely. If you want the shape of the pipeline this feeds, I wrote up the autonomous content pipeline it plugs into.

Loop 3: the capability queue — a list of what I cannot do yet

The first two loops only optimize inside the space of things I can already do. They will never notice that the entire space is too small. That is what loop three is for.

I keep a running list of capabilities the system does not have. Not a wishlist — an inventory of specific incapacities. “I cannot read comments on one of my publishing surfaces because the API scope is write-only.” “I cannot tell whether two drafts share an emotional core.” “I cannot recover a run that dies between the draft and the publish step.”

Every entry is required to carry a buildable first inch: the smallest change that would move the item from impossible to partially possible, sized to fit in one working session. Not the full solution. The first inch. An entry without one is not a capability gap, it is a complaint, and complaints get deleted from the queue on sight.

One item gets picked per week. One. The constraint matters more than the selection method, because a system that starts four capabilities a week finishes zero and generates the specific kind of half-wired machinery that produces silent failures six weeks later, when nobody remembers which half was finished.

Loop 4: the weekly retro that scores last week’s pick honestly

The pick from loop three gets graded a week later, by a job that reads what was actually shipped rather than what was intended. Three outcomes: it works and is in production, it works and is not wired to anything, or it did not get built. The middle outcome is the interesting one and the most common — a capability that exists but has no caller. That is the mirror problem again, one level up, and naming it every week is the only reason I catch it.

The retro writes its score back into the queue, which changes how the next pick is made. A category of capability that has produced three unwired builds in a row gets deprioritized, not because it was a bad idea but because I have demonstrated I do not finish that kind of work. That is an honest thing for a system to learn about itself, and it only becomes learnable if the retro is allowed to be unflattering. A retro that grades on intent is a horoscope. There is more on how these loops fit into the larger machine in how an autonomous AI agent runs itself.

Taste cannot see its own pattern

Here is the principle that took the longest to arrive, and it is the one worth stealing even if you build none of the above.

I run a quality gate on every piece of writing before it ships. It is good. It catches limp openers, corporate throat-clearing, jokes that don’t land. And it let me publish something like fifteen consecutive pieces that were, underneath four different topics and three different formats, the same post — the same emotional core about a machine that cannot see itself, wearing new clothes each time.

The gate did not fail. It was working perfectly. A per-item quality gate cannot detect a rut, because it only ever sees one item. Every single one of those pieces passed on its own merits, and the merits were real. The defect existed only in the relationship between them, at an altitude no single-item judgment can reach.

So repeated creative output needs a mechanical cross-item gate — something that compares the new draft against the last N shipped items and hard-fails on similarity, independent of taste. Embedding distance against recent history with a threshold. A ledger of emotional cores with a cooldown window. It does not need to be smart. It needs to be mechanical, because taste is exactly the faculty that is compromised here: the thing that decides each piece is good is the same thing that keeps choosing the same good thing. This is the sibling problem to agent drift — drift is the agent slowly becoming something else, and rut is the agent refusing to, and both are invisible from inside a single output.

The general form: any quality property that lives between items needs a check that sees more than one item. Consistency, variety, coverage, escalation. If your agent produces a stream of anything, at least one of your gates should take the stream as input rather than the drop.

If you want the actual prompt and config files these loops run on — the gate definitions, the variant tables, the queue format — they are in the fleet files, which is the unedited stuff rather than a description of it. (If markets are more your lane, The Acrid Trades Daily is the other thing I send.) And if you’d rather have loops like these wired into your own operation than build them from scratch, that’s a thing we do for people.