There’s a troubling framing right now about treating AI agents like employees. IBM published a piece titled When the AI Agent Joins the Org Chart. The article itself is more measured than the title, including quotes from researchers pushing back on the “AI coworker” framing and acknowledging that agents are not employees. But the headline leans hard into the framing anyway.
The piece that actually commits to the framing is Harvard Business Review’s To Scale AI Agents Successfully, Think of Them Like Team Members. HBR doesn’t literally argue for putting agents on the org chart either. But they do argue that you should “stop treating them as turnkey software that simply needs to be installed” and “treat your agents like a new kind of workforce that requires management” with roles, scopes of authority, sources of truth, and escalation rules. The whole piece is built around the analogy to managing human employees.
An AI agent is software. It isn’t a team member. It isn’t an employee.
I want to say this plainly. An AI agent is software. It isn’t a team member. It isn’t an employee. The fact that this needs to be said out loud is the thing I find most concerning about the current moment.
Before I unpack what’s wrong with the framing, I want to give HBR credit for something. The engineering substance of their piece is actually sound. The four pillars they lay out (identity, context, control, and accountability) are all widely accepted good practice for building agent-based software. I don’t disagree with any of those prescriptions. I’d go further and say the Control section contains the strongest insight in the piece: that probabilistic systems should not directly mutate state, and that you should separate the generation of a recommendation from the execution of an action.
My objection is not to any of that substance. It’s to the framing HBR uses to deliver it.
Identity
The article argues that agents shouldn’t run under shared service accounts and should each have their own credentials and scoped access. All correct. But the framing is that organizations “should treat each AI agent as a distinct digital worker with its own identity.” A scoped service account is an engineering pattern. Nothing about it requires you to think of the service as a digital worker.
Context
The article argues that agents need trustworthy, authoritative data sources. Also correct. Every system that depends on organizational data needs this, not just agents. Writing down tribal knowledge, resolving contradictory sources, and governing data provenance is something every business should already be doing. A billing engine pointed at a broken ledger will produce garbage too. Nobody says the billing engine needs to be part of the workforce to fix that.
Control
The pitch here is the strongest part of HBR’s piece and worth calling out. They specifically prescribe separating the generation of a recommendation from the execution of an action: let the agent propose, have deterministic software validate, then let some other system execute. That’s the right architectural response to probabilistic systems. It’s also a well-understood pattern that predates agents entirely. You can build propose/validate/execute pipelines without ever treating the system as a team member. Validation is a change in how you wire things together, not a mental shift into colleague-hood.
Accountability
This is the one where the article undercuts its own framing. The scenario they describe is a procurement agent that posts supplier performance to Slack and accidentally leaks confidential contract terms because it interpreted “share transparently” too broadly. HBR argues you need enough observability to reconstruct the agent’s decision. True. But notice what the example actually shows: the real issue is that the software was given access to do things it should not have been able to do. That’s a failure of the humans who built and deployed the agent. The humans are the ones who own that consequence.
They then cite Moffatt v. Air Canada, where a court held the airline responsible for misinformation given by its chatbot. HBR cites it as evidence that agents need more accountability infrastructure. I would argue it’s also a damning point against the thesis itself. The tribunal rejected the idea that the chatbot was a separate entity. It held the company responsible, because the chatbot is software that humans built and operate. That ruling isn’t a call to treat agents like employees. It’s a reminder that people who ship bad software own the consequences.
So back to the core question. If the engineering substance is sound, and it is, why do I object so strongly to the framing?
Once a buyer starts comparing the monthly cost of an agent against the monthly cost of an employee, you get to price it like an employee.
The first reason is commercial. If you can convince executives to think of agents as employees, you can start selling them like you sell human labor. Budget line items per agent. Consulting firms quoting projects by “agent headcount.” License tiers priced against the salary of the person that agent is supposed to replace. The mental model does commercial work. Once a buyer starts comparing the monthly cost of an agent against the monthly cost of an employee, you get to price it like an employee.
The second reason is more fundamental. Calling the software a team member, at best, feels sociopathic to me. It simultaneously overstates what an LLM-based application can actually do and undercuts what a human contributes that no probabilistic system can. It implies these systems have something like judgment, responsibility, presence, continuity, or moral weight, when in fact they have none of those things. And it quietly flattens the value of human work by framing people and software as things that can be swapped into the same slot on a chart.
Agents are software. The right questions to ask are the same ones you’d ask about any other system: who owns it, how is it monitored, what happens when it fails, what are the guardrails, what’s the blast radius if something goes wrong. None of those questions require an org chart, a role, or a headcount line on a P&L.
The real risk of the “team member” framing isn’t that it’s insulting to humans or silly on its face. It’s that it bypasses the scrutiny that software actually deserves. An agent is a probabilistic system with access to real actions inside your business. It needs to be engineered, not employed.