Feedback Loop Engineering: making your project agent-ready

Most of the energy in agentic coding today goes into a single question: how do we make agents do what I want autonomously and effectively? We write a sharper prompt, choose a stronger model, or add a better skill for the task at hand. All of this helps, but it is but a drop in the ocean compared to what's possible.

We've started calling the bigger picture feedback loop engineering: the practice of designing the loops around your agents so that each run improves the conditions for future runs. It gives a name to work many teams are already doing, and draws attention to a middle layer that is still often missing.

Three loops

Feedback loops sit at different tiers according to how quickly they can see and address a problem.

The inner loop operates over a single change. It contains the quality gates you probably already have in your projects: tests, typing, linting, PR review and the back-and-forth of review comments. Its job is to stop a bad change before it lands. This is where most teams start.

The middle loop operates across the project and its history. This is where maintenance agents live. Some are drift loops, which find state that has gradually moved away from the project's standards, such as stale documentation, decaying tests or growing complexity. Others are retro loops, which find the same problem recurring across runs, such as a repeated review comment, flaky check or piece of agent friction. They turn what they find into corrective work for the normal development pipeline.

The outer loop reads signals from production and the business. A watcher can file work when an error rate or product metric crosses a threshold. A responder can act directly, for example by restarting a failed service. This tier checks whether the changes that passed the first two loops work in the real system.

The inner loop improves the change in front of you. The middle loop improves the conditions in which many future changes will be made. Without it, you keep paying for the same classes of mistakes in tests, review time and failed runs.

Make the project agent-ready

The target of the middle loop is the software project. A maintenance agent notices where agents repeatedly struggle in your repository, then routes corrective work through the normal pipeline so future runs have an easier time. The agent platform may be exactly the same before and after.

This distinction affects how you frame the goal. A loop starts from evidence in the project, such as agent logs, recurring PR comments or an analysis of its architecture, and asks how the project should change in response. That might mean removing a recurring source of friction for future agents, keeping the architecture healthy as the codebase grows, or improving the documentation, tests and tools. The data makes the goal specific to the project.

This becomes more important as agents write a larger share of the code. Each run is focused on its own task and may not see the structure emerging across ten or twenty changes. No individual change needs to be obviously bad for duplicated logic, inconsistent abstractions or stale guidance to accumulate. The middle loop gives the project a way to reflect on its own state and history.

How a maintenance agent works

A maintenance agent can run once or on a schedule. In our case, it may start from a recurring ticket or a scheduled run. It analyses one focused set of data, writes a short report and files ordinary issues for the work that report implies.

Those issues then enter the same pipeline as human-filed work. In our setup, the maintenance run does not open its own PRs. Its job is to turn noisy evidence into well-scoped work that the rest of the system can solve.

The first runs still need human judgement. We run a new loop once by hand and read every issue it files. If the signal is useful, we schedule it; if the fixes are small and mechanical, we may later allow them to merge automatically. Measurement of loop health is still work in progress. We need to know when a loop is noisy, when its findings are ignored, and whether the corrections improve the project over time.

To put some scale on this, at Tessl we run four maintenance agents daily. Each files roughly two issues per run, and we have accumulated around 500 issues tagged as maintenance-origin. We have also tried deeper, less frequent runs. One audit of Kikimora examined 1,102 commits, review threads from 400 merged PRs, CI runs, agent transcripts and 108 supervision sessions. It produced 63 findings, and 86% of the findings we triaged were dispatched as work.

The data sources are the whole game

Any feedback loop is only as good as what it reads and what that source can tell it. Some of the most useful sources we have found are:

• Agent logs. These show where agents spend too many turns, retry an operation or repeatedly get confused. An early retro loop found that agents kept re-deriving how to use Linear's API. The resulting issue led to a small CLI that made the operation faster and more reliable for every later run.
• Recurring review comments and CI failures. Repeated feedback is evidence that a convention lives too late in the process. A retro loop can propose the cheapest durable fix: perhaps a lint rule, verifier, test or piece of guidance.
• The repository's current state. Drift loops compare code-derived facts with documentation, inspect architecture against the project's own principles, or use coverage and mutation testing to find weaknesses in the test suite. These checks are often too heavy for every PR but work well on a cadence.
• Production telemetry. Errors, incidents and product measurements feed the outer loop. They can create work when a live signal moves outside the range the team expects.

These sources describe different problems. A spike in agent turns suggests friction; stale documentation is drift; a recurring CI failure suggests a missing guardrail. The quality of the loop depends on making that interpretation explicit.

Getting started

If you want to build a feedback loop, you need three things:

1. A good data source. This might be agent logs, PR and CI history, an architecture analysis, or another view of the project's current state.
2. A clear understanding of what that source reveals. Repeated agent confusion, documentation drift and growing architectural complexity are different signals and lead to different corrections.
3. A clear goal for what should improve. The loop might aim to remove a recurring source of friction, restore documentation to match the code, or keep the architecture modular as the project grows.

Start small: one narrow problem, such as documentation drift or recurring review feedback. Then run the loop once before scheduling it. Review the work it files, check that it does not duplicate existing work, and increase its autonomy only as you trust the signal. Over time, a loop stack lets the project retain what it learns: restoring standards when they drift, turning recurring problems into guardrails, and feeding production signals into future changes.