One instruction doc for a person and a model

The two documents nobody means to write

If you run any kind of content or ops workflow with both people and AI agents in the loop, you've probably ended up with two versions of the same instructions without deciding to. One lives in a Google Doc or a Notion page, written for a human. It has context, tone, "use your judgment here," maybe a screenshot. The other lives in a system prompt or an agent config file. It's terser, more rigid, full of bullet points and conditionals because that's what gets a model to behave consistently.

Nobody sits down and decides to maintain two SOPs for the same job. It happens because the two documents were written for different failure modes. The human doc assumes the reader has judgment and will ask when confused. The model doc assumes the reader has no judgment and needs every branch spelled out. Both assumptions are correct for their audience. The problem is that the underlying process the two documents describe is supposed to be the same process, and once you have two files, they will drift.

Where the drift actually shows up

I run a shared operator on onlinejobs.ph alongside Claude agents doing pieces of the same content pipeline. When the human SOP gets updated because a client changed a formatting requirement, and the agent's system prompt doesn't get the same edit, you don't find out until the agent ships something wrong. When the agent's prompt gets tightened because it kept making a specific mistake, and that fix never makes it into the human doc, the person doing the same task by hand keeps making the same mistake and nobody connects the two.

The drift is quiet. It doesn't throw an error. It just means the two workers assigned to the same job are quietly doing it differently, and whoever is reviewing output has to catch the divergence by eye instead of by process.

The fix isn't better sync, it's one document

The instinct is usually to build a sync process: update the human doc, then remember to update the prompt, or vice versa. That's fragile because it depends on someone remembering, every time, in both directions. A better fix is to stop treating them as two documents that need to match and instead write one instruction doc that both audiences read directly.

This works because the actual requirement of a good SOP and the actual requirement of a good system prompt overlap more than people assume. Both need:

• A clear statement of the goal, not just the steps
• The inputs required before starting
• A sequence of steps in order, not a wall of context
• Explicit handling for the common branch points, not just the happy path
• A clear instruction for what to do when something doesn't fit the expected pattern

A human reading that structure doesn't lose anything. A model reading that structure gets exactly what it needs to behave consistently. The document that's vague enough to bore a careful VA is usually also vague enough to make a model improvise in the wrong direction. The document that's precise enough to keep a model on rails is usually also precise enough that a new hire can follow it without three follow-up questions.

What actually has to change in how you write it

The main adjustment is removing the parts written for reassurance rather than instruction. Human SOPs often carry sentences that exist to make the reader feel oriented: "this step might feel repetitive, but it matters because..." That's fine for a person and mostly inert for a model, it'll just follow the instruction either way. You can usually cut it without losing anything either audience needs, which tightens the doc for both.

The bigger adjustment goes the other way: adding the explicit branch handling that a model needs and a person would normally infer. A human VA, told "check that the source is credible," will draw on a lifetime of judgment about what looks like a credible source. A model won't reliably draw the same line unless you say what "credible" means in this context: a named author, a dated publication, no anonymous forum posts. Writing that line in explicitly doesn't just help the model. It also removes ambiguity for a new team member who hasn't built up the same judgment yet. Precision helps both readers; it just happens to be non-negotiable for one of them and merely helpful for the other.

Decision points are where this pays off most. Instead of "escalate if something looks off," write the actual condition: "if the source published date is missing, or the byline is generic like 'staff writer,' flag it and don't proceed." A person can work with the vague version because they'll pause and think. A model given the vague version will often just proceed, because "off" isn't an instruction, it's a vibe. Once you write the condition explicitly, both the person and the model handle the edge case the same way, which is the whole point.

Where this approach has real limits

This doesn't mean a person and a model should be treated identically everywhere. A model executing a step will do exactly what the instruction says, including any accidental gaps you left in it. A person will often notice a gap and either ask or make a sensible call. That means a shared SOP has to be written to the model's need for completeness, not the person's tolerance for ambiguity, or the model will find the hole in your instructions that no human ever tripped.

The reverse also matters: a model can only act within the tools and access it's actually been given. If your shared doc says "check the CMS for the current draft," that instruction only works for the model if it has a way to actually reach the CMS, whether that's a direct integration or an MCP connection to the tool. For the human reader that line is trivially satisfiable, they'll just open a browser tab. Writing one doc for both audiences means being honest about which steps assume access the model doesn't have, and either giving it that access or marking the step as human-only.

There's also no shortcut around actually testing it with both readers. A doc that reads clean to you as the author can still be ambiguous in ways you won't catch until a real run exposes it. Run the same SOP past a new VA and past the model on the same task, independently, and compare where they diverge. Divergence tells you exactly where the doc is still leaving a decision to inference instead of stating it. This isn't a one-time exercise either, every time the process changes, both readers need to run the updated version before you trust it's actually shared.

What this buys you and what it doesn't

Writing one instruction doc for a person and a model doesn't reduce your task list to a system prompt and doesn't mean the model can take over the judgment calls a person makes on ambiguous cases. What it does is remove the silent drift between how two different workers execute the same job, and it forces you to write instructions precise enough that gaps show up as questions instead of as inconsistent output three steps downstream. The document gets shorter on reassurance and longer on the actual decision logic, which turns out to be better for the human reader too, not just the model.

If you're running content, ops, or research work with people and AI agents touching the same pipeline, this is one of those changes that costs you an afternoon of rewriting and pays back every time you'd otherwise have caught a mismatch after the fact.

If this kind of operator-level detail on running AI agents in real production workflows is useful, you can find more of it on the [home page](/).

Get new guides and videos first — join the Telegram channel.