Adding AI to your business always sounds like a good idea, until it gets tested on the wrong process. We have seen enough projects come and go at AutoBoost to know the failure is almost never the model: it is having said yes too fast. That is why, before taking on an AI project, we run the exact process through five filters, in this order, and if one fails we do not move to the next until it is fixed.
This is not a list of "signs your company is ready for AI" (we already covered that here). It is the opposite question, and a more uncomfortable one: when the right call is to say not yet, even when the client wants to start today.
Why you need a filter, not a gut feeling
The reason we need an explicit process, instead of "you can just tell when it fits," is that almost everyone who calls us already believes their case is the good one. Nobody hires an AI project thinking it will fail. The filter exists exactly for that: so the decision does not depend on how much the client wants it (or how much we want to bill the project), but on five conditions you can check before writing a single line of code.
Filter 1: Is your data already unified, or does it live in five different places?
AI reasons over the data you give it. If that data is split between the ERP, three spreadsheets, and one person's head, adding AI on top does not fix anything: it just automates the confusion faster. At a group of pharmacies we work with, the data platform with an AI "controller" only started delivering once the data from several branches was unified into a single place and the AI could reason over more than a million rows (full case); before that, any answer would have been an opinion dressed up as data.
Practical rule: if today, to answer a business question, someone has to open three systems and cross-check numbers by hand, that is the project to do first. AI comes after, not in parallel.
Filter 2: Is the process repeatable, or does it change every week?
An AI agent performs well when the process has a stable shape: the same steps, the same rules, even as the input data changes each time. If the process gets reinvented every week because "this time it's different," AI has nothing to build on, and every exception becomes a special case someone has to review by hand anyway. We already covered this with the example of when it makes sense to use an AI agent versus a fixed workflow: the question is not which one is more modern, it is which one fits how stable the process really is.
Practical rule: if the process has changed more than once in the last three months without anyone documenting it, it is not mature enough for AI yet. Stabilize the process first, automate it second.
Filter 3: Can anyone explain what happens if the agent gets it wrong?
This filter gets skipped more often than you would think. Before giving write access to an agent (one that quotes, invoices, or creates an order), there has to be a clear answer to "what if this fails?": who finds out, how fast, and what gets undone. If the answer is "we don't know, we'll figure it out," the project is not ready, no matter which provider or model you choose.
Practical rule: if nobody in the company can name, today, the person who reviews what the agent does, it does not get write access yet. Start in read-only mode, and move up a level once that owner exists.
Filter 4: Do you need it to act, or just to answer?
There is a huge gap between an assistant that answers questions and an agent that writes into the real system: validating a customer, applying a price tier, checking stock, creating an order. If all you need is for someone to find information faster, a well-built internal search tool is cheaper and safer than an agent with write permissions. The AI sales agent that quotes over WhatsApp inside the ERP of a distributor with more than 50,000 products (full case) makes sense because the business needed the AI to actually act, not just summarize the catalog.
Practical rule: if, after describing the project, you are still only using verbs like "look up" or "explain," you do not need an agent with write access. If verbs like "create," "invoice," or "send" show up, you do, and that is when the access rules we already covered here come into play.
Filter 5: Can you measure whether it's right, or are you just trusting that it sounds right?
The last filter is the one most often forgotten, because an AI that answers wrong almost always sounds just as confident as one that answers right. If there is no way to check, with real data, what percentage of answers or actions are correct, there is no way to know whether the project is working or just appearing to work. This is exactly why we insist on asking what a model is really measuring when it says it's right before signing off on any rollout.
Practical rule: if the project does not include a way to verify accuracy against real data (an invoice already booked, an order already sent, a payment already reconciled), it is not finished, even if it is already in production.
Quick checklist before you say yes
| Filter | Question | If the answer is NO |
|---|---|---|
| 1. Data | Is it unified in one place, not five? | Sort the data first |
| 2. Process | Is it stable, with the same rules every time? | Stabilize the process first |
| 3. Owner | Is there someone who reviews failures? | Start in read-only mode |
| 4. Action | Do you need it to act, not just answer? | An internal search tool may be enough |
| 5. Measurement | Can you check accuracy against real data? | Add that measurement before scaling |
If all five answers are yes, go ahead: that is exactly the ground where custom AI, integrated into your real system, delivers. If one is no, it does not mean the project is bad: it means there is a prior step, and doing it first is cheaper than undoing a rollout that never should have started.
At AutoBoost we run every project through these five filters before writing a single line of code, whatever system the client uses. If you want us to apply them to yours, reach out and we will look at it together, or check how we work in our services.
