SOP, skill, agent: which carrier the work should end up in

Every delivery leaves something behind, and what shape that thing takes is usually decided by taste — sometimes by the customer's taste, which is worse. There is a cheaper way to decide. Ask who makes the judgement at that step today, and how you would find out the first time it is made wrongly. The answers sort the work into three carriers almost by themselves.

Three piles first

Before choosing a carrier, split what the delivery left into three piles: the repeatable base parts that every customer needs, the parts that are specific to this customer, and the parts that only a person can decide.

The first pile is a candidate for a shared skill. The second stays client-side documentation, and pretending otherwise is how a vendor ends up maintaining a hundred variants. The third pile is the interesting one: it looks like a process problem and is actually a boundary. Anything in it that gets automated anyway will be automated without its checks.

The ladder, and the rung you can verify

The carriers form a ladder: written procedure, template, prompt, skill or workflow, agent, product module. Start at the lowest rung that can be verified in this delivery, not the highest one that can be demonstrated.

A template can be verified in an afternoon by the person who has to use it. An agent can only be verified against an evaluation set that does not exist yet. That gap is the whole argument for starting low, and the reason most "let's build the platform first" projects spend the first month on infrastructure and the last week on the actual work.

Who judges decides the layer

The dividing question is not whether the model is capable. It is who makes the judgement at that step, and the input problem follows from it: if the judgement depends on context that cannot be delivered into an interface, it stays on the human side however good the model is — the test behind the division of labour.

Question	Stays an SOP	Becomes a skill	Becomes an agent
Who judges the next step	A person, every time	A person decides to invoke it	The agent decides; a person sees exceptions
How often it changes	Every customer, every month	Stable; changes with the customer	Stable, and the boundary is clear
What an error costs	Visible, fixed in passing	Reviewed before use	Must be caught before release, or be cheap
How often it runs	Occasionally	Repeatedly, in the same shape	Many times a week
Where the edge sits	Written guidance	Instruction, examples, a check	Wired into interfaces

Read the table column by column rather than row by row. Most work lands in one column cleanly; the work that straddles two is the work to leave alone until the next delivery has produced more evidence.

The price of promoting too early

Turning a changing process into an agent carries three costs, and all three are paid after the invoice.

The process keeps changing, so every change becomes a change request. The customer has gained a system and lost the ability to edit the thing that runs their job — an operator is now dependent on a vendor for a sentence they used to rewrite themselves.

The judgement has moved into the agent silently. On the happy path the behaviour is indistinguishable from the old one; on the exception path the checks that used to be a person pausing are simply gone. That is the failure the division-of-labour test predicts, and it shows up at the moment the exceptions appear.

Maintenance consumes the next delivery. An agent built on a process that had not settled will be rebuilt during the following engagement, at the customer's expense and with the vendor's name on it.

The counter-example is easy to picture because it is common. A customer asks on day one for an agent, for a process that changes twice during the project. It ships, it works, and it is correct about the process as it stood in week three. Users keep a spreadsheet beside it, then a group chat, then they stop opening it. Nobody complains, because nobody expected it to survive; the fourth week passes and the thing is decorative. If it had shipped as an SOP and a skill, the changes would have cost a paragraph instead of a sprint.

Two exceptions to the table

The first cuts across it. An action that is irreversible, expensive, or visible to the customer's customers does not go to the layer where the agent decides, even if it meets every other criterion. In the software company where internal delivery was reorganised around agents, the fully automatic development agent took roughly ten percent of the simple development tasks, and high-risk actions were never left to it — a share that looks modest until you count what had to stay out.

The second is frequency, which is a threshold rather than a feeling. Notice a task the second time it appears; standardise it the third time, if the shape repeated. Productising at the second occurrence produces a template built on one example, and productising at the tenth means eight repetitions of avoidable effort went by. This also gives the four-week test a second use: a skill or an agent nobody opens in its fourth week is not alive, whatever the adoption looked like at first. The four-week rule applies to carriers as much as to features.

What survives the handover

Whatever the carrier, it has to be operable by someone who is not you. That means naming who edits it, what event forces a rewrite, and what happens when the tool around it is replaced. An SOP that says who owns each line outlives a skill whose owner left, and both outlive an agent whose prompt lives in a screenshot.

Write it into the handover alongside the sunset condition, and the decision about the carrier gets made once, at the right level, rather than again every time the customer asks for something clever. Then the criterion is two questions. Who makes this judgement today? How would you find out the first time the agent gets it wrong? If the second answer is "at month-end" or "when the customer complains", the work belongs in a skill with a person at the trigger.