Business process frameworks were built for humans, not agents

How HCM workflows actually work

If you have ever configured a business process in Workday or SAP SuccessFactors, you know the model. You define a sequence of steps. Each step has an actor – usually a human. The actor completes their step (fills out a form, approves a request, uploads a document), and the process moves to the next step. It is linear, sequential, and human-initiated at every stage.

Workday calls these Business Process Frameworks (BPFs). SAP calls them workflows. Oracle has its own variant. The specific names differ, but the underlying model is the same: a chain of human actions connected by system routing.

This model works well for the use cases it was designed for. Processing a new hire? Define the steps: manager submits requisition, recruiter posts job, candidates apply, hiring manager interviews, offer is extended, HR processes onboarding. Each step has a clear owner and a clear action. The system routes work from one person to the next.

Where the model breaks down

The problem is not that BPFs are bad. The problem is that they embed three assumptions that agents violate:

Assumption 1: Processes are linear. BPFs execute step by step. Step 2 waits for Step 1. Step 3 waits for Step 2. But real workforce decisions are rarely linear. When Fatima in talent acquisition identifies a critical role to fill, the optimal process runs multiple tracks in parallel – sourcing internal candidates, posting externally, checking the redeployment pool, and evaluating contractor options – all simultaneously. A BPF forces these into a sequence.

Assumption 2: Humans initiate every step. Every step in a BPF assumes a human actor. Someone clicks, someone approves, someone submits. This means nothing happens until a person acts. An agent-driven process does not wait. It detects a signal (an employee's engagement scores dropping), evaluates the situation (cross-referencing compensation, tenure, performance, and market data), and initiates a response – all without waiting for a human to notice the problem and start a workflow.

Assumption 3: Processes live in one system. BPFs orchestrate actions within Workday. SAP workflows orchestrate actions within SuccessFactors. But workforce processes increasingly span systems. Onboarding a new hire might touch the HCM, the learning platform, the IT ticketing system, the badge access system, and the team communication channel. A BPF cannot reach beyond its own walls.

Linear vs. event-triggered: a comparison

Characteristic	BPF / HCM workflow	Agent playbook
Trigger	Human clicks “start”	Event or signal detected
Execution	Sequential, one step at a time	Parallel branches, conditional paths
Actor	Human at every step	Agent acts, human approves when needed
Scope	Single system	Cross-system orchestration
Adaptation	Fixed path, defined at design time	Dynamic, adjusts based on context
Speed	Days to weeks (waiting for humans)	Minutes to hours (agent acts between approvals)
Reusability	Monolithic, hard to recombine	Composable, mix-and-match steps

The playbook model

Agent-native processes need a different model. In practice, this is emerging as the “playbook” – a process definition designed for agents rather than humans.

A playbook differs from a BPF in four fundamental ways:

Event-triggered. Playbooks start when a condition is met, not when a human clicks a button. “When a high-performer's engagement score drops below threshold for two consecutive periods” is a playbook trigger. The agent is always listening for the signal.

Parallel execution. Playbooks can run multiple branches simultaneously. When the retention playbook triggers, it can simultaneously pull compensation benchmarks, check internal mobility options, review the employee's development history, and draft a manager briefing. These are independent tasks that do not need to wait for each other.

Composable. Playbook steps are modular. The “assemble compensation benchmark” step can be reused across retention playbooks, promotion playbooks, and annual review playbooks. BPFs tend to be monolithic – each process is designed end-to-end with limited reuse of components.

Context-aware branching. Playbooks adapt based on what the agent learns as it executes. If the compensation benchmark shows the employee is already above market, the retention playbook shifts its focus to development opportunities or role changes rather than a pay adjustment. BPFs follow the same path regardless of what is discovered along the way.

A concrete example: internal mobility

Consider how an internal mobility process works in each model.

BPF approach: Diego, a product manager, opens the HCM portal. He searches for open roles. He finds one that looks interesting. He clicks “apply.” His manager receives an approval request. The manager approves. The receiving manager reviews. HR reviews. Weeks pass between each step because each one waits for a human. Diego may lose interest – or accept an external offer – before the process completes.

Playbook approach: The agent detects that Diego's skills and career interests align with a newly posted role. It evaluates fit across skills, experience, team dynamics, and development trajectory. It simultaneously notifies Diego (“a role matching your interests just opened”), briefs the hiring manager (“here is a strong internal candidate”), and prepares a transition impact analysis for Diego's current manager. Diego responds in Teams. The agent handles scheduling, document assembly, and routing. Elapsed time: days, not weeks.

The outcome is the same – Diego moves into a new role. But the process model is fundamentally different. One is built for humans clicking through steps. The other is built for agents orchestrating across systems and people.

Why you cannot patch BPFs into playbooks

A natural question is whether HCM vendors can simply upgrade their workflow engines to support these patterns. The short answer is: not without rebuilding the foundation.

BPFs are deeply embedded in HCM architecture. They are tied to the system's data model, its security framework, its approval chain logic, and its audit infrastructure. Adding parallel execution, cross-system orchestration, and event-triggered initiation would require rearchitecting the workflow engine from the ground up – while maintaining backward compatibility with every existing BPF that customers have configured over the past decade.

This is not impossible, but it is the kind of foundational change that takes years, not quarters. In the meantime, the playbook model needs to exist as a complementary layer that coordinates with BPFs rather than replacing them. The playbook triggers the BPF when it needs to create a transaction in the system of record. The BPF handles the transaction. The playbook handles everything around it – the context assembly, the cross-system coordination, the proactive delivery.

Coexistence, not replacement

BPFs are not going away. They remain the right model for straightforward, compliance-driven transactions – processing payroll, managing benefits enrollment, handling leave requests. These are structured, predictable, and well-served by sequential workflows.

But the higher-value workforce processes – retention, internal mobility, workforce planning, succession management – require the playbook model. They are complex, multi-system, and benefit from proactive, parallel, context-aware execution.

The practical architecture is a layer cake: BPFs handle the transactional floor, playbooks handle the strategic ceiling, and they connect through the system of record that both read from and write to. Understanding this distinction matters because it explains why organizations that wait for their HCM vendor to deliver agentic workflows will be waiting a long time. The process model itself needs to change – and that change comes from a complementary layer, not from inside the BPF.