In May, Harvard Business Review told leaders to stop treating AI agents like employees. The same month, Fortune called managing your agents the next test of leadership. Same technology, same audience, flatly opposite instructions.
I’ve read both. My day job is leadership, and most of it is human work: getting an organisation to move in the same direction, down and sideways and across functions. Alongside that I spend a good deal of my own time directing agents through real work, partly to keep learning. So I run the two side by side, and I keep noticing the same muscles firing in each. Neither piece would have helped me in the moment that mattered, when an agent did exactly what I asked and handed back something subtly, confidently wrong. The debate is loud, and it points the wrong way. Both sides argue about what an agent is. Neither asks what the leader is doing.
The two camps, and why each one is seductive
Take the sceptics first, because they come armed with data. The HBR study is a good one: more than 1,200 managers, and when the AI was framed as an employee they caught 18% fewer of its errors, took 9 percentage points less personal accountability for those errors, and handed that accountability to the machine. Name the thing, treat it like a colleague, and you start covering for it the way you’d cover for a person. The conclusion writes itself: stop the anthropomorphising, redesign the workflow, keep the human on the hook.
It’s rigorous, and it’s seductive because it sounds safe.
The other camp is seductive for the opposite reason. It matches what the work feels like. Fortune, Forbes, IBM: treat agents like new hires, think like a hiring manager rather than a software buyer, manage agent performance the way you manage team performance, work out your human-to-agent ratio. Anyone who has spent a fortnight directing a capable agent recognises it instinctively: it does feel like managing someone.
So one camp has the evidence and the other has the intuition, and they contradict each other outright. When that happens, the fault is usually not in the answers. It’s in the question.
The mistake both camps are making
Both camps keep arguing over what an agent is: colleague or tool, hire or software. It’s the wrong unit of analysis. You aren’t managing the agent. You’re managing the loop it sits inside: your intent, its action, the guardrails, the feedback, and you again. Draw a box around only the agent and you optimise the wrong thing. Draw it around the loop and the argument moves onto ground where it can be settled: you stop grading what the agent is and start asking how you steer it. That doesn’t dissolve the contradiction by itself; it’s the diagnosis, not yet the cure. And it isn’t a new idea. Grading the system rather than the component is old management in fresh clothes, which is rather the point of everything that follows.
A second-order catch matters even more. The loop doesn’t hold still. The moment you add the agent, or ship the first version of anything, the system you were directing changes underneath you. New behaviour, new failure modes, new information you didn’t have an hour ago. This is the oldest lesson in software, and it’s why waterfall lost to agile decades ago: you cannot specify your way out of a system that reshapes itself as you build it. Anyone selling you upfront specification for agents is selling you waterfall in a new coat.
Two loops, two levers
So you run two loops instead, and the craft is learning which lever tunes which.
The management loop is the one between you and the agent: you set intent, it acts, you respond, you calibrate. This is where directing lives, and directing is not writing a specification. Humans are famously bad at specs; we don’t know what we want until we see what we didn’t. (The current excitement about “spec-driven development” is mostly comedy: specs are decades old. We re-find them, rename them, and act surprised. Tech runs on repeating patterns dressed as revelations.) A basic spec is fine, necessary even. But the value is in the steering that follows, not the document that precedes it.
The iteration loop is the one between the agent and the work: build, run, observe what changed, correct. This is where guardrails and the harness live: the tests, the verification, the gates that make the loop fast and safe rather than fast and terrifying. Guardrails aren’t a cage you build once. They’re how you let the loop run hot without getting burned. And a guardrail is really just direction settled in advance. Deciding where to place one is the same call as deciding how much leash a report has earned. The two aren’t different in kind, only in when you make the decision: directing is steering live, and a guardrail is that same steering precommitted and handed to the machine, so you needn’t make the call afresh every time.
So the skill isn’t sorting each problem into one of two clean bins. The bins bleed. What it takes is judgement: how much of your steering to spend live, how much to lock in ahead of time, and when you’ve got that mix wrong. Lock in too much and a capable agent does careful, useless work, fenced in by yesterday’s guesses; try to steer all of it live and you drown, hand-holding what a gate should have caught. Get the balance backwards and you’ll reach for a guardrail when what you needed was a clearer word.
The difference shows up in a single line of my own behaviour. When I hand an agent an open “fix this,” I get something good tangled up with some very odd assumptions. It filled the silence with guesses, the way anyone would. When I say instead, “fix this, touch as little code as you can, verify against the thing that matters, and push back if you think I’ve got it wrong,” the result is better, and something more interesting happens. It argues with me. And the argument sharpens my thinking, which was half-formed when I started.
That last move — push back if I’ve got it wrong — is the one neither camp mentions, and it’s the one that gives the game away. Inviting the thing you’re directing to disagree with you is not prompt engineering. It’s management. It’s the exact instinct a good manager uses to break the power imbalance with a nervous report: I know you’ll defer to me, so I’m telling you not to. The tech and the human aren’t separate problems here. The best directing borrows straight from the second.
What transfers from managing people, and what doesn’t
The pushback move points at the real distinction, the one both camps walk straight past. Some of managing people transfers to directing agents. Some of it emphatically does not. Sort those two correctly and the whole confused debate resolves.
Start with what transfers, because it is most of the useful part. Setting intent: being clear about what “good” looks like before work begins. Calibrating autonomy to competence and stakes: a long leash for the reversible and the low-risk, a short one for the load-bearing. Running a feedback loop that actually closes, rather than issuing an instruction and hoping. Inviting challenge, so the thing you’re directing tells you when you’re wrong instead of dutifully executing your mistake. None of these are technical skills. Every one is something a good manager already does on a Tuesday. But look at how the sharpest of them travels: inviting challenge only works on an agent because you first learned, from people, how someone defers to power, then carried that understanding across. The method moves to the agent; the read that built it came from humans. This is why the “manage them like hires” camp feels right. The craft of good management carries over.
Now the part that does not transfer, which is where that same camp quietly walks off a cliff. Personifying does not transfer. Naming the agent, granting it a seat and a personality, treating its output the way you’d treat a colleague’s. That is not management but projection, and it carries a measurable cost. This is what the HBR study actually caught. Look again at their finding: the damage came the moment the agent was framed as an employee. Managers started covering for it, the way you’d extend the benefit of the doubt to a person you liked. Accountability leaked out of the human and into the machine.
That finding is real. The conclusion drawn from it is not. HBR measured anthropomorphising and then indicted management, as though the two were the same thing. They are not even close. Anthropomorphising is about the agent’s identity, what you decide it is. Directing is about your method, what you decide to do. You can direct an agent with total rigour while harbouring no illusion that it is a person. In fact you must: the discipline of directing well is what stops you slipping into the cover-for-a-colleague reflex the study warns about. The sceptics found a real hazard and mislabelled the exit. The hazard was never directing the agent. It was mistaking it for someone.
The bill both camps forget to pay
Draw the box around the system rather than the agent, and a duty falls out of it. A system needs an owner: one named person accountable for what the loop produces, not a department and not a diffuse sense that the technology is everyone’s problem. This is no longer only good sense; the law is catching up. The emerging standard for agents in production is a named human owner and a test of reasonable oversight: the organisation is liable for what its agents do unless it can show it was watching. Regulators have stopped entertaining the idea that an autonomous system can absorb the blame. Accountability runs to the humans behind it, and it always did.
All of it collides with the one resource nobody budgets for, your attention. You can run ten agents at once. You cannot pay attention to ten agents at once. In any system built from a human and their agents, the human is the single-threaded part. The bottleneck was never the code; it was always the person meant to be steering. Governance frameworks hand you a stack of agents and a legal duty to oversee every one, and forget to mention that oversight has a price. You pay it in attention, and you don’t have much. “How many agents per human” is an attention-budget question, not a throughput one, and the budget is the tightest constraint in the whole system.
This is where the two levers finally lock together. Directing spends attention. It is the expensive, high-judgement loop, and where your scarce focus earns its keep. Guardrails and the harness save it. They let you not watch everything, so the attention you do have lands where the stakes are. Get that division wrong and you will either drown, hand-holding trivial work, or look away from the one loop that could hurt you. Far from bureaucracy, guardrails are what let a single-threaded human safely run a system that outnumbers them.
What this asks of leaders
None of this reduces to a slogan about whether agents are colleagues. It asks three concrete things, all leadership work rather than tooling.
Invest in direction as real work. The intent you set, the feedback you close, the challenge you invite: treat these as the management artefacts they are, not overhead to be minimised on the way to the “real” job. The quality of your directing is now a first-order determinant of what your systems produce. Fund it, teach it, take it seriously.
Place guardrails by risk, not everywhere. A guardrail on reversible, low-stakes work is friction that trains your people to route around it. A guardrail on the load-bearing and the irreversible is the thing that lets you sleep. Match the constraint to the consequence, layer it, and put the human firmly in the loop where the blast radius is large.
Keep the accountability human, and protect the attention that makes it real. Give every agent doing consequential work a named owner. Then do the harder thing: guard that owner’s attention budget as fiercely as you guard the headcount line, because an owner who is too fragmented to see what their agents are doing is a name on a form, not an accountable human.
A role shift is folded inside all of this: the engineer who used to write the code increasingly directs the systems that write it. It is tempting to conclude that whoever directs agents well will lead people well, or the reverse. Resist it. The two overlap in their mechanics and part company completely in what they cost.
Directing agents is people-leadership with the hardest parts removed: an agent has no career to grow, no morale to read, no stake in whether the business it serves thrives. Strip those out and what remains is the mechanical core: set the intent, calibrate the leash, close the loop, invite the challenge. An engineer can master that core, produce excellent agent work, and still be nowhere near ready to lead people, because the empathy and the felt obligation to serve the business are precisely the parts agents never ask of them.
The traffic runs the other way too: plenty of managers today, engineering managers among them, have the human instincts and still cannot let the detail go, clutching control that a capable report, like a capable agent, would do better without. The mechanics and the humanity are separate masteries. Agent work is a fair gym for the first and no certificate at all for the second. That fuller shift, who grows into leading people and what directing agents does and doesn’t teach them, deserves a conversation of its own.
Close
Two respected outlets, one month, opposite advice, and both were answering the wrong question. An agent is not a colleague and it is not merely a tool, and the argument over which was never the one a leader needed to win. The question is what you build around it: the intent you set, the loops you run, the guardrails you place, the owner you name, the attention you spend and protect.
None of that is new. Good managers have balanced directing against constraining, run the slow loop of judgement against the fast loop of delivery, and asked the people they lead to tell them when they’re wrong, for as long as there have been people to lead. What is new is the substrate. The muscles are the same ones. So stop asking what the agent is, and start designing the system it lives in, directing it the way you’d direct anything else you were accountable for.