HR teams are being asked to do more than ever. Everest's Tech Provider Spotlight explores how HR Service Delivery is evolving. Read Now.
Previously, I argued that a single mega-suite is not a strategy. This tackles the harder question: what should replace it?
The answer is not another front door. It is a governed HR service brain: one consistent service layer that can sit behind Copilot, Teams, email, mobile, the portal, and whatever comes next.
That matters because employees do not behave like your systems diagram.
In recent research commissioned by Applaud, only 26% of employees said they start with an HR system or portal, only 6% said they receive help instantly via AI or chat, and employees said they can resolve only about 47% of HR needs themselves. The architectural problem is not discoverability alone. It is inconsistency across channels, tools, and handoffs
The timing is awkward in exactly the way that makes this topic urgent. AI is now mainstream in the enterprise, but value is still disappointingly uneven. McKinsey found that 88% of organisations reported regular AI use in at least one business function in 2025, yet only 39% reported EBIT impact at enterprise level; in the same research, 23% said they were scaling agentic AI somewhere in the business, but no more than 10% were scaling it in any single function.
IBM reports a similarly sobering gap: only 25% of AI initiatives have delivered expected ROI and only 16% have scaled enterprise-wide.
At the same time, MACH Alliance research suggests a strong relationship between composable maturity and realised AI value, with 78% of firms with mature composable technology reporting clear AI ROI versus 13% of those still in planning. That last figure comes from an industry body rather than a neutral public regulator, so it is best treated as directional rather than definitive, but the pattern is hard to ignore (McKinsey).
That is why I take a sharper position than the usual “be agile” advice. In the agentic era, the unit of HR design is no longer the portal, the chatbot, or even the workflow. It is the domain specialist: a modular HR service component focused on a business capability such as leave, payroll, onboarding, policy, or manager support.
Agent-to-agent (A2A) design should then allow enterprise front doors to hand work to those domain specialists, while IT controls identity, security, logging, and access policies. That split is now technically more practical because the ecosystem is converging on open patterns for tools and collaboration.
Google’s Agent2Agent protocol is designed for agent collaboration across frameworks and vendors, Anthropic’s Model Context Protocol (MCP) standardises how assistants connect to external tools and data, and Microsoft Entra Agent ID is turning agents into first-class identities with authentication, authorisation, and auditability. NIST’s AI RMF reinforces the same lesson from a governance angle: govern, map, measure, and manage, with governance treated as a cross-cutting function (Google).
The thesis is simple: a front door is not a strategy. In 2026, the winning HR architecture is one brain, many channels; bounded autonomy instead of platform sprawl; and HR domain ownership inside an enterprise governance frame that IT can trust.
There is a sentence more HR leaders need to hear from their technology partners: employees do not care which assistant answered them. They care whether the answer was right, whether it was consistent, and whether the next step actually worked. That is why the most dangerous architectural mistake in HR today is to confuse a good front end with a good service model. Copilot is not an HR strategy. Nor is a prettier portal. Nor is a better search bar. Those are entry points. Strategy lives behind them.
This matters more now because the broad AI market has already shown the limits of horizontal deployment. McKinsey describes a “gen AI paradox”: more than 78% of companies have deployed generative AI in at least one business function, yet more than 80% still report no material contribution to earnings from those initiatives. Its explanation is blunt and useful. Horizontal copilots and chatbots have spread quickly, but higher-value vertical use cases remain trapped in pilot mode. In other words, general-purpose access to AI is not the same thing as domain-level transformation. HR should read that as a warning and an opportunity (McKinsey).
The implication is that the future of HR service is not one giant assistant connected to everything. That model creates a giant operational blast radius. Every new channel, every new prompt pattern, every new connector, and every new permission rule increases the chance that two employees asking the same question in two different places will get two different answers. McKinsey’s recent architecture work calls out the danger directly: without an orchestration layer, dozens of agents can create friction and contradiction, while an agentic mesh provides coordination, enforces business rules, and maintains a shared source of truth. That is a more useful mental model for HR than the simplistic “single front door” dream.
The answer is not “more best-of-breed”. It is business-capability architecture. McKinsey calls the pragmatic middle path “domain-based modernization”: modernise the business domains that matter most, using composable building blocks rather than forcing an enterprise-wide rip-and-replace. That is exactly the right frame for HR service, because employees experience HR as domains of need, not as application categories: pay, leave, benefits, policy, onboarding, offboarding, manager guidance, exceptions. Organise around those domains and you gain both speed and control.
The most useful way to make composable HR architecture concrete is to stop talking about “the stack” and start talking about the HR Service Brain. The below diagram is grounded in the same principles now showing up across primary sources: McKinsey’s agentic mesh, Google’s A2A collaboration layer, Anthropic’s MCP tool-and-context standard, and Microsoft’s move to treat agents as governed identities rather than free-floating bots.
In plain English, the HR Service Brain is a governed middle layer between enterprise front doors and HR systems of record. Front doors are where employees ask. The brain is where service logic lives. Domain specialists sit inside that brain. Tools, records, workflows, and content sit beneath it. That separation matters because it lets IT standardise identity, access, and approved channels, while HR continuously refines the service logic without waiting for every change to be rebuilt in every interface (Microsoft).
The technical pattern behind this is worth stating clearly because it helps HR leaders talk credibly to CIOs. In practice, MCP and A2A do different jobs. MCP is about giving assistants secure, standardised access to tools, data sources, prompts, and resources. A2A is about letting one agent discover another agent’s capabilities, exchange information, and collaborate on short or long-running work.
Microsoft’s own direction reinforces that split: Copilot Studio now supports multi-agent orchestration, Teams’ AI library is adding support for both MCP and A2A, and Entra Agent ID supports OAuth 2.0, MCP, and A2A so that agents can be authenticated and governed like any other enterprise actor. That is why “agent-to-agent” should not be dismissed as vendor theatre. It is becoming infrastructure.
The strategic value of the domain specialist is that it narrows the answer space. A payroll specialist does not need to know everything about HR. It needs to know payroll policy, payroll context, payroll tools, payroll escalation rules, payroll exceptions, and payroll risk limits. That narrower domain makes quality easier to govern, change easier to ship, and failure easier to contain. It also aligns with the shape of current enterprise AI value creation: the most useful gains are seldom coming from one enormous model trying to do everything; they are coming from bounded, domain-aware systems that plug into enterprise controls. [11]
There is a subtle but important organisational point here as well. HR should not ask IT to own HR service improvement end to end. That model is too slow. But HR also should not ask IT to approve a thousand direct integrations from every front door to every HR system. That model is too risky. The HR Service Brain is the compromise mature organisations need: IT governs the doorway, HR governs the domain. Some organisations will build that layer themselves; others will buy it. A platform such as Applaud can play that role. But the architecture principle matters more than the vendor label.
The strongest objection to agentic HR architecture is also the right one: autonomy multiplies risk. The wrong response is to ban autonomy. The right response is to bound it. That is why composable HR architecture should be designed around blast radius, not novelty.
McKinsey’s agentic architecture work warns against uncontrolled autonomy, fragmented system access, lack of observability, and agent sprawl. NIST says governance should be cross-cutting, continuous, and present throughout the AI lifecycle. Microsoft’s answer is identity, access control, and auditability for agents. These are not separate conversations. They are the same architecture conversation seen from three angles. [12]
The Blast Radius Ladder is a useful way to explain this to both HR and IT. The principle is simple: the more an agent can do, the smaller its scope and the tighter its controls should become. This is the opposite of the “give one assistant all the permissions” instinct.
Centralised dependency is not the same as governance. When every meaningful change depends on enterprise IT backlog, HR does not become safer. It becomes slower, more fragile, and less able to correct drift. The architecture goal is not to stop HR innovating. It is to let HR innovate inside a blast radius small enough for IT to trust. That is what “governed autonomy” actually means.
The operating split below is the one I would recommend to most large organisations.
| Layer | IT should own | HR should own | Shared accountability |
| Enterprise front doors | Approved channels, identity, access, device and security standards, connector policies | HR entry patterns, content style, service intent design | Escalation guardrails and user experience standards |
| HR Service Brain | Protocol standards, logging, observability, environment controls | Domain logic, knowledge, specialist agents, journey design, service improvement | Risk thresholds and model-change governance |
| Tool and action layer | Least-privilege access, API patterns, secrets management, monitoring | Action policy, approval rules, exception handling, content validation | Periodic access reviews and incident response |
| Decision boundary | Prohibited or restricted actions, legal review triggers | Human-accountable decision ownership | Audit, DPIA, and policy refresh |
This split also fits the regulatory reality in Europe. Under the EU AI Act, certain AI systems in employment are high-risk by definition, including systems used for recruitment or selection and systems used to make decisions affecting terms of work relationships, promotion or termination, to allocate tasks based on personal traits, or to monitor and evaluate workers’ performance and behaviour.
Deployers that are employers must also ensure AI literacy, and when they use high-risk AI systems in the workplace they must inform workers’ representatives and affected workers; where applicable, deployers must use the provider’s Article 13 information to support GDPR impact-assessment obligations.
The lesson for HR service architecture is straightforward: keep service automation away from employment decisioning unless you are deliberately entering a high-risk regime and are prepared to meet the obligations that follow (EU Law).
Introducing the Permission Pyramid:
The practical rule is easy to remember. Let agents inform broadly. Let them prepare often. Let them act only when the action is low-risk, rule-bound, logged, and reversible. Let them escalate whenever confidence, sensitivity, or policy ambiguity rises. And reserve employment decisions for accountable humans unless and until you are intentionally operating inside a compliant high-risk framework.
That is not timid. It is how you scale safely (NIST).
Most HR architecture programmes fail because they start with products, not service demand. The better starting point is what I would call demand archaeology: finding where employees actually start, where they drop out, where they channel-hop, where managers become shadow HR, and where the same issue gets asked three different ways. The goal is not an encyclopaedic taxonomy. It is a short list of domains where consistent service would remove the most friction. For most organisations, that list will quickly reveal a handful of candidates: leave, pay, policy, onboarding, case intake, and manager support.
Once those domains are defined, the next move is to create a canonical HR logic layer. This is the part many teams skip because it feels unglamorous. It is also the part that separates serious architecture from AI theatre. Canonical logic means one approved answer model, one set of knowledge owners, one validation cycle, one expiry and review policy, one access model, and one escalation path per domain. NIST’s AI RMF is useful here because it refuses to treat governance as a one-off sign-off. Governance is supposed to infuse mapping, measurement, and ongoing management. In other words, your knowledge model, tool permissions, analytics, and review rhythm are all part of the architecture, not admin overhead.
The third move is to define a handoff contract between front doors and domain specialists. This is one of the least discussed and most important design steps. A handoff should not just pass a question. It should pass a governed context packet: identity, worker type, country, business unit, service domain, relevant history, confidence level, policy scope, audit ID, and permitted next actions. Without that packet, “one brain, many channels” becomes “many channels, repeated context loss”. With it, you get true handoff integrity. Google’s A2A protocol exists precisely because dynamic multi-agent systems need a standard way to discover capabilities, exchange information securely, and coordinate work across time horizons; Microsoft is clearly building in the same direction.
The fourth move is permission design by domain, not by tool. This is where many organisations will need to unlearn old habits. A write permission in one context is not the same as a business permission in another. Creating a case is not the same risk as changing a bank account. Generating a standard employment letter is not the same risk as approving exceptional leave. Domain-based permissioning is slower to design once, but far safer and faster to scale thereafter. Microsoft Entra Agent ID is useful evidence that the market is moving this way: specialised agent identities, policy templates, standard protocols, and audit logs. Your architecture should assume that each meaningful agent will eventually need its own identity, access pattern, and sponsor.
The fifth move is a weekly improvement loop. That sounds operational rather than architectural, but it is both. If service quality drifts and nobody notices for a quarter, your architecture is not modern; it is merely digital. The improvement loop should review failed handoffs, channel-hop rate, contradictory answers, stale knowledge, repeated escalations, risky tool calls, and reopen patterns. The real power of composable architecture is that it makes those fixes local. You do not need to rewrite the portal to improve payroll explanations. You improve the payroll specialist. That is what “modular” should mean in HR.
Learn how to transform HR into a people-first function that builds trust, designs better experiences, and drives real business results in this interactive, 10-minute guide. Read Now.
Most HR service scorecards are now too shallow for the architecture they are trying to govern. Portal traffic is not an outcome. Deflection on its own is not a strategy. In a multi-channel, agentic environment, the metrics that matter are the ones that reveal consistency, continuity, and correct completion.
Consistency Score =
(same approved answer + same permitted action + same escalation path across equivalent intents) / total sampled equivalent intents
The point of this metric is not mathematical elegance. It is to force the right conversation. If an employee can ask “What parental leave am I entitled to?” in Copilot, the portal, email, or chat, and the answer changes depending on venue, the organisation does not have a channel problem. It has a service architecture problem.
A practical executive scorecard would look like this:
| Metric | What it reveals | Why it matters |
| Consistency score | Whether the same intent gets the same approved outcome across channels | Measures architectural coherence, not just experience polish |
| Channel-hop rate | How often employees must switch channel to finish the same need | Exposes friction and hidden cost |
| Handoff integrity | Whether context survives from AI to human without repetition | Protects trust in mixed human-AI service |
| Action success rate | % of agent-triggered actions completed correctly without repair or reopen | Separates useful automation from noisy automation |
| Exception escalation rate | Where low-confidence or high-risk intents surface | Helps tune autonomy and staffing |
| Knowledge freshness risk | Share of high-use content overdue for validation or showing conflicting outcomes | Prevents drift, not just search failure |
The ROI case then becomes much more credible, because it is rooted in service economics rather than AI theatre. A public benchmark from Applaud’s research suggests employees currently resolve only about 47% of HR needs themselves. An academic field study in customer support found that AI assistance increased worker productivity by 15% on average across 5,172 agents, with larger gains for less experienced and lower-skilled workers. HR should not import that number uncritically, but it is a sensible directional benchmark for assisted Tier 1 casework.
Assume an organisation handles 100,000 annual HR service intents. If self-service completion improves from 47% to 60%, that creates 13,000 additional Tier 0 resolutions. If each one avoids 12 minutes of HR service time, that releases 156,000 minutes, or 2,600 hours, of HR capacity. At a fully loaded cost of £40 per hour, that is about £104,000 in annual capacity released. If AI-assisted Tier 1 work also improves productivity by a cautious 10% rather than the 15% observed in the QJE study, the economic case improves again. The important point is not the exact number. It is that composable architecture improves value by reducing variance, repair work, and repeated handoffs, not just by “deflecting tickets”.
The case evidence, while mostly published by Microsoft and McKinsey rather than audited independently, points in the same direction. Wells Fargo built an agent for 35,000 bankers across 4,000 branches that gives instant access to guidance on 1,700 internal procedures. Microsoft says 75% of searches now happen through the agent and response time dropped from 10 minutes to 30 seconds. That is not an HR example, but it is exactly what many HR teams need: a governed domain specialist that collapses knowledge friction in the flow of work.
HCLTech is closer to the mark. Microsoft says its “Super Assistant” routes HR tickets to a dedicated HR resolver agent, which then interacts with employees, connects to backend systems, and works toward resolution before handing off to a human when needed. Microsoft reports expected case resolution 40% faster and the ability to redeploy 30% of support staff. The important lesson is not the vendor stack. It is the pattern: one front door, then a specialist resolver, then bounded action, then human handoff where needed (Microsoft).
McKinsey’s recent enterprise architecture examples add two more patterns. A European bank used an AI-mesh architecture to automate analytical work in corporate credit processes, then scaled via reusable “atomic” agents. A large Latin American bank used an “agent factory” of more than 100 AI systems to modernise a 20-year-old corporate banking platform; McKinsey says the result was a 60% reduction in engineering time and $250 million in savings from a $600 million programme. HR does not need that scale of spending, obviously. But the architectural lesson is critical: organisations create leverage when they reuse capabilities across domains instead of rebuilding logic channel by channel.
The uncomfortable truth is that many HR leaders are still talking about AI as if the main question were whether to launch a better assistant. It is not. The real question is whether HR is willing to own the service domain strongly enough to stop outsourcing coherence to whatever enterprise front door happens to be fashionable this quarter.
That means a change in ambition. The aspiration should no longer be “one place to go for HR”. That was always a fantasy. The aspiration should be one service brain that can meet employees anywhere. If the answer, action, and escalation path are consistent, the channel becomes less important. If they are inconsistent, the channel becomes a source of risk.
This is also where HR should be more demanding of IT, not less. Ask for identity, doorway standards, access controls, protocol support, logs, and observability. Ask for an enterprise frame that can support MCP, A2A, and nonhuman identities properly. But do not hand over the service domain itself. If HR does not own the knowledge, journeys, domain permissions, quality scoring, and improvement loop, then HR will never really own service innovation either.
If every assistant in your company gives a different HR answer, you do not have an AI strategy. You have a consistency failure. Fix that, and composable HR architecture stops sounding technical. It starts sounding like what it really is: the operating model that lets HR become faster, safer, and more human at scale.
How Applaud Helps You Make It Happen
At Applaud, we believe employees are a company’s most important customers. That’s why our technology is built entirely from the employee’s point of view—delivering more human, intuitive, and rewarding HR experiences that empower HR teams to do more for their people.
If you’re ready to turn employee-first HR from vision to reality, we’re here to help. Get in touch to see how Applaud can transform your HR Service Delivery and create a workplace where employees truly thrive.
Duncan Casemore is Co-Founder and CTO of Applaud, an award-winning HR platform built entirely around employees. Formerly at Oracle and a global HR consultant, Duncan is known for championing more human, intuitive HR tech. Regularly featured in top publications, he collaborates with thought leaders like Josh Bersin, speaks at major events, and continues to help organizations create truly people-first workplaces.