Troels Frimodt Rønnow

The first thing most engineers do with an agent framework is build an assistant. A general one. They point it at the repo, write a prompt that says something like "help me ship faster," and spend an afternoon being impressed. A week later they have quietly stopped using it. A general assistant is a chat window with extra steps, and you already had a chat window.

The interesting work is the opposite of that. Pick one task you do every week and resent, and build an agent that does only that task — and is forbidden from doing anything else.

I keep seeing this pattern, and it keeps working. One builder, writing for Learn With Me AI, wired up a system to hunt for startup ideas: a small group of agents, fixed rounds, a fixed turn order, each one locked to a single role it argues without mercy. Another, in a piece on the AI Maker newsletter, built an agent that reviews the SEO layer of a finished blog post — metadata, slug, alt text, internal links — and is explicitly barred from rewriting the essay. Different domains, same shape. One agent, or one tight team. One job. Hard rules about what it must not touch.

The thing that makes these work is not the model. It is the scope.

Scope is the feature, not the limitation

The SEO agent is useful precisely because it ships with a list of what not to touch. The idea tournament is useful because the proposing agent cannot see the critic's verdict until its spec is already built — so it cannot quietly soften an idea to dodge a kill it can smell coming. Strip the constraints out of either system and you are left with a worse general assistant.

This is the part engineers get backwards. We treat scope as the thing we settle for because the model is not good enough yet. It is the other way round. Scope is what makes the output trustworthy enough to use without watching. A narrow agent earns the right to run unattended because its blast radius is small and its job is verifiable. A general one never does, which is why you keep it in a chat window where you can supervise every token.

The agent I would build first

Here is an agent I would build before any general "code helper": a migration safety checker.

Most teams have shipped a database migration that took out production. You add a NOT NULL column without a default and the table rewrite locks writes for four minutes. You run CREATE INDEX without CONCURRENTLY on a 40-million-row table. You drop a column that three services still read. None of this is clever to catch. It is a checklist. It is also exactly the kind of check a tired engineer skips at 6pm on a Friday.

So build an agent that does one job. When a pull request touches migrations/, it triggers. It reads the migration and checks it against a fixed list:

Does it add a NOT NULL column with no default?
Does it take an ACCESS EXCLUSIVE lock on a table over some row threshold?
Does it create an index without CONCURRENTLY?
Does it drop or rename a column still referenced in application code?

It posts one comment. If nothing is wrong, it says so in one line. It does not review naming. It does not comment on the rest of the PR. It does not approve or block. It informs, and then it stops.

Look at why this is a better investment than a general reviewer:

You can verify it. Write the dangerous migration yourself and confirm the agent catches it. You cannot do that with "review my PR" — there is no defined output to test against.

A small, cheap model can do it. The job is narrow, so you do not need the frontier model on every push. It runs fast, it runs often, and it costs almost nothing.

It fits a pipeline. This is a CI step on a pull_request event, not a thing you open and talk to. It runs when you are not looking, which is the entire point.

It stops needing you. General assistants fail because they keep you in the loop. A narrow agent with a one-comment blast radius does not.

The recipe

Building one of these is less about prompting than scoping. Four steps.

Pick the task by subtraction. Not "what could AI do here" — that question has no floor. Ask: what do I do every week, by hand, that is mechanical and that I resent? Release notes. Triage. The dependency-bump sanity check. The migration review. The resentment is the signal.

Write down what "done" looks like before you write a prompt. If you cannot describe the output in two sentences, the job is still too big. "A PR comment listing any migration that matches one of four risk patterns" is two sentences. "Better code" is not.

Write the do-not-touch list. This is the step everyone skips, and it is the one that makes the agent usable. The SEO agent's single most important feature is the list of things it leaves alone. Your migration agent must not refactor, must not lecture on style, must not block the merge. Forbidding behaviour is how you make the agent's output predictable enough to trust.

Wire it to a trigger, not a chat box. An agent you have to remember to invoke is a tool you will forget by Thursday. An agent bound to a pull_request event is infrastructure. The difference between a clever demo and something that compounds is whether it runs without anyone deciding to run it.

The prediction you can argue with

Here is the take you are welcome to disagree with. The general coding agent in your editor — the one everyone is comparing benchmark scores on — is going to matter less than people currently think, not more.

The chat window is where you do novel work, and novel work is real. But most engineering is not novel. It is the same dozen checks, the same triage, the same release ritual, every single week. That work is going to move out of the chat window and into a swarm of small agents wired to events. The teams that pull ahead will be the ones with the longest list of boring, narrow, unattended agents — not the ones with the cleverest prompt for the general one.

The reasonable counter-argument is that models will simply get general enough that all this scoping is wasted effort: one assistant, smart enough to be trusted with everything. You might be right. But I would bet against it, because the bottleneck was never raw capability. It was trust. And you do not earn trust by making the model smarter. You earn it by making the job small enough to verify.

Where to start

Do not open the framework docs and ask what a powerful agent could do. Ask the smaller question: which single job would you hand over tomorrow if you could be sure it caught the thing you are scared of?

Pick that one. Describe what "done" looks like in two sentences. Write the do-not-touch list. Wire it to an event, not a chat box. Then write the dangerous input yourself and confirm the agent flags it.

That is the whole loop. Get one boring agent running unattended this week, and you have a template for the next ten. That is how the useful AI in your codebase gets built — one job at a time.

Sources I drew from: