I recently needed to understand a long, cross-departmental process. It was documented across a huge slide deck, a few forms, and half a dozen fields scattered across internal systems. No single source of truth.
In my experience, the right tool for this is a checklist. Not a dashboard, not an assistant. Just a simple list of boxes to check in the right order.
So I used Claude to read through the materials and produce a tight summary of the process and its steps. I reviewed it, then asked Claude to turn that summary into a checklist draft. I refined it. I’m using it now, and I’ll keep refining it as I go.
Around the same time, I learned that another team in the organization was building this same process into an AI skill, a packaged capability an agent can call on demand. It’ll probably be useful. It’ll help with several of the steps.
But it’s the wrong tool for what I actually needed. I don’t want to consult an AI agent to find out what’s next on my list, or how far I am from done. A glance at a checklist is faster than a prompt. And it costs nothing.
The sledgehammer problem
You don’t reach for a five-kilogram sledgehammer to hang a picture frame. Both tools can drive something into the wall. Only one of them will also put a hole through it.
The same logic applies to AI, and I already wrote about the general version of this: a fool with a tool is still a fool. The tool doesn’t decide the outcome. The judgment behind picking it does.
With AI, that judgment now has to answer a longer list of questions than it used to.
Does this need a skill, or a checklist? Does it need the heaviest model available, or the smallest one that can do the job? Should this run as an automated, deployed agent, or stay chat-based, something a person triggers on purpose? What information does it actually need access to, and which tools should it be allowed to touch? And underneath all of that: should AI be doing this at all, or doing this particular part of it?
None of these are technical questions. They’re judgment calls. Skipping them doesn’t make the process faster. It just moves the cost from before you build to after you’ve built the wrong thing.
A quick test before you build anything
Before formalizing a process into a skill or an agent, run it through this:
| If what you need is… | The right tool is usually… |
|---|---|
| A fixed sequence of steps someone follows manually | A checklist |
| An answer people ask repeatedly | A FAQ page or wiki entry |
| A status people want to glance at | A dashboard |
| A judgment call that changes with context | A chat-based assistant, on demand |
| A repeatable action across many cases, unattended | An agent or skill |
Most process documentation problems live in the top three rows. Most of what gets built lives in the bottom two.
That gap is the actual failure mode. Building an agent has gotten cheap enough that it no longer forces the question a bigger investment used to force automatically: what problem is this solving, and what’s the smallest thing that solves it? The tool got cheap. The thinking didn’t get cheaper with it.
The part that doesn’t automate
Here’s what doesn’t change, whether you use AI or not: someone still has to look at the output and decide if it’s good enough to stand behind.
A checklist built by AI is only as good as your review of it. A skill deployed by another team is only as good as someone checking that it does what it claims, on the cases that matter, not just the demo. The tool can produce the artifact. It cannot decide, for you, whether the artifact is right.
You can automate the drafting. You can’t automate standing behind it.
A fool with a tool is still a fool. A fool with the wrong tool, chosen because it was the newest one available, just gets there faster.
Before you build anything, ask what you actually need. Then ask if what you’re about to build is that, or just the thing that was easiest to reach for.