Don’t treat agents like teammates. Treat them like systems.
The MIT/BCG “agents as teammates” frame is leading operators into a specific failure mode HBR research has now named: anthropomorphizing AI reduces individual accountability and lowers review quality. The Constrained Agency move is to treat agents like systems with delegated authority.
The dominant 2026 framing for AI agents in the workplace, popularized by MIT Sloan / BCG and adopted across the major-firm research agenda, is “agents as teammates.” Agents are described as collaborators, junior colleagues, members of the hybrid workforce. The frame is intuitive and pleasant. It is also, per recent HBR research on anthropomorphization in AI deployments, demonstrably harmful: when agents are treated as teammates, individual human accountability decreases, escalation rates rise unnecessarily, peer review of agent output declines, and adoption suffers. The frame produces the opposite of what it intends.
This piece argues for a sharper alternative. Agents are not teammates. They are systems with delegated authority — closer to a configurable database trigger or a privileged service account than to a junior colleague. The frame matters because it determines how operators design the management layer around the agent. Treat agents as teammates and you build a soft management approach that fails at scale; treat agents as systems and you build the hard management approach that the constraint stack actually requires.
Why “teammates” fails and “systems” succeeds.
Anthropomorphism reduces accountability.
The HBR research finding is direct: when employees describe agents in social terms (“Sarah the agent”), they treat agent output the way they would treat a colleague’s output — assume good intent, defer to apparent expertise, escalate ambiguity rather than resolve it. The same employees, given the same agent framed as “the customer-service automation system,” review output more rigorously, catch errors faster, and trust their own judgment more. The frame changes the behavior, and the behavior changes the outcome.
The teammate frame imports management practices that don’t fit.
Treating agents as teammates pulls in human-management primitives — feedback conversations, performance reviews, growth paths — that have no analog in software. Operators waste cycles trying to apply them. Treating agents as systems pulls in software-management primitives — version control, telemetry, scoped permissions, kill switches — that are exactly the right primitives for the use case.
The systems frame aligns with the auth layer.
Per Piece 02, the agent identity layer requires ephemeral, intent-bounded, delegation-chained, machine-introspectable primitives — none of which are teammate primitives. Naming agents as systems with delegated authority makes the auth layer’s requirements legible to the operator. Naming them as teammates obscures the auth layer’s requirements and produces over-scoped service accounts dressed up as colleagues.
The systems frame supports the “agent manager” role correctly.
HBR is right that organizations need agent managers — but the role is closer to SRE-with-business-context than to people-manager-with-AI-knowledge. Reframing agents as systems makes the role design coherent: the manager owns the system’s scope, telemetry, error budget, and escalation pathway, not its “professional development.” This is the right job description for the role; the teammate frame produces the wrong one.
The strongest argument against this position.
The strongest counter is that the teammate frame helps employee adoption — humans accept and use AI more readily when it is positioned as a colleague rather than as a tool. This is empirically true in early-deployment surveys. The HBR research suggests it is also empirically false for downstream review quality and accountability. Both can be true: the teammate frame reduces friction at adoption and increases friction at quality control. The honest position is that the teammate frame is a valid messaging strategy for change management but a damaging design principle for the management layer. Use teammate language in the rollout deck; use systems language in the design specification.
Three things to do this quarter.
01 · Audit your agent management vocabulary. Are agents described as “Copilot,” “Sarah,” “the team” in operating documents? If yes, you have likely imported the teammate frame into the management layer where it produces accountability dilution.
02 · Hire agent managers as SREs with business context, not as people managers with AI training. The role is system ownership: scope, telemetry, error budget, escalation. Title and JD should reflect that.
03 · Build the management layer around system primitives. Agent observability dashboards, scoped permissions, version-controlled prompts, kill switches, telemetry alerts. These are the right primitives. Performance reviews and 1:1s are not.