The Role, Decoded

What the People team actually does

A modern People function at a global, remote-first fintech like a major fintech/crypto exchange runs a portfolio of workflows that look administrative on the surface and are anything but. On any given day the team processes:

• Job changes — promotions, lateral moves, manager changes, comp adjustments, FTE changes. Every one of these touches Workday and downstream payroll.
• Worker conversions — contractor → employee, employee → contractor, intern → FT, EOR → direct hire across 70+ countries.
• Onboarding and offboarding — new-hire tasks across 10+ systems (Workday, IT provisioning, payroll, benefits, equity admin, ATS close-out, IDP enrollment).
• Employee questions — "How much PTO do I have left?" "How do I update my country of residence?" "What's the parental leave policy in Germany?" — thousands of tickets per quarter.
• People analytics — headcount, attrition, hiring funnel, eNPS, comp-band analysis, DEI reporting.
• Cyclical events — performance cycles, comp cycles, equity refresh, open enrollment, year-end.
• Compliance work — I-9, right-to-work, GDPR data-subject access requests, jurisdiction-specific reporting.

All of this is data-heavy, cross-system, and error-sensitive. An off-by-one on a comp change ripples into payroll; a missed offboarding step leaves access to crypto-custody systems. This is exactly where agentic AI helps — if you can prove the agent didn't touch the wrong worker, can show its work, and gracefully bails to a human when the stakes are high.

The HRKX team — what it is and isn't

The JD names "HRKX" — HR Knowledge Exchange (sometimes "People Operations Center of Excellence" elsewhere). This is the operational heart of People at a global company. It's not HR Business Partners (HRBPs, who advise leaders), and it's not recruiting (TA, separate org). HRKX is the team that:

• Owns the day-to-day operational workflows above
• Maintains Workday business processes, calculated fields, and integrations
• Answers tier-1 and tier-2 employee questions
• Drives system configuration changes
• Partners with Payroll, IT, Legal, and Finance on cross-functional changes

What this role actually builds

Translate that. You'll be building:

• Onboarding orchestration — agent reads the offer, drafts the Workday hire record, prepares the EIB upload, queues IT provisioning, schedules check-ins. Human approves the Workday submission.
• Offboarding checklists — agent assembles a complete leaver checklist (access revocation, equity treatment, payroll cutoff, final pay calc, knowledge transfer). HRBP signs off; payroll signs final pay.
• Policy Q&A — employee asks a question in Slack; agent retrieves from policy library + Workday data, drafts a response. Auto-send for low-risk; HRKX approves for jurisdiction-sensitive answers.
• Survey synthesis — Qualtrics survey closes; agent clusters free-text comments, flags risk themes, drafts the leadership summary.
• Promotion-cycle analytics — agent pulls all promotion packets, scores against rubric, surfaces edge cases for committee.
• Recruiter pipeline summaries — agent ingests Ashby pipeline data, drafts the weekly hiring health snapshot.
• Audit-ready logs — every agent run is replayable, attributable, retained per policy.

The pattern is the same as Compliance: AI proposes, humans dispose. The agent never silently mutates a worker record near a payroll cutoff.

"Full-stack ownership" — what that phrase signals

The JD says: "full-stack ownership role spanning opportunity identification, solution design, deployment, governance, and transfer capability." Decompose that:

You will be asked, in some form: "What does success in your first 90 days look like?" The answer is shaped by this table — not by "I'll have shipped five agents."

The HITL gate over payroll-adjacent workflows

This is the single most important constraint in the entire role. Internalize it:

"Payroll-adjacent" is broader than people think. It includes:

• Job changes (the new job profile may have different bonus eligibility)
• Location changes (tax jurisdiction, equity treatment)
• FTE changes (proration math)
• Compensation changes (obvious)
• Worker type changes (W-2 ↔ 1099, employee ↔ contractor)
• Leaves (paid vs unpaid, statutory minimums)
• Terminations (final pay calc, severance, equity)
• Time-off corrections that touch accrued PTO valuations

Conversely, things that are not payroll-adjacent and can have lighter HITL: drafting policy Q&A responses, summarizing surveys, drafting onboarding welcome emails, scheduling check-ins, generating analytics narratives.

When you're asked "would you automate X end-to-end?" the right framing is: "Is X payroll-adjacent? If yes, the agent drafts; a named human approves. If no, the agent can run with sampled human review."

"Halt or redesign" — the bar for saying no

The JD: "Halt or redesign builds that introduce unacceptable payroll, legal, or data privacy risk. Own that decision and get organizational acceptance before proceeding."

This sentence is testing whether you can be the person in the room who says "we're not shipping this." It's a senior-engineer judgment signal. In interview, when given an aggressive prompt ("can you ship this onboarding agent end-to-end by Friday?"), the answer is not "yes" or "no" — it's:

Notice the moves: own the decision, name the risk, propose a phased path, loop in the stakeholder (Payroll), defer the irreversible step.

The tech stack — what each piece is for

n8n

Low-code workflow orchestration. Self-hostable, developer-friendly, strong AI primitives. In HR contexts it shines because:

• Visual editor lets HRKX operators read and even modify workflows
• Native connectors for Slack, Google Workspace, HTTP, queues, databases
• Built-in AI / Claude / agent nodes
• Self-hosting matters for employee PII residency
• Easy to attach approval steps (the HITL gate)

Your interview-ready framing: "n8n is the orchestration layer — branching, retries, approvals, scheduling. Heavy AI logic and HRIS integrations live in Python; n8n stitches them together with HITL approval steps."

Claude API / Anthropic SDK

• Models: Sonnet for most workflows (good cost/capability), Opus for the hardest reasoning (e.g. policy synthesis across jurisdictions), Haiku for triage classification.
• Tool use: model calls functions you define — read Workday worker, list ATS candidates, propose EIB upload.
• Prompt caching: cache the policy library, the Workday schema, the role rubrics for ~90% discount on repeat calls.
• Structured outputs: JSON schemas for actions the agent proposes — so the HITL UI can render them.
• Long context: long employee history, policy library, full survey free-text in one call.

Python

The glue and analytics layer:

• Workday SOAP/REST client wrappers
• Ashby API integrations
• pandas for headcount, attrition, cohort retention
• Custom MCP servers (Workday MCP, ATS MCP, policy MCP)
• EIB transformation scripts (pandas → CSV with Workday's exact column shape)
• Eval harnesses

MCP (Model Context Protocol)

Anthropic-led protocol for standardized agent access to tools and data. Three primitives: tools, resources, prompts. In HR, MCP is how a single agent can reach into Workday, Ashby, the policy library, and the ticketing system without you re-implementing those integrations per agent.

The killer HR pattern: a Workday-read MCP server that exposes worker, position, supervisory-org, business-process queries as resources; a separate Workday-write MCP that only proposes EIB uploads (never writes directly), gated by HITL.

Workday

The HRIS at the center of everything. You are expected to know — at depth — the worker model, business processes, EIB uploads, calculated fields, condition rules, integration architecture (Studio, Core Connectors, RaaS, web services), and the payroll dependencies. See 05-deep-dive-secondary.

Ashby

The ATS The company uses (the JD URL is jobs.ashbyhq.com; it's also a "nice to have"). Modern, API-first, much friendlier than Greenhouse or Lever. Know its API shapes: candidates, applications, interviews, offers, jobs, custom fields. See 14-domain-context.

Cross-jurisdictional privacy constraints

The company has employees in 70+ countries. Your design must respect:

• GDPR (EU) — data minimization, purpose limitation, right to access (DSAR), right to erasure (right to be forgotten), data-residency considerations.
• UK GDPR — similar to EU GDPR but post-Brexit divergence.
• US state privacy — California CCPA/CPRA (employee data is in scope), Colorado, Virginia, etc.
• APAC — Singapore PDPA, Japan APPI, Australia Privacy Act, India DPDP Act.
• Employment law cross-border — what you can store, where, for how long, varies wildly.

What this means for design:

• Don't send employee PII to third-party APIs unnecessarily. Tokenize or use worker IDs when possible.
• Data classification first — Public / Internal / Confidential / Restricted (e.g., comp, health, performance). Restricted data has tight rules about where it travels.
• Audit logs must persist for the regulatory window, but DSAR / erasure requests must be honored — design log retention with that in mind.
• Sound aware in interview, not lawyerly: "I'd flag this for a privacy review before sending EU employee PII to a US-based model API."

Soft signals to expect in the JD

• "Halt or redesign" — they want someone willing to say no.
• "Multiply the People team's capability" — you are not building tools that only you can operate. Runbooks, templates, training are deliverables.
• "Drive adoption, not just delivery" — measure usage, not just shipped builds.
• "Track and report on automation impact" — manual hours eliminated, error rates reduced, payroll exceptions avoided. Have numbers on past work if you have them.
• "Systems thinker with strong implementation mindset" — no architect-astronauts. You write the code.

The seniority clause

The JD asks for 5+ years software engineering, 2+ in AI/agentic systems, and 2-3+ in HR/People tech, and deep Workday. Few candidates have all four cleanly. If you don't:

The two thin spots most candidates hit:

• Thin on Workday with strong AI — own it, redirect to your AI agentic depth, show you've read this folder's Workday chapter cold.
• Thin on AI agents with strong HR/Workday — own it, show recent depth (this folder, side projects, a small MCP server you wrote), redirect to your operational instincts.

See 02-positioning-from-scratch for specific language.

What to ask them

1. "What's the highest-stakes People workflow currently being considered for AI assist? Where is the human approval gate non-negotiable?"
2. "How do you measure today whether an agent-drafted policy answer or analytics narrative is good enough before it's used?"
3. "When an automated change to a worker record is later questioned by Payroll or Legal, what does your replay/audit story look like?"
4. "Where do n8n, custom Python, and MCP servers cleanly divide responsibilities in your existing builds — and where is that boundary still being figured out?"
5. "Which Workday integration patterns are in production today — Studio, Core Connectors, RaaS, Prism — and which gives you the most pain?"
6. "What does the HRKX team's first month of working with the AI architect look like? Where would they expect to be self-sufficient by month 6?"

These show you're thinking about the role as an architect and operator, not a coder-for-hire.

✓ Check yourself

Answer from memory before opening each one.

1. The onboarding agent is ready, and the product owner asks you to let it write the Workday hire record directly, since a person approves the offer anyway. What do you answer, and what does the agent do instead?

   Show answer

   Keep the human gate on the job-data write. A hire sets pay, tax jurisdiction, benefits eligibility and worker type, so the agent drafts the record in human-readable form and a named person approves before anything commits. Approving the offer is a different decision from approving the record, and the second one is where payroll errors start. See The HITL gate over payroll-adjacent workflows.

2. Sort these into payroll-adjacent or not: a location change for an engineer moving from Berlin to Lisbon, a drafted parental-leave answer in Slack, a survey summary for the leadership team, and an FTE change from 1.0 to 0.8. What decides each one?

   Show answer

   The location change and the FTE change are payroll-adjacent. The first moves tax jurisdiction and equity treatment, and the second changes proration. The policy answer and the survey summary are not, so they can run with sampled review. The test is whether the action can alter pay, comp, status, benefits eligibility or tax. See The HITL gate over payroll-adjacent workflows.

3. An executive asks for the full onboarding agent by Friday, and payroll locks in two weeks. Describe your reply and the order of its parts.

   Show answer

   Say yes to the parts that are not payroll-adjacent, name the Workday write as the risk, propose a phased plan that gets most of the value behind a gate, and loop in Payroll Ops before committing a date. You own the decision, you state the risk, and you defer the irreversible step instead of giving a flat yes or no. See The "halt or redesign" bar.

4. Why does the Workday-write MCP server only propose an EIB upload, while the read server exposes worker queries directly? What would you lose if you let the write server commit?

   Show answer

   Reads cannot change pay, so they can be broad. A write that only produces a proposed upload keeps the commit behind the approval gate and gives you a reviewable artifact. If the server committed, any prompt error or bad tool call would become a worker-record change with no human between them. The split puts the gate in the architecture instead of in the prompt. See The tech stack.

5. Legal asks you to honour an erasure request, but your audit log must be kept for the regulatory window. How do you design for both, and what do you avoid sending to the model API in the first place?

   Show answer

   Design retention up front: keep the log's evidence of what the agent did, and key records by worker ID so that identifying fields can be deleted or redacted without destroying the audit trail. Avoid sending raw employee PII to a third-party model API when an ID or token will do, and flag EU data going to a US-hosted API for privacy review. See Cross-jurisdictional privacy.

6. A candidate has deep Workday experience and no shipped agent. A second has the reverse. Which gap does the guide treat as more recoverable, and what does each need to show?

   Show answer

   Neither is ranked as fatal. The guide treats both as ramp gaps if the candidate names the gap plainly and shows adjacent depth. The Workday-strong candidate needs a small shipped agent with approval gates. The AI-strong candidate needs fluency in the worker model, EIB and payroll locks. The deciding factor is honesty plus evidence of velocity. See The seniority clause.

Takeaway

• This role is judged on whether you build agents that take real actions in HR processes with oversight, so the unit of design is the approval gate, not the model call.
• No agent action that affects pay, comp, employment status, benefits eligibility or tax executes without a named human approving a readable proposal, and "payroll-adjacent" covers location, FTE, worker type, leave and termination changes.
• Workflows that are not payroll-adjacent, such as policy answers and survey summaries, can run with sampled review, so risk decides the level of oversight, not the technology.
• When asked to ship something risky fast, own the decision: name the risk, offer a phased plan, involve Payroll, and defer the irreversible write.
• n8n orchestrates, Python holds the HRIS integrations and eval code, Claude does the reasoning, and MCP gives agents one governed way to reach Workday, the ATS and policy data.
• Employee PII from 70+ countries means classify data first, send IDs instead of identities where you can, and design log retention so erasure requests and audit duties both hold.

The role is clear; next is how to talk about it honestly when your own background is uneven. → Positioning From Scratch

Further reading

• Tool use with Claude — Anthropic docs. How a model proposes tool calls that your code executes, which is the mechanism behind every approval gate here.
• Model Context Protocol specification — Model Context Protocol project. The tools, resources and prompts primitives and the host, client and server roles.
• Prompt caching — Anthropic docs. What can be cached, such as a policy library, and how repeat calls get cheaper.
• Building effective agents — Anthropic, 2024. The workflow versus agent distinction and when to add autonomy.
• Regulation (EU) 2016/679 (GDPR) — European Union, 2016. The primary text for minimisation, purpose limitation, access and erasure.