Blog

The one rule that lets me trust AI agents with my side projects

None of my AI agents can send, post, merge or pay without my yes.

Wireframe gate on a dark grid, linked to four small panels, with the words Approval rules, Agents at work, one gate

Most evenings my part in my side projects is small. A few AI agents do the planning and the coding, and I do the approving. I read what they want to send or merge, and I say yes or no. Turns out that still fills an evening.

That one rule is why I let them near my side projects at all. The other half is routing. Most of the day they hand work to each other without me, and I only see the parts that need a decision. Here is where my yes sits, and why.

Reading is free

Diagram titled Reading is free: calendar, docs and repos connect to a wireframe cube, while send, post and merge wait behind a yes gate

My agents can read everything I give them. Calendar, docs, my X timeline, repos. I keep this side of the rule as wide as I can. An agent that has to ask before every lookup needs a babysitter, and then I might as well do the work myself.

Reading breaks nothing, so I don’t make them ask.

Anything that changes something out there waits for me:

  • Nothing gets posted or sent until I say yes.
  • Code lands in a pull request, and the merge button is mine.

The line is easy to check. If an action only changes what the agent knows, it runs. If it changes what other people see, or touches money, it waits for me. It also means that when an agent gets something wrong, the mistake stays with me. Fails are the fun part, but I’d rather find them in my review than on my timeline.

So far this step has mostly meant small edits. I change a detail, then I say yes. I haven’t had a case yet where I said no and was glad it never went out. The suggestions have been good enough every time. I keep the step anyway, for the day I need it.

Logins live in a vault

Diagram titled Logins live in a vault: a wireframe safe linked to agent access and reading, with send behind a separate yes gate

It’s tempting to put the yes at the login page. It feels safe, because nothing happens without you. In practice it mostly means an agent sits and waits while you’re busy with something else.

Before the vault existed, my agents didn’t use logins. When something needed one, I typed it in myself. For me the vault is an absolute quality gate. Without something like it, I wouldn’t let agents near logins at all.

My agents don’t wait for me at every login page. Since late October the logins sit in a vault, and a bot uses them from there when a task needs one.

Logged in doesn’t mean allowed to send.

Access and permission are two different questions. The vault answers the first one, the rule at the top answers the second. An agent can log in and read what’s there. Anything that would send still waits for me.

Fixed steps where it matters

Diagram titled Fixed steps where it matters: a fixed pipeline from import to clean, check and export, with an agent feeding scripts into the steps

I build data pipelines for a living. The scariest run is the green one that quietly processed zero records, so I like boring and predictable. After any run, the first thing I check is whether anything actually arrived on the other side. A row count ends more arguments than any review.

When data needs cleaning, the steps live in a fixed n8n pipeline. The agent writes the cleanup scripts. The pipeline runs them the same way every time. Messy CSV files are the typical case. The agent writes the script, I review it, and n8n runs it in its fixed spot.

This sounds like it clashes with something else I learned recently. Telling my agents how to do something works worse than telling them what I want. When I spell out the steps, they follow them, including the bad ones. Both are true for me. For open work I describe the goal and let the agent find the way. For data I want the same steps in the same order every time, so the order lives in the pipeline and not in a prompt. Most of my agent fails so far came from bad input nobody checked, and a bigger model doesn’t fix that. It just fails more confidently.

The agent writes the pieces. The pipeline decides the order.

Who hands what to whom

Diagram titled Who hands what to whom: a dispatcher hands work to research, evaluation, planning and building, with yes gates before outreach and building

Turns out my agents have the same problem as every team I’ve ever been on. The work got done. Nobody handed it over properly. The result was there, it just never reached the next step.

So I cleaned up the team. One clear job per agent, a lot fewer rules. They work better now. One bot sorts whatever comes in and hands it to the one that should do it.

For my side projects it’s two steps now: one agent plans, another builds. The planning step is there for the same reason it exists with people. I’d never send a paid team off with just an idea. Tokens are cheaper than salaries, but agents build faster, and building the wrong thing faster helps nobody.

Smaller jobs also made fixing things easier. When something breaks, I change one agent and watch that one agent. Way less detective work the next morning.

My yes sits at a few doors. Everything between them runs on its own.

Where your yes sits

I don’t think my setup fits everyone. Reading is free, and anything that sends waits for my yes. That works for one person. I have no idea yet how it scales to a team. I’m also still figuring out whether a new rule actually makes my agents better or just makes me feel better.

That’s why I’d like to compare notes in person. My idea for Cologne is a build night where everyone brings one boring task and leaves with an agent that handles it. For now it’s only an idea, with no date and no place yet. I’d like to add a small session on approval rules, where we look at where each of us puts the yes. If you build with agents, my DMs are open.

What’s the one thing you’d never let an agent do without asking you first?