Onboarding an AI teammate: HR's strangest new job description

Somewhere right now, an HR leader is reading a Slack message from an engineering manager that says something like: "Hey, quick one. We're adding an agent to the team to handle triage and first-draft work. Does it need to go through any process, or do we just... turn it on?"

The HR leader does not have an answer, because no answer exists. There is no policy. There is no process. There is a growing pile of adjacent questions in her inbox, and a dawning realization that this is about to become part of her job. It sounds like a joke assignment, onboarding software, and the instinct of most People teams has been to lob it over the wall to IT. That instinct is understandable and wrong, and it's worth spelling out why, because whoever picks this up first is going to define how their company works for the next decade.

Consider what actually happens when a team adds an agent that participates in the work. It joins channels. It reads documents. It messages people, and people message it. It hands work to colleagues and receives work from them, sometimes from other agents. It has, functionally, a role: responsibilities, access, expectations, failure modes. Now run down IT's checklist for new software: licensing, security review, data access, done. Notice everything that checklist doesn't touch. Who is this agent's manager? What is it responsible for, and what is it explicitly not allowed to touch? What happens when it makes a mistake that affects a customer, or a colleague? How do the humans around it know what to expect from it? Those aren't software questions. They're the questions HR answers every time a human joins, and the fact that nobody's asking them is precisely why early agent adoption keeps producing the same messes.

The messes have patterns. There's the orphan agent: set up by an enthusiast who then changed teams, still running, still messaging people, belonging to no one, until it does something odd and the ensuing investigation discovers nobody can say who's responsible for it. There's the shadow delegation problem: an employee quietly routes a chunk of their job through an agent, output quality is fine, and then they leave, and the team discovers a load-bearing workflow nobody knew existed and nobody can maintain. There's the expectations collision: half the team treats the agent's output as final and ships it, the other half treats it as a rough draft, and the disagreement surfaces as a customer-facing error and a very unpleasant retro. Every one of these is an org-design failure, not a technical one, and org design is HR's home turf.

So what does the strange new job actually involve? Stripped of novelty, it's four familiar HR motions pointed at an unfamiliar subject.

Role definition, first. Every agent that participates in work should have what amounts to a job description: what it owns, what it must escalate, what it may never do. Teams that write this down get predictable agents. Teams that don't get improvisation, and improvisation at machine speed is how small ambiguities become large incidents. HR has been forcing clarity about roles out of reluctant managers forever. Same skill, new species.

Ownership, second, and this is the non-negotiable one. Every agent needs a named human accountable for it, the way every employee has a manager. Not a team, a name. When the name leaves the company, the agent gets a new owner or gets turned off, as part of offboarding, the same checklist that already handles their badge and their laptop. The orphan agent problem is entirely a failure to do this one boring thing.

Norms, third. Humans need to know how to work with agent colleagues, and it will not happen by osmosis evenly. What's reasonable to delegate? How should you treat agent output, and how do you flag when it's wrong? Is it acceptable to be curt with an agent in a shared channel, and before you laugh, watch what happens to a team's tone when half its members are curt to agents all day in front of each other. Culture is upstream of policy here, and culture is supposed to be the People team's whole thing.

And skills, fourth, because working alongside agents well is a trainable competence that most employees currently lack. Delegation, specification, review. The companies treating this as a formal capability, taught and practiced, are pulling away from the ones treating it as something employees will figure out. The gap between an employee who directs agents well and one who doesn't is becoming as wide as any skills gap HR currently measures, and unlike most, this one is closable with training that exists.

There's a bigger reason for HR to claim this ground rather than have it land by default. The alternative isn't that nobody decides these things. It's that they get decided implicitly, by whoever configures each agent, one enthusiast at a time, with no consistency and no principles. Questions like how much of a role can be delegated before the role should be redesigned, or what happens to the junior rungs of a career ladder when agents absorb the work juniors learned on, or how performance gets evaluated when output is a blend, these are going to be answered at every company within a few years. The only choice is whether they're answered deliberately by people whose job is organizational health, or accidentally by people whose job was shipping a feature by Friday.

The strangest job description in HR, in other words, is also the most consequential one open right now, and it's open at nearly every company simultaneously. The engineering manager's Slack message deserves a better answer than "ask IT." The HR leaders writing that better answer today, on plain pages, with named owners and boring checklists, are going to look prophetic in three years, and they'll know the truth: it wasn't prophecy. Someone just had to treat the new teammates like what they functionally are, and HR was always the department that knew how teams work.