Welcome, we have a new team member!
The first time I welcomed Arthur onto a team, I made the mistake of simply letting him take on the team’s existing tasks. I assumed onboarding meant transferring tasks. It took time before we fully understood that the team had not actually gained the full benefit of the unique skills and experience Arthur brought. We had only added a faster pair of hands for work we already knew how to do. The harder, more valuable conversation — about what each of us should now own — never happened until something fell through the gap between us. I think about Arthur now in light of introducing AI agents and AI skills into our teams, and why we need to think about the problem similarly. Organizations are about to make the same mistake at scale, with a new kind of team member that does not yet have a name on the org chart. Meet our new AI team member.
The instinct, when an AI arrives, is to hand it a task. That is reasonable, because it is how we onboard a tool. But it is not only a faster tool. It makes choices. And the moment something on your team makes choices, the question stops being “what can it do” and becomes “what is it allowed to decide, and who answers for the result.” That is not a tooling question. It is a question about the team’s working agreement, and most teams never reopen it.
That gap is worth naming before any agent is deployed. To see why it matters, it helps to be precise about what an AI transformation means.
What an AI Transformation Actually Is
The phrase collapses three different ambitions that demand different work and produce different returns:
- AI as leverage on existing work: copilots and agents that make current activities faster or cheaper.
- AI in the product: intelligence embedded in what customers buy or use.
- AI reshaping the operating model: changing how work flows, where decisions are made, and how the team is shaped.
The first is table stakes, the second is positioning, and the third is where durable advantage lives — and where most of the difficulty sits. The dominant failure mode is running the program as a tooling rollout (the first ambition) while quietly expecting the returns of the third. Those returns do not arrive, because the constraint was never tool access. It was the operating model wrapped around an older set of assumptions about who does what.
Bringing AI onto a team is where these three ambitions meet in a single, concrete decision. Treat it as leverage alone and you get a faster version of the team you already had. Treat it as an operating-model change and you have to reset roles. The rest of this piece is about that reset.
The AI as a Team Member
It helps to name what you are adding, because it arrives in more than one form. An assistant, or copilot, responds when a person asks — suggesting or drafting while the human stays in control. A skill is a specific capability the AI can perform, such as drafting a contract clause, writing a query, or running a test suite. An agent pursues a goal across several steps, choosing its own actions and calling on skills as it goes. These are not competing categories but points on a single line: how much authority comes with what you add. In practice two things enter the team at once — new capability and new autonomy in using it — and the more authority you hand over, the more the team’s roles have to change. For that reason this piece speaks of the AI member in the generic sense. The principle holds whichever form arrives, and whichever form arrives next.
Harvard Business Review offers the right starting point, drawn from the most autonomous case: scale AI by thinking of it as a team member, not as software you switch on everywhere at once [1]. The distinction matters. A team member is onboarded into a role with scoped authority, supervision, and a path for escalation. Software is simply deployed.
What does the role look like in practice? Engineering teams are converging on a clean division of labor, often summarized as delegate, review, and own. The AI handles first-pass execution: scaffolding, implementation, drafting automated tests and code; people review that output for correctness, standards, risk, and alignment; and ownership of architecture, trade-offs, and outcomes stays human. The engineer’s center of gravity shifts from producing the work to orchestrating and judging it — part of a broader move toward senior people who set standards and orchestrate work across teams, vendors, and agents [2]. The same shift reaches well beyond engineering. A Product Manager who once spent a lot of time evaluating customer feedback, defining strategy, and creating a roadmap now reviews and sharpens the priorities and outcomes an AI builds from customer signals — spending less time producing the artifact and more time deciding what is worth building and why. Which role changes, and how much, depends on which capability you introduce and how close it sits to that role’s daily work.
This is why introducing AI with real autonomy is an organizational design question, not a technical one. An agent holds decision rights. The instant you let it choose its own steps toward a goal, you have delegated authority, and delegation is the substance of how a team is organized.
Honest test: transformation is not whether the team moved faster — it is whether the composition of roles changed. If work sped up while everyone kept doing the same things, the team bought leverage, not transformation. The human value line has to move: people concentrate on judgment, taste, ambiguity, and relationships, while the AI absorbs high-volume synthesis and pattern work.
Resetting Roles Within the Team
Resetting roles is the work of rewriting the team’s working agreement. The instinct is to respond to a capable new member by defining everything: every task assigned, every interaction specified, every contingency written down. That instinct is the mistake — an agreement that tries to control everything is brittle. It is committed to today’s conditions and cannot absorb the next change. The real work is narrower and harder: deciding which parts of the agreement to make firm and which to leave deliberately adaptive.
Three moves make that practical:
- Stabilize the boundary
- Design the edges
- Protect the whole
Each one, in turn.
Stabilize the boundary
Separate the frame from the contents. Make the frame explicit and controlled: who is accountable, what the AI may decide, where it must stop and escalate, and what counts as reviewed. These are stable and carry the real risk. Leave the contents adaptive — which tasks the AI takes on and how far it is trusted will shift as its capability grows, so fixing them in place only costs the team its ability to learn. This is encapsulation applied to a team: wrap the AI in a controlled interface of accountabilities, decision rights, and escalation gates so the inside can keep changing without destabilizing the people around it.
One practical move: split tasks into AI-only, human-plus-AI, and human-only to surface where authority sits [3]. Make the ownership it reveals firm, but treat the allocation itself as a living boundary — revisited as trust changes, not a contract signed once.
Design the edges
Spell out the edges before the AI acts: when it must stop and hand off, when it should interrupt for input, and when it should stay silent [4]. Where you cannot fully trust it, wrap it in compensating controls — a review gate, a verification step, a limit on what it can commit without a human — so escalation is part of the role rather than an afterthought. And name an owner for the gray area of accountability, the decision an AI makes at the edge of its authority, before the gap is found rather than after. To sort what to make firm from what to leave open, use one rule: reversibility and the cost of being wrong. Stabilize early where a wrong call is expensive and hard to undo; hold it loose where it is cheap to adjust and let feedback settle it. The same rule flags overreach: the moment a boundary replaces judgment with a rote checklist instead of freeing it, it has gone too far.
Protect the whole
Guard the entry-level work that builds your future experts. The over-commitment to avoid is letting the AI absorb foundational work and quietly stopping the development of the people who used to do it. Freeze junior roles because the AI now writes the boilerplate and you remove the rung on which senior engineers are made — an inverted pyramid that starves the future supply of the very people who must review and own what the AI produces. A Google DeepMind analysis of AI delegation makes the point in general terms: the routine tasks most likely to be handed to an agent are exactly the ones through which junior people build judgment, so automating them away erodes the apprenticeship pipeline [4]. Faster output today, no pipeline to the judgment roles tomorrow. It is the parts-versus-whole trap — fixing in place what needed to stay adaptive, and precisely the trap systems thinking exists to catch.
Conclusion
It is fair to argue the opposite — that an AI is not a coworker at all but an instrument, programmable, bounded, and dependent on human judgment [5]. Teammate or tool, the test of success is the same. You still measure it, just not only for speed or cost. It shows up in a morning that feels like nothing at all.
By the time the team gathered, Andrew, our AI teammate, had drafted overnight, so the questions on the table were the ones worth arguing about rather than the busywork of producing the draft. Maura, who came up from junior to senior, ran the review. The early roles we might have automated away are the ones that built the judgment she now brings. She spends her time directing Andrew’s work, catching what Andrew cannot, and bringing along whoever comes next.
No one in the room treated Andrew any differently. Andrew had a clear job, a clear owner, and a clear edge — and that was the point. We knew who was accountable, where Andrew had to stop and ask, and what only a person should decide. The measure of success was never that the team just moved faster. It was that the team had changed shape and normalized around its newest member, with every person moving up to work that needs human judgment, making the team whole. Arthur taught me the lesson years ago. Andrew, an AI, is the proof we finally learned it.
References
[1] Telang, R. and Hydari, M. Z. “To Scale AI Agents Successfully, Think of Them Like Team Members.” Harvard Business Review, March 2026.
[2] Soller, H., Stefanelli, M., Goel, R., and Husain, U. “Designing an End-to-End Technology Workforce for the AI-First Era.” McKinsey & Company, April 2026.
[3] “No More Pyramids: Rethinking Your Workforce for the Agentic AI Era.” PwC, 2026.
[4] Tomašev, N., Franklin, M., and Osindero, S. “Intelligent AI Delegation.” arXiv:2602.11865 [cs.AI], Google DeepMind, February 2026.
[5] “The Future of Work: AI Agents as Instruments, Not Co-Workers.” IDC, December 2025.
This post comes from our management consulting practice, which specializes in designing and implementing operating models that align governance, processes, and technology to drive measurable business outcomes.
