Specialised Tools vs General Ones

Every month a general assistant absorbs the function of a category of smaller products. Summarisers, rewriters, prompt libraries, translation tools, meeting note-takers — a great many have been reduced to a feature.

Four conditions still favour a specialised tool, and they are worth knowing because everything outside them is a cancellable subscription.

One: proprietary data the assistant does not have

A legal research product with licensed case law. A medical product with a clinical database. A financial product with filings and market data. A product with your organisation's own documents indexed properly.

The model is generic; the material is not. This is the strongest and most durable form of specialisation, and it does not erode when the underlying model improves — it improves alongside it.

Two: integration where the work happens

A tool inside your code editor, your document, your spreadsheet, your inbox, your design file.

The advantage is context and friction. It sees what you are working on without you pasting it, and it is available at the moment you need it rather than in another tab.

This is real and it is also the category most likely to be absorbed, because the platform vendor can build it natively and frequently does.

Three: a workflow with genuine engineering around the model

Document parsing that handles bad scans. Retrieval over a large corpus with proper chunking. Output validation. Structured extraction with schema enforcement. Multi-stage pipelines with checks between stages.

The model is one component in a system. You could not replicate it with a prompt, and the work is in the parts that are not the model.

Four: domain evaluation

Someone has tested outputs against expert judgement in a specific field and tuned the system accordingly — prompts, retrieval, validation, refusal behaviour.

Valuable and hard to verify from outside. Ask what the evaluation consisted of, who did it, and what the results were. Vendors doing this work will tell you. Vendors claiming it without specifics are claiming it.

Where the general assistant now wins

Writing and editing of every kind.

Summarising and rewriting.

Translation, for most purposes.

Explanation and study support.

Coding, unless you need deep repository integration.

Data analysis on files you can upload, particularly with code execution.

Research, where the assistant has search.

If a product does one of these and nothing else, test whether the assistant you already pay for covers it before subscribing.

The absorption pattern

The lifecycle is predictable. A narrow product appears solving something the assistants do badly. It works well for a year. The assistants improve. The product's advantage narrows to interface. Then it either finds proprietary data, deepens the integration, or fades.

This is why annual contracts are a bad idea in this category and why the export test matters. The product you rely on may be reduced to a feature in the tool you already have.

A test before subscribing

Try the task in your existing assistant with a serious attempt at instruction. Not one lazy prompt — twenty minutes of iteration to see how close you get.

If you get 80 percent of the value, the specialist is buying convenience. Price it accordingly and pay monthly.

If you get 30 percent, the product is doing something real. Find out what, because that tells you how durable the advantage is.

If you get nothing, it has data or engineering you cannot replicate. That is a genuine product.

The organisational version

For teams the calculation shifts, because adoption matters more than capability.

A specialised tool that colleagues actually use beats a general assistant nobody opens. Administration, access control, audit logs and a support contract have value that individual comparisons ignore.

But the same discipline applies: know whether you are buying capability or convenience, keep the term short, and test the export before you depend on it.

The questions that reveal durability

Before committing to a specialised tool, three questions predict whether it will still be worth paying for in a year.

What does it have that a model does not? Data, integration, engineering, evaluation. If the honest answer is a prompt and an interface, the advantage is temporary.

What happens when the underlying model improves? Products built on proprietary data get better alongside the model. Products whose value is compensating for model weaknesses get worse — their reason for existing shrinks with every release.

Could the platform vendor build this? Where the product is a feature inside someone else's tool, and that someone is shipping AI features, the clock is running.

A durable product answers the first question with something you cannot replicate, the second with "we improve too", and the third with a reason the platform will not bother.

Products failing all three are worth buying monthly and not worth building a workflow around.