The Five-Layer Architecture: Separating System of Record from System of Action
Keep your HCM. Move the experience above it.
A benefits team spent nine months trying to make one question answerable inside their HCM: "If I go on parental leave in March, what happens to my equity vesting and my bonus?" The data existed. Vesting schedules lived in one module, the bonus plan in another, the leave policy in a PDF attached to a third. Every configuration cycle got closer and never arrived. The answer required reasoning across three systems that were never designed to talk to each other, and the HCM had no place to put that reasoning.
That question is not a data problem. It is an architecture problem. And the most important architectural choice you will make is this: separate the system of record from the system of action. Choose your HCM for governance, accuracy, and reliability. Build the experience above it. Nothing in this chapter is rip-and-replace. The HCM stays. What changes is what you stop asking it to do.
The system of record is the trusted source of employment and payroll data. The system of action is where a person expresses intent and work gets done. Most HR technology pain comes from asking one system to be both.
What each layer is for, and what it is not
Read this from the top. A person states a need; five layers stand between that need and the enterprise systems that execute it. Each layer has exactly one job. The failures happen when a layer is asked to do a job that belongs to another.
Notice what this buys you. The system of record stays exactly where it is, doing the one thing it is good at: holding data you can trust and audit. The parental-leave question gets answered in the conversation layer, assembled by orchestration, made correct by the organizational context layer, and grounded in records the HCM already holds. No single system had to become smarter. They had to be arranged.
The rules that belong in the procurement contract
This architecture only holds if you buy for it. These are procurement rules, not aspirations. Write them into requirements and evaluation criteria before a vendor demo can charm you out of them.
- API-first, as a hard requirement. Every system you buy or keep must expose its capabilities through documented, supported APIs. If the only integration path is a nightly file export or a screen scrape, it cannot participate in the action layer. Make this a pass or fail line in the RFP, not a nice-to-have.
- Design identity and permissions for agents acting on behalf of people. Human logins were never built for a software actor operating for someone else. Treat delegated authority as a first-class design problem from day one, not a patch you add after the first incident.
- Treat knowledge content as owned and maintained. The policies, definitions, and decision rules in the organizational context layer are an asset with an owner, a review cadence, and a version history. Content that no one maintains becomes wrong content that agents repeat at scale.
- Make every agent action traceable to a decision and a person. For anything an agent does, you should be able to reconstruct what it did, which rule it applied, what data it read, and who is accountable. Traceability is not a logging afterthought; it is the design.
- Keep control of orchestration. Whoever owns the orchestration layer owns the employee experience. If you let a single application vendor own it, you have handed them the room and rented back the furniture. Keep the layer that routes across systems under your control.
Whose permission does the agent use
The second rule deserves more than one line, because this is the question that stalls real programs. It looks like a detail. It is the whole thing.
When an agent acts on an employee's behalf, whose permissions apply? There are three candidates, and each is wrong in a different way. If the agent uses the employee's permissions, it can never help with anything the employee cannot already see, which erases much of the point. If it uses the agent's own elevated permissions, it becomes a way for any employee to read data they were never entitled to. If it inherits the configurer's permissions, you have created a silent privilege escalation that no audit will catch until it is a headline.
Now the case that breaks naive designs: an employee asks a question they are fully entitled to ask, but answering it requires data the employee is not allowed to see. "Am I being paid fairly for my level?" is legitimate. Answering it well may require reading the pay band and the distribution of peers, which the employee cannot access directly. The agent needs to reason over data the person cannot see, then return only what the person is entitled to receive.
The agent holds its own identity with permissions granted for a specific task, on behalf of a named person, with the resulting answer filtered to what that person may receive. Every step is logged. Solve this before you scale, or you will solve it under a compliance review after you have scaled.
Where real HR work lives
Concrete capabilities, the layer that owns each, and who is accountable for the outcome. Notice that ownership of the mechanism and accountability for the decision are not the same column, and often not the same actor.
| Capability | Owning layer | Accountable party |
|---|---|---|
| Answer "how much PTO do I have" | Conversation | Agent |
| Approve a time-off request | Orchestration | Manager |
| Interpret a policy in context | Organizational context | Agent |
| Own the wording of a policy | Organizational context | HR policy owner |
| Calculate pay for a period | Enterprise systems | Payroll engine |
| Correct an employee record | System of record | HR operations |
| Draft a succession plan | Organizational context | Agent |
| Decide a promotion | Orchestration | Manager and leader |
| Route an offer for approval | Orchestration | Agent |
| Sign off on an offer | Orchestration | Hiring manager |
| Surface a flight-risk signal | Organizational context | Agent |
| Close a grievance | Orchestration | HR business partner |
| Provision system access on hire | Enterprise systems | Agent |
| Decide a termination | Orchestration | Leader and legal |
| Explain a benefits election | Conversation | Agent |
The pattern is consistent. Retrieval, interpretation, drafting, and routing sit above the record and can be agent-led. Consequential judgment about a person stays human, even when an agent did every step leading up to it. That is not a limitation of the technology. It is the point of the design.
No, this is not rip-and-replace
The objection forms fast in any HR technology review: we just spent years and a large budget on the HCM, and now you want to replace it. You do not. This model is the opposite of replacement. It depends on the HCM being exactly what it is.
The system of record earns its keep by being the trusted, governed, auditable source of employment and payroll data. That is hard, regulated work, and your HCM does it. The layers above do not compete with that; they stop overloading it. They sit on top and read from the record through the APIs you already require. You are not tearing out the foundation. You are stopping the practice of asking the foundation to also be the front door, the switchboard, and the policy expert.
The HCM was never the problem. Asking it to deliver the employee experience was.
Where to begin and how it fails
The architecture is a diagram until you pressure-test it against your own systems. Here is a month that produces evidence, and the two ways this work most reliably goes wrong.
- Pick one cross-system question your HCM cannot answer today, like the parental-leave case, and write down every system and document its answer touches.
- Map those systems onto the five layers on one page. Mark which are genuinely API-first and which are file exports pretending to be integrations.
- For that one question, decide whose permissions the agent should use and what the answer may reveal. Get security and legal to react to a concrete case, not a policy in the abstract.
- Name an owner for the organizational context content the question depends on, and set a review cadence for it.
- Add the five buying rules to your next vendor evaluation as pass-or-fail criteria before any renewal or new purchase.
- You collapse the layers back into one vendor. A single suite offers to do conversation, orchestration, context, and record together. It is easier to buy and it quietly hands away control of the experience layer. When you want to change one part, you cannot.
- You defer the permissions question. The demo works because it runs on test data with an admin login. Real employees, real records, and real entitlement rules expose the identity gap you skipped, usually during the security review that gates your launch.