Why I Treat AI Agents Like Junior Staff, Not Tools

<p>I keep noticing how much the word "tool" undersells what's actually happening when I work with AI agents day to day. A tool is a hammer. It does one thing, you point it, it does the thing, you put it down. That's not what's going on when Nova's coding agent reviews a pull request, or when an agent swarm is split across different lanes of a problem, each with its own context and judgment calls to make.</p><p>My view is that the more useful mental model is a junior staff member — not because the AI is conscious or deserves a desk, but because the management problem is the same shape. A junior engineer doesn't need you to specify every keystroke. They need a clear brief, boundaries on what they're allowed to decide alone, and a point where they have to come back and check with you before something ships. That's exactly the posture I've landed on with agents: give them the goal, give them room to work, but keep a human veto on anything that touches production or anything hard to undo.</p><p>Where this matters practically is in how you structure the work you hand off. If you treat an agent like a tool, you tend to over-specify — you write out every step because you don't trust it to fill gaps sensibly, and then you've basically just written the code yourself in prose first. If you treat it like a hammer that occasionally surprises you, you under-specify and get burned, then overcorrect into micromanagement. Neither extreme is right. The useful middle is closer to delegation: here's the outcome I want, here's what you must not touch, here's where to stop and ask.</p><p>This also changes how I think about review. You don't review a junior's work the same way you review a senior's — you look harder at the judgment calls, less at the syntax. Same with agent output. I'm less interested in whether the code compiles and more interested in whether the agent made a reasonable call at the ambiguous points — the places where the brief didn't fully specify what to do and it had to decide something on its own. That's where the real risk and the real value both live.</p><p>I think this framing matters more as these systems get wired into actual business infrastructure rather than toy demos. AIREP and Gripswich OS aren't experiments — they're running systems that real operations depend on. An agent making a bad judgment call in a side project is an annoyance. The same agent making a bad judgment call against a live multi-tenant database, or against a gym's booking system, is a different category of problem. The "tool" framing makes people relax in exactly the places they shouldn't, because tools don't make judgment calls — they just execute. Agents do make judgment calls, constantly, even when you haven't given them permission to.</p><p>None of this is an argument for giving AI more autonomy than it should have. It's almost the opposite — it's an argument for being honest about how much autonomy it already has, so you manage it accordingly, instead of pretending it's a deterministic tool and getting surprised later. The businesses that get hurt by AI in production aren't the ones that gave agents too much power on purpose. They're the ones that didn't notice how much power they'd already handed over, because they were still calling it a tool.</p><p>I don't think this is a solved problem, for me or for anyone building with these systems right now. But naming the management problem correctly feels like a precondition for solving it. You can't build good boundaries around something you're still describing as a hammer.</p>