I look at where your rules live, whether your design system is machine-readable, and which tasks would actually survive automation. Usually the blocker isn't the model. It's that nothing is written down in a form a machine can use.
You're being pitched AI tools weekly and can't tell which ones would actually work here. Someone wants to "add AI" to a process, but nobody's checked whether the underlying data, rules or design system are even in a state a model could use. You've had one AI pilot quietly die because it needed answers nobody had written down. Before the next purchase or pilot, you want an honest read on what's actually ready — and what has to be fixed first.
I start with what the system can currently see — where your rules, decisions and design tokens live, and whether they exist anywhere a model could actually read them. Most "AI readiness" problems turn out to be documentation problems wearing a technology label.
Then I map the specific tasks under consideration against that reality: what data they'd need, who'd need to check the output, and what happens on a wrong answer. Some tasks clear this easily. Most need groundwork first — and a few should be quietly dropped rather than automated badly.
You get a plain assessment, not a vendor recommendation. If the honest answer is "not yet, fix this first," that's what you get, in writing, before anyone spends a cent on tooling.
One to two weeks for a single assessment, scoped to the specific tools or processes on the table. Best done before you sign anything, not after a pilot has already stalled.
Will you tell us we're not ready?
Often. That's the useful version of this — cheaper to hear now than after a failed pilot.
Do you recommend specific AI tools?
No — this assesses readiness, not vendors. I'll tell you what needs to be true before any tool works well, not which one to buy.
What if we're already mid-pilot?
Still useful — it's common to run this after something's stalled, to find out whether the problem is the tool or the groundwork underneath it.