Finance Got There First.
Anthropic's CFO Krishna Rao no longer runs backward-looking meetings. The architecture that made that possible isn't proprietary. HR just hasn't built it yet.
Leaders sit down to talk about what happened. Attrition moved. Headcount slipped. A comp band fell out of market. By the time anyone surfaces the numbers, the hour is gone. The strategic conversation never starts.
It’s an architecture problem.
Finance solved it. Not by working harder or hiring more analysts. By building three layers that handle the backward-looking work automatically, so the humans in the room only have to do one thing: decide.
A live connection to the data. A library of institutional knowledge the model can call. Workflows that execute what you approve.
That’s the pattern. It runs in production today. And every single layer translates directly to HR.
Here’s how it’s built:
Krishna Rao runs finance at Anthropic. A lengthy but interesting video here, where he breaks it down at roughly minute 39:00.
In a recent conversation about how his team actually works, he said something that most executives would be careful not to say: their meetings no longer spend time on what happened. Claude has already done that part. By the time anyone sits down, the variance analysis is complete, the drivers are identified, every number that moved has an explanation attached to it. The agenda is entirely about what to do next. A weekly report that used to consume hours now takes thirty minutes. The monthly financial review arrives ninety to ninety-five percent complete. Rao didn’t frame this as a productivity win. He called it a structural change in how the function operates.
That framing matters. This isn’t a pilot program or a vendor success story. It’s a production system, running today, inside a real organization, built on an architecture that anyone could replicate. HR has been chasing this exact transformation since Dave Ulrich named it in 1997 the shift from transactional to strategic, from backward-looking to forward-facing. Backward-looking work was always there, always urgent, always consuming the hours that strategic thinking required. AI doesn’t dissolve that tension through aspiration. It dissolves it through execution if someone actually builds the thing.
What Anthropic’s Finance Team Actually Built
Every legal entity at Anthropic now produces its statutory financial statements using Claude a human checks the output, but the model does the construction. They built a real-time analytics platform that used to require hours of manual work to produce a memo on what was moving the numbers. They assembled a shared library of more than seventy finance-specific skills, accessible to anyone on the team through a common repository. That library is the part most organizations miss. It isn’t a folder of clever prompts. It’s the team’s institutional knowledge, made persistent and callable.
The architecture underneath all of this has three layers. First, a live system-of-record connection the model reads and writes against real data, with a human confirmation gate before anything executes. Second, the skill library domain expertise encoded in reusable form, not recreated from scratch each session. Third, the workflow layer recurring processes like the monthly financial review automated end-to-end, with human judgment applied at the output stage, not the production stage.
The skill library is not a collection of clever prompts. It is an institutional knowledge layer built on top of the model, encoding the team's collective expertise in callable, reusable form.
All three layers translate directly to HR. What follows is what they look like when actually built.
Tool 1: The “HRIS” MCP
I am purposely keeping this agnostic but I did built on specific platforms and open sourced code. The foundational layer is a direct connection between Claude and your system of record. The foundational layer is a production MCP server built against an enterprise HRIS, with write operations gated behind a confirmation step before execution. Write-capable HRIS MCPs with full operational coverage remain rare in public documentation most published implementations stop at read-only queries, which is where the architecture gets interesting but also where most teams stop building.
What this means in practice: you can ask Claude a natural language question about workforce data, and it executes real HRIS API calls, returns structured results, and proposes actions that require your explicit approval before they run. The confirmation gate is not a UX nicety. It is the architectural decision that makes write access responsible. (FYI I have done this against a well known HCM).
The API bridge layer is where most MCP implementations fail on enterprise systems. Many HRIS platforms expose a mix of legacy and modern API surfaces. Bridging those two is not complicated once you understand both, but most teams give up at the seam or build against only the modern surface, losing access to the majority of the platform's functionality. A complete architecture covers the full operational surface: requisitions, headcount, compensation, worker profiles, and organizational structure. Cost and performance are factors but solvable, more on those pieces later.
Tool 2: The Comp Planning Dashboard
Compensation decisions have a bounded option set. The compa-ratio is either below threshold or it isn’t. The budget envelope is either sufficient or it isn’t. The recommended adjustment is calculable from a formula. This is where the HRIS MCP should reach in and do something not just surface data, but propose a specific action, pre-populated and ready to execute. The HRBP reviews it, confirms, and the change request is written to the HRIS directly. One gate. One action. Fully auditable.
This is the structural difference between a dashboard and a system. A dashboard shows you the problem. A system proposes the solution and executes it when you say go. The confirmation gate is not a formality it is the moment where human judgment enters the loop, reviews the proposal, and takes ownership of the decision. Everything after that is administrative work the model handles.
Tool 3: The Talent Signal Internal Mobility Layer
Internal mobility is too contextual for direct write actions. The employee journey branches in too many directions lateral move, promotion, stretch assignment, cross-functional rotation, development plan each with different implications for comp, reporting structure, and career trajectory. No model should be choosing between them without a human. But the human-in-the-loop experience can be dramatically better than what exists today. Right now an HRBP sees a flight risk and opens a blank calendar invite. What they should get is a pre-built conversation brief and, after the conversation, a structured set of actions to choose from. The human picks the path. The MCP handles the execution.
The design principle here is different from comp. Comp has a right answer within a bounded range the model can propose it. Mobility has a right conversation, followed by a right path chosen by a human who was in the room. The model's job is to make that human as prepared as possible going in, and as unencumbered as possible coming out. The HRBP owns the judgment. The system owns everything else.
Tool 4: The HR Variance Analysis
Rao’s sharpest observation was about the meeting agenda itself. When AI handles the backward-looking work, humans get the time back for the forward-looking kind. Here is what that looks like applied to the standard HR business review. ((FYI if you want to ‘kind of’ open source most of this and use a data lake to handle this complexity in a simplistic output way: “HCM” → Airbyte → MinIO (Iceberg tables, cataloged in Polaris) → dbt Core + Spark → Trino → Claude via MCP))
Vendors
Think of this as outsourced compliance for stage 1. What Rao described isn’t a feature of being Anthropic. It’s a feature of having built the right architecture. His team didn’t buy a product. They built a system on top of a model they could trust, in a domain they understood completely. The seventy-skill library exists because someone on that team knew which seventy skills were worth encoding. That knowledge doesn’t come from a vendor. It lives inside the function, or it doesn’t exist at all.
HR has not done this, at least most have not. The reasons are real: procurement cycles that favor vendors over internal builders, HRBP job descriptions that have never included infrastructure skills, a professional culture that treats technology as something IT delivers rather than something the function designs. Those are structural conditions, not permanent ones. They change when individuals decide to build rather than wait, and its happening now.
The forward-looking meeting Rao described is not waiting on a product roadmap or a budget cycle or a vendor’s next release. The HRIS connection exists. The comp planning layer exists. The internal mobility signal exists. The variance analysis workflow exists. None of it required a procurement cycle or an IT project plan. It required understanding the domain well enough to know what to build, and the decision to treat HR’s own infrastructure as something worth designing.
Sanjeev Sharma is a Principal for Workforce Innovation and AI Strategy, focused on rapid prototyping at the intersection of AI, HR technology, and organizational design. He writes The Work Design Lab at sanjeevsharma.com. Views are his own.
Appendix A
What This Actually Costs
A token economics model for enterprise HR AI deployment at scale
Cost is the first objection that kills enterprise AI conversations before they start. It is also, at current API pricing, almost never the real constraint. What follows is a worked model for a deployment most CHROs would recognize: a 2,000-person HR function serving a 120,000-person organization.
At current API pricing for a production-grade model, blending input and output tokens, 1.1 billion tokens runs approximately $3,000–5,500 per month at list price. Prompt caching changes the math significantly. System prompts, HRIS schema context, org structure, and skill library definitions are all static content that caches across sessions. With aggressive caching, that figure drops 60–70%.
Where the Real Costs Live
Token spend is not the constraint. The actual cost structure of a deployment like this has four components that matter. My “kind of” open sourced build, “HCM” → Airbyte → MinIO (Iceberg tables, cataloged in Polaris) → dbt Core + Spark → Trino → Claude via MCP is CHEAP, 120,000 person companies can deploy better scenarios but will cost more.
BUILD AND INTEGRATION
Three to six months of a practitioner who understands both the HR domain and the underlying infrastructure. One person, possibly two. This is the scarcest input in the system not because the technical skills are rare, but because the combination of domain depth and build capability is. Most HR functions do not currently employ this profile.
CHANGE MANAGEMENT
Getting 2,000 HR practitioners to use new tools instead of existing workflows is where enterprise AI deployments actually succeed or fail. The technology is the easier problem. Adoption at scale requires deliberate investment: training, workflow redesign, manager accountability, and a visible sponsor who uses the tools themselves.
DATA QUALITY
The variance analysis is only as good as the HRIS data it runs against. Most enterprise HR data is substantially messier than anyone acknowledges until a model surfaces the inconsistencies at scale. Budget for a data remediation phase before expecting clean analytical output. This is not an AI problem. It is a pre-existing condition the AI makes visible.
GOVERNANCE
Who owns the skill library. Who approves updates. What the confirmation gate policy is for write operations at different levels of the organization. What the audit trail looks like for compliance purposes. These are not technology decisions. They are policy decisions that technology enforces. They need to be made explicitly, before deployment, not discovered during an incident.
Appendix B
The Skill Library
Four production-grade HR skills. Design intent, input schemas, and output contracts. Skills 01-03 abstracted, hey, I’m not giving away the farm for free just yet but these templates will help you assemble your own, feel free to reverse engineer. Skill 04 shown in full.
The skill library is where the institutional knowledge of the HR function becomes persistent and callable. Each skill below shows the design intent, input requirements, and output contract.
I saved this as png for reference.
