Why most new AI tasks need a documented procedure, not another autonomous agent.
There's a familiar pattern inside organisations rolling out AI. Someone gets one AI system working well on a task, and the moment a new, slightly different task shows up, the instinct is to stand up an autonomous agent for it: a system that plans its own steps, decides which tools to call, and works through a problem with real independence. A tool that handles customer support gets an agent sibling for refunds. A research assistant gets an agent sibling for report formatting. Within a year, what started as one useful system has become a small fleet of autonomous agents, each with its own setup, its own maintenance burden, its own way of failing, and its own hand-off problems when work needs to move between them.
Often, this is the wrong instinct, and an expensive one. Most new tasks that show up day to day aren't judgment calls that need an autonomous decision-maker. They're routine, repeatable procedures: the same steps, followed the same way, every time. That kind of work doesn't need an agent at all. It needs a documented procedure that whatever system is already running can simply follow, the same way a well-run team hands a new task to an existing employee with a checklist rather than hiring someone new for it.
Teaching versus hiring versus writing a procedure
It helps to separate three different things organisations sometimes conflate. Writing a procedure is what you do when the work is routine: the steps are known, they don't change much task to task, and following them doesn't require independent judgment. Teaching an existing system is what you do when the work needs some genuine flexibility or reasoning, but the system you already have is broadly capable enough, if only it had the right context, reference material, or reasonable access. Standing up a new agent is what you do when the work itself needs a level of autonomy, or a structural property, that no amount of instruction can supply.
Anthropic, among others, has built a mechanism for the middle case: a packaged bundle of instructions and reference material, which they call a "skill," that an existing AI system can pick up and apply when it's relevant, without needing to become a different system to do it. The system only pulls that material into its working context when the task actually calls for it, so an organisation isn't paying an ongoing cost, in compute or in complexity, for capabilities it isn't currently using. Conceptually, this is closer to a well-maintained internal playbook than to a new piece of infrastructure, and it's worth CTOs understanding the distinction precisely because the cost profile of the two options is so different: a skill is cheap to write, cheap to update, and reviewable by someone without deep technical background. A new autonomous agent means new decisions about what data and systems it can touch, new monitoring, and usually some logic for handing work back and forth with everything else already running.
Where a genuine agent, not just a skill, is the right call
None of this means autonomous agents are unnecessary. There are real, structural reasons to build one, and they're worth naming precisely because they're the exception, not the default:
- Genuinely open-ended, judgment-heavy work. If the task can't be reduced to a fixed procedure because it requires weighing options and adapting the approach step to step, that's exactly what autonomy is for.
- Genuinely parallel work. If separate streams of work need to happen at the same time rather than one after another, a single system working sequentially will be too slow by construction.
- Hard boundaries on data or access. If one part of the work must never be able to see data that another part touches, such as HR records versus general operations data, or one client's information versus another's, that's an access-control boundary that has to be built into what each system is actually permitted to reach.
- Separate accountability or audit requirements. In regulated settings, having a genuinely distinct system, with its own logs and its own failure boundary, can be a compliance requirement rather than a convenience.
The test for any new request, then, is to ask first whether it's routine (write a procedure), whether it needs more competence but not more autonomy (teach the existing system a skill), or whether it hits one of the four points above (build something new). Most requests stop at the first or second question. It is not the case that fewer agents is always better, but it's also not the case that every new task justifies a new build.
Governing skills at scale: the marketplace problem
The mechanics of writing one good skill are the easy part. The harder problem shows up once an organisation has dozens or hundreds of them, written by different teams, for different purposes, at different levels of quality. At that point, the question stops being "how do we write a skill" and becomes "how do we govern a growing library of them," and that's a genuinely organisational problem, not just a technical one.
The useful analogy is an internal app marketplace rather than a code repository. A marketplace model means every skill going into shared use has to clear some standard before it's published: what data or systems it touches, who owns it, what it's actually for, and what it explicitly should not be used for. It means someone is accountable for keeping each skill current as underlying processes change, rather than skills quietly going stale or contradicting each other because three different teams wrote overlapping versions independently. It means a review step before a skill is available organisation-wide, not just within the team that wrote it, so that quality and security expectations don't depend on which team happened to write the fastest first draft. And it means a deprecation process, because an unmaintained skill still being pulled into live work is arguably a bigger risk than no skill existing at all.
None of this is enforced by writing better instructions inside the skill itself. A skill's own text can say what it's meant to do, but it can't guarantee anyone follows the submission standard, keeps it updated, or retires it when it should be retired. That has to be a governance layer sitting above the skills themselves, owned by the organisation, not something any individual skill author can supply.
There's a related question this raises but doesn't fully answer here: once a skill is published, how does the organisation actually know it performs reliably across the range of situations it'll be used in, rather than just on the examples its author happened to test? That's a distinct problem from governance, evaluation, and it deserves its own full treatment rather than a paragraph here. It's a strong enough concept to flag now and come back to properly later.
A simple test before building something new
Before commissioning a new AI system for a new piece of work, it's worth asking, in order:
- Is this routine and repeatable, with the same steps every time? If so, this probably doesn't need an autonomous agent at all, just a documented procedure the existing system can follow.
- Does the existing system just lack the right knowledge or reference material, without the task itself demanding open-ended judgment? If so, that's a skill, not a new build.
- Does the work genuinely require independent judgment across variable, unpredictable steps? If so, that's a real case for an autonomous agent.
- Does this need to run in parallel with existing work, rather than after it? If so, that's a real case for a separate system.
- Does this involve data or systems that must be walled off from what the existing system can already touch? If so, build it separately, with that boundary designed in from the start.
- Does this need its own audit trail for compliance reasons, independent of everything else? If so, build it separately and say so.
Most new requests fail the first test and stop there. The ones that pass one of the later questions are the ones that genuinely justify the cost of something new.
What's still unproven
It's worth being honest about the limits of this argument. The case above is grounded in how the mechanism is described by the vendor building it, which is a reliable account of how it's designed to work, but not independent evidence of how much it actually saves in practice, or how it holds up against a genuine side-by-side comparison against building separate agents for the same set of tasks. That comparison hasn't been run yet, by this author or, as far as is publicly documented, by anyone else. Organisations making real infrastructure decisions on this basis should treat the underlying mechanism as real and well-described, and the size of the cost saving as a reasonable expectation rather than a proven number.
The takeaway
The organisations getting the most value out of AI at reasonable cost are the ones asking, before every new request, whether the gap is routine, knowledge, or genuine autonomy, and building only for the case that actually applies. Most of the time, especially early in an AI rollout, the answer is routine or knowledge, and the fix is cheaper, faster to change, and easier to govern than standing up a new agent would be. But the exceptions are real, and as the library of skills grows, governing it properly, and eventually evaluating it properly, matters just as much as knowing when to build an agent in the first place.