How to Write an SOP for a Hybrid Human-AI Workforce
AI is embedding into People Operations processes fast. If you're using it but your SOPs haven't caught up, scaling and audit problems are close. I reworked my SOP-writing process for hybrid Human-AI work.
-
Choose a routine task, but before timing yourself, decide the allocation question first: which parts of this task should a human do, which should an AI agent do, and which require a human to review AI output. The fastest, most error-proof version of the task is no longer a single human sequence. It's a division of labor.
Time yourself doing your portion. Then map the whole flow, marking each step as human-executed, agent-executed, or human-verified. Remember the movie where the person lands the plane following instructions from the ground? Now you're writing two scripts: one for the human in the cockpit and one for the autopilot, plus the handoff points between them.
When you're done, ask yourself:
Did this allocation get the desired outcome?
Do I split the work the same way every time? If I sometimes hand a step to the agent and sometimes do it myself, is that warranted, or unexamined?
At every human-to-agent handoff, does the agent receive everything it needs? Context, constraints, format, edge cases. An agent won't ask a clarifying question you'd expect from a person. It will fill the gap with an assumption.
At every agent-to-human handoff, can the reviewer actually evaluate the output? If the human can't tell correct output from plausible-wrong output, verification is theater.
If you answered "No" to any of these, find where it breaks and fix the allocation before proceeding.
-
Write how the task gets done across both workers, missing no detail. This still includes WHO, WHERE, and WHY, but WHO now has three values: human, agent, or human-reviewing-agent.
Two documentation artifacts, not one:
The human-facing SOP. Same as a traditional SOP for the steps a person owns, plus explicit verification instructions for agent output: what "good" looks like, what failure modes to watch for, and what to do when output fails. Jargon that can't be quickly googled gets explained.
The agent specification. This is the plane-landing script for the AI. Anything you'd leave to human judgment must be made explicit: inputs, the exact desired output and format, constraints, what to do at the boundaries. Ambiguity that a human colleague would resolve with common sense becomes an error source with an agent. If your SOP is part of a bigger picture, focus on the part you own, and define the handoff interface precisely.
Explicitly describe the desired outcome. For the agent, this isn't optional prose. It's the specification the output gets checked against.
One reframe that breaks the old model: in a human-only SOP, a bad result triggers feedback that improves the executor. With an agent, miscalibrated output doesn't train the agent. It points back at your specification. When the agent produces the wrong thing, the default assumption is that the spec was underspecified, not that the worker underperformed. Verification failures are spec-diagnosis events.
-
This step now runs twice, against two different subjects.
Test the agent specification. Run the task through the agent using only your written spec. Add nothing verbally. Every time the output is wrong, incomplete, or plausible-but-off, don't correct the agent in the moment. Trace the failure back to the missing or ambiguous line in the spec and fix that. The agent is a perfect test subject for specification gaps: it has zero background knowledge and will never quietly compensate for a hole in your instructions.
Test the human SOP with someone who has never done the task. Ask them to execute their steps and to verify the agent's output using only your description. When they stumble, ask a question, or wrongly accept bad agent output, take a note and fix the document. When they ask a question, don't answer it. Work out what was unclear. That tells you what to rewrite.
The specific new failure to hunt for: the reviewer waving through wrong agent output because your SOP told them what to check but not how to tell right from wrong. If that happens, your verification instructions are the defect.
Go back to the board. Do it, document it, delegate it, on both tracks, until the agent performs from the spec alone and a fresh human can both do their part and reliably catch agent errors.
-
Human SOPs assume the executor remembers what they did, and that memory plus their manager's oversight is enough of a record. Neither assumption holds for agents. Agent memory drifts, resets between sessions, and gets silently compacted. An agent cannot be trusted to be its own witness. If the only record of what the agent did lives in the agent's context, you have no record.
So the SOP has to specify a run log as a required output of the task, not an optional add-on. Every agent-executed run writes down:
What it was asked — the actual prompt or spec version handed to the agent, not a description of it.
What it did — the steps taken, tools or systems touched, data read and written.
What it produced — the output, and which inputs produced it.
What a human decided — every point where a person approved, overrode, or corrected agent output, and the reasoning.
When, and which version — timestamp, and the spec/model version in effect, since both change under you.
Two reasons this is non-negotiable in HR specifically. First, audit and compliance: benefits, pay, leave, and hiring decisions carry legal and regulatory exposure, and "the agent did it" is not a defensible answer. You need to reconstruct who or what made a given decision and on what basis, months later. Second, spec diagnosis: the run log is the raw material for the verification-feedback loop in step 2. When output drifts, the log is how you find whether the spec, the model, or an input changed.
Design point for the writer: the log should be generated by the workflow, not by a human remembering to fill it in. A human-maintained log of agent activity will be incomplete within a week. Make logging a step the agent (or the surrounding system) performs automatically, and treat a run that didn't log as a failed run.
One more, easy to miss: log the human side too. The record of who reviewed what and when is the part auditors will actually want, and it's the part most likely to be missing because humans assume their own actions don't need recording.