What If a Judge Fixed Your Agents?

I am experimenting a lot with agents in this period, especially for a client. Not in the “nice demo on localhost” way. Real production agents, real people, real conversations, and all the little stupid things that happen when an AI is not inside your notebook anymore.

Two of them are already in production on ElevenLabs: one voice agent that answers the phone, and one agent that replies on WhatsApp and email. I wrote about how I think about these two agents before. And after watching them for a while, the question became pretty obvious to me: what if an LLM judge could check the agents every hour and fix their prompts by itself?

Yes, I built it. And it works.

The judge that runs every hour

At a very high level, I created a judge. It runs on a schedule, every hour, and it checks everything that happened since the last round. Technically, it is a Claude Code session running on my Mac with a skill. No separate server, no big platform, no “let’s create another microservice because why not”.

The judge reads the conversations and the logs. ElevenLabs gives it safe access through the API, and I also have all the data inside my own database. Then it checks every message against the boundaries, meaning the rules an agent must never break.

For example: inventing a phone number or a name. Promising a call when it should not. Booking outside the calendar. Saying it is an AI, or saying it is not an AI, when it should not go there. Across the two agents there are about twenty of these checks.

The important part is that it does not just scream “bug” because a keyword appeared somewhere. Before calling something a defect, it reads the case inside the real conversation and discards false alarms. Because otherwise you don’t have a judge, you have a very expensive grep with opinions.

It fixes the prompt, but with a leash

When the judge finds a serious defect, it does not go directly to production. It fixes the prompt first, then tests the fix on a test copy of the agent using the real cases. Nothing is sent to anyone. No customer receives a test message. No one gets a weird experimental answer because I was in builder mode at midnight.

Only if the defect disappears, and nothing new appears, it publishes the prompt to the live agent. Every time it publishes something, it emails me. So I still know what changed, when, and why.

There are also hard limits. The judge never talks to customers. It never decides product questions. If fixing something means deciding how the product should behave, it hands that to me. And it never rolls back on its own.

This is not “let the AI run the company”. It is more like: let the AI do the boring checking and the first safe iteration, then keep the human where the judgement actually matters.

The dashboard

Of course I needed a UI, because otherwise after two days you don’t understand anything anymore. So I created a dashboard with a timeline of all the attempts, plus a diary of every change to the agents. I also rebuilt the diary back to early September, so I can see how the prompts evolved over time.

Every open defect gets a coloured dot at each round. 🔴 found means the judge saw the defect and publishes a fix. 🟠 happened again means a new fix that evolves the previous one. 🟢 not happened means there was a chance, and the defect did not show up. ⚪ no occasion means there was no conversation where it could happen, so it does not count. 🔵 waiting for you means fixing it is a product decision, so it waits for me.

A defect counts as solved after three greens after the last fix. If there is an orange, the count restarts. Simple, visible, and honestly very useful, because you can see if something is actually improving or if you are just moving the problem from one sentence to another.

Evals on the field, plus tests

In a couple of days, the judge was able to test properly, show me the conditions, show me how the agents behaved, and bring the prompts to a more stable version. Not perfect, because perfect does not exist here. But much more stable.

For me this is a mix of evals on the field and tests. The field gives you the real weird cases. The tests make sure you do not break the same thing again, the same idea as letting AI test its own work, just pointed at agents instead of pages. And the dashboard gives you the memory, because I can reread, recheck, reiterate, and reuse the same approach for the next agent.

This is the part I like the most. Every new agent can start with the same idea: boundaries, logs, judge, test copy, safe publication, diary. Not a one-off script that dies in a folder, but something I can productize.

Why not yet another framework?

Now, someone will say: “Alex, why are you not using yet another framework?” Fair question. Maybe there are already frameworks that do this very well. Maybe they have a lot of stars on GitHub and so on and so forth.

But this is connected to the top-down approach I wrote about in another article. I want to learn. I want to understand the problem from the product side first, then decide what abstraction I need. And yes, I am opinionated, so I started from scratch.

Maybe one day I will have my agent factory. Who knows.

For now, I am building the pieces I need, testing them on real agents, and trying to make them boring enough to trust. I hope this can inspire someone else experimenting in the same direction. If you have a similar approach, share your links with me. And if you want to build something like this, write to me.