How to tell an AI tool from a wrapper
A wrapper puts a text box in front of a model and charges you for it. Six questions that separate the two, and why the difference shows up in month three rather than week one.
Most of what arrives in our inbox is a wrapper. That is not an insult and it is not always a problem. A wrapper is a product whose entire behaviour is one prompt, sent to somebody else’s model, wearing a nice interface. Some wrappers are worth paying for. Most stop being worth it the moment the underlying model gets better at the task on its own, which is a strange thing to build a subscription on.
The trouble is that a wrapper and a real product look identical in a demo. Both take your input and produce something impressive in eight seconds. The difference is structural, and it surfaces in month three, when you have real volume, real edge cases and a real reason to care what happens when it fails.
Here is what we actually ask when something lands in the queue.
Does it hold state between runs?
A wrapper is a function. You give it input, it gives you output, and it has no memory that the last hundred runs happened. A product accumulates. It knows what you corrected last time, which of your documents are canonical, what your team decided in March.
This is the single most reliable tell, because state is expensive to build and impossible to fake in a demo. Ask what the tool knows about you on day thirty that it did not know on day one. If the honest answer is “your settings”, you are looking at a function with a subscription attached.
Who owns the failure?
Models fail. They produce confident nonsense, they time out, they refuse things they should not refuse. The question is what the product does about it.
A wrapper passes the failure straight through to you. You see the raw refusal, or the malformed JSON, or the eight-second hang followed by nothing. A product has decided in advance what should happen: it retries with a different approach, it falls back to a narrower method, it tells you plainly that it could not do the thing and why.
You can test this in ten minutes. Feed it something at the edge of its competence. Not something absurd, just hard. A messy real document instead of the clean sample. Watch what comes back when it cannot cope.
Is there a product around the prompt?
Real products have unglamorous parts. Permissions. Audit trails. Bulk operations. An export that produces something another tool can read. A way to undo. Somewhere to see what happened last Tuesday.
None of that is exciting and none of it demos well, which is exactly why its presence is informative. Nobody builds an audit log to impress you on the landing page. They build it because customers with real workflows asked for it, which means there are customers with real workflows.
What happens to your data on the way through?
A wrapper usually forwards your input to a model provider more or less as you typed it. That may be fine. It may also be completely unacceptable, depending on what you are pasting in.
The tell is whether the tool can answer the question at all. A product that has thought about this has a page explaining which provider sees what, whether inputs are retained, and whether anything is used for training. A wrapper typically has a privacy policy that mentions cookies and stops.
Does the pricing match the work?
Watch for pricing that has no relationship to what the thing costs to run. Flat unlimited pricing on top of a metered model is a bet that you will not use it much, and it usually ends one of two ways: quiet rate limits, or a pricing change with thirty days’ notice.
This is not automatically bad. It is a signal about how long the current deal will last, and it is worth knowing before you build a workflow on it.
Would it survive the model getting better?
The last question is the one that matters most and gets asked least. Imagine the underlying model improves substantially at the core task. Does this product become more valuable, or does it become unnecessary?
Products that own the surrounding workflow, the data, the integrations and the review process get better when models do. Products that exist because the raw model is awkward to use get quietly deleted. You are choosing which side of that line to put your workflow on.
What this means for a directory
We list wrappers. Some of them are genuinely useful, and a well-made wrapper that saves you an hour a week at a fair price is a perfectly good purchase.
What we will not do is describe one as something it is not. If a tool is one prompt in a nice interface, the listing says what it does and what it costs, and you get to decide whether that is worth the money. The reason the entry rule is that a person opens the tool and uses it on a real task is precisely this: you cannot tell the difference from a landing page, and neither can we.
