Build the squad. Own the platform.

My wife Helen, who works in HR, sent me an episode of HR Disrupted last week - Lucy Adams interviewing Andy Doyle from Kantar on putting AI agents into production HR workflows.

Andy describes some genuinely impressive work. Kantar had around 4,000 HR policies spread across 63 markets. Twenty-three versions of a single policy were scattered across the intranet, many written by different people at different times, some long out of date. Reviewing and standardising all that by hand would have been the work of years. So they built a set of small, single-purpose agents instead, one to rewrite each policy into a standard format, another to flag where it broke local employment law. The whole lot went into one common framework in a week.

It's a real piece of engineering, which is what makes some of the rhetoric around it a shame: you don't train out hallucination, you constrain it with evals and guardrails. But the operational story underneath holds, and the lesson is in what they did, not how they describe it.

Listening to the podcast got me thinking less about Kantar and more about the next move for everyone who hears a story like that and wants to do something similar.

Why now?

The conversation about AI inside large organisations has shifted in the last six months, from a model problem to a deployment one. AWS's Ishit Vachhrajani describes it as moving from "generate and hope" to systems that plan, decide, and act with human guidance. You can still argue about whether the models are ready, and plenty of people do. But the teams already shipping agents into production - Andy's at Kantar among them - have stopped waiting for that argument to settle. The hard parts that remain, reliability and hallucination, get handled operationally now - not trained away. Those are deployment problems, not model problems. The bottleneck is the org chart.

Where in your organisation does this capability live? Who owns it, who governs it, who carries the risk when something goes wrong? These are organisational design and architectural decisions, and the next ten years of AI in your business will be shaped more by how you answer them than by which models you pick.

And the honest version of where this is heading is bigger than a governance question. The functional org chart - HR over here, IT over there, finance in the corner - has been the default shape of large organisations for the better part of a century. AI may prove to be one of the forces that starts to pull it apart. Get this right and you're not just deploying agents well, you're building the first working piece of an organisation that composes around the work itself rather than the functions that have always owned it. The first step towards that is much smaller.

Faced with the immediate question - where does this capability live - most leaders reach for one of two answers. Both look reasonable. Both have serious problems.

Two easy answers that don't quite work

The first is to outsource the capability wholesale. Buy an agentic platform from one of the workflow-automation or RPA vendors who've rebadged in the last eighteen months, let them run the platform layer, let their workflows define your agents.

This is a mistake, and a specific one. Not that you shouldn't get external help - most organisations will sensibly work with partners. The mistake is handing over the architectural decisions. Rent a vendor's abstraction and your data, governance, audit, and identity story is whatever they ship. When an agent does something it shouldn't, the loop back to the people who can change it goes through a support queue. You've outsourced the part of your business that's about to become strategic.

Building on a hyperscaler is genuinely different. Model behaviour, pricing, and roadmap are externally controlled either way, but on AWS, Azure, or Google you own the IAM, the audit, the cost controls, the integration patterns. You stand on their shoulders without handing over the decisions that shape how your capability evolves.

The second easy answer is to bolt the capability onto an existing function. Hand it to HR, hand it to IT, hand it to whoever has the closest claim, and declare the strategy done.

There are really two layers here, and they want different answers. The platform layer - IAM, audit, cost controls, the cloud foundation the agents run on - IT will rightly own as platform engineering. It's foundational and benefits from standardised delivery, same as any cloud platform.

The harder question is who owns the capability that uses the platform: designing the agents, deploying them into real business problems, shaping how people interact with them, deciding what good looks like. That's where the "give it to a function" answers break down.

Of the single-function answers, HR has the strongest case. Adoption really is the hard part, and behavioural standards and change management live closer to HR than to engineering. None of that is wrong. The problem is that bolting the capability onto any single function inherits that function's operating pattern, and strategically important work inside a shared service ends up under-invested and slow. The interesting question isn't "which function owns it?" It's whether you're building cross-disciplinary capability that lives in the business, or single-discipline capability that gets delivered to the business.

We've done this before

The thing that should give every senior leader pause is that we've already lived through a version of this. It was called Excel.

Spreadsheets put powerful data manipulation in the hands of capable people with no engineering scaffolding around them. Net positive on the whole, but it also gave us the London Whale loss at JPMorgan and a generation of businesses running critical processes on undocumented workbooks built by an analyst who left two roles ago. We're still cleaning that up decades later.

"Buy some licences and see what people can do" is the same energy. Powerful tools, capable hands, no scaffolding. Except an agent doesn't sit in a workbook waiting to be opened - it acts. Put one on top of a broken process and it won't just record the mess, it'll run it. We learned the lesson once. This time the spreadsheet could fire people.

What to do instead: build a squad

The answer isn't a new department. It's a deployment squad - and you can see the shape of one in the Kantar story, even if Andy doesn't call it that. The top agent builders are spread across HR, payroll, and analytics. The payroll manager who happened to be in the room when the Copilot licences went out became the AI manager. The head of analytics built the finance/HR reconciliation agent herself, eighty hours by her own count. The job title may be useful political cover, but it isn't the operating model. What Andy describes is a squad, not a function.

I'm extrapolating here. I haven't run an internal AI deployment squad inside a large enterprise. What I have watched, up close, is the pattern AWS Professional Services and the Partner Network use to ship production work inside customer organisations - and the forward-deployed engineer roles that Anthropic, OpenAI, and Google are now pitching look like the same shape. The underlying logic is one AWS worked out long ago: access alone isn't the bottleneck. Deployment is.

So build your own version. A small, cross-functional squad: platform engineers who can operate like internal forward-deployed engineers, IT people who already know your data and systems, HR expertise on behavioural standards and adoption, and line-of-business owners who know what good looks like. It embeds into specific problems and ships production agents. Not an innovation pod or a tiger team that spins up a demo and disbands. It owns what it ships, it integrates properly with the platform, and it stays.

The squad needs two things to work.

The first is platform discipline. The agents it builds are applications. They live on a platform layer that decides who an agent is allowed to be, what it can touch, what records it leaves, what it costs, and what it's allowed to do with sensitive data. Most of that comes from the cloud platform you already use. What it doesn't give you, you build and maintain yourself. Be clear from day one about which decisions belong to the platform and which belong to the agent, and resist the urge to rebuild platform-level safeguards inside every individual agent. Andy's team raced past the audit trail and had to come back to it later; he notes it would have been far more costly in a regulated industry. The discipline matters from the start, not as a retrofit.

The second is a sponsor senior enough to clear blockers but light enough not to slow it down, with the authority to ship without permission from every adjacent function. Andy had exactly this: permission to think bigger and permission to fail visibly. The sponsor's risk tolerance is what lets the squad ship and learn. The platform discipline is what decides whether the inevitable failures are recoverable embarrassments or unrecoverable disasters.

Where the squad sits on the org chart matters less than these two things.

One thing the podcast skips is how the rest of the organisation reacts. A cross-cutting squad shipping into work that IT, finance, or operations think of as theirs can be read as a threat, even when it's there to help. Handling that is real work, and it gets easier each time: squads that do it well don't stay one-offs. They become the prototype for how AI capability spreads, and the platform team scales with them.

What this means for HR, and for Helen

The more forward-looking parts of the profession have been moving from a roles-based view of the workforce to a skills-based one, where the unit of work is the skill, not the job title, and teams get composed from skills as the business needs them. Mercer's Jess Von Bank, in a recent People Management feature, pushes HR to design itself from first principles - for what the business needs now, not what the org chart has always done. A deployment squad, assembled from the skills a problem needs, is exactly what that model produces, which is why HR shouldn't try to own the AI capability but should help compose the team that delivers it. That's a craft the profession has spent a decade building, and it deserves better than to be flattened into change management.

For someone like Helen, that means becoming genuinely literate in the platform layer - what agents do, how they fail - without becoming an engineer. The more HR understands how these systems work in practice, the more useful it is to the teams that build and deploy them.

The squad is the starting move. Build enough of them and the question stops being "which function owns AI" and starts being "why are we organised around functions at all". That's a bigger argument, and not one for today - but you don't have to settle it to start.

Don't wait for a reorg to make it official. The future organisation doesn't arrive by redrawing the chart - it arrives one shipped agent at a time. The org chart will catch up when the work has earned it.