Section A · Orient

The Role, Decoded

What "AI agents in HR" actually means at a global fintech/crypto exchange — what each piece of the stack is for, why payroll dependencies are the killer constraint, and the bar this role is being held to.

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
Why this matters for the interview

You're not joining a "People AI Lab." You're embedded with the operators who run the actual workflows. They will be your primary stakeholders and your handoff target. Read the JD line "transfer capability back to the People team" with that lens.

What this role actually builds

The JD's core sentence

"Architect and build agentic workflows using n8n, Claude API, Python, and MCP that take real actions in HR processes with appropriate human oversight and approval gates."

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:

PhaseWhat you doWhat you'd say in interview
Opportunity IDSit with HRKX, watch them work, find the 20% of tasks that consume 80% of time and meet the AI fit profile."I'd start by shadowing the ops team for a week and instrumenting where time goes before pitching builds."
DesignRisk-tier, sketch data flows, name the Process Owner, design the audit log first, then the agent."Risk tier, data classification, HITL points, and audit log before I write a line of agent code."
DeploymentBuild in n8n + Python + Claude + MCP, with staging and payroll-calendar-aware change windows."I deploy through a staging environment that mirrors Workday sandbox; production cutovers avoid the 72h window around payroll lock."
GovernanceMaintain the risk register, audit logs, named owners, and the halt criteria."Every build has a Process Owner, a documented data flow, and a halt criterion before it ships."
TransferRunbooks, templates, training the HRKX team to extend and operate without your involvement."I treat HRKX professionals as the long-term operators; my deliverable includes the runbook and the trained handoff, not just the workflow."

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:

The rule

No agentic action that affects pay, comp, employment status, benefits eligibility, or tax may execute autonomously, ever. Period. Every such action passes through a human approval gate, with the human reviewing the proposed change in human-readable form before it commits.

"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:

The pattern

"Yes for the parts that aren't payroll-adjacent. For the parts that are — the Workday job-data write — I want a human approval gate before we go live, and I want to run it past Payroll Ops because we're entering a payroll-lock window in two weeks. Let me come back with a phased plan that gets us the bulk of the value while keeping the high-risk write behind a gate."

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:

Believe this

JDs cast wide. Recruiters bring in candidates with adjacent depth when there's signal somewhere else. If you're interviewing, someone decided your conversation was worth their hour. Confirm that. Don't try to convince them of years you don't have.

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.