AI tools

What sits in this category

Assistants that answer from your own material, copilots that live inside another product, and platforms for wiring a model into a process that used to be done by hand. The thread running through all of them is the same: a model does part of the work, a person checks it.

Products whose whole job is drafting text belong in AI writing. Products that make pictures or footage are in AI image and video. Automation with no model in the loop sits in no-code and automation.

Four shapes, sold under one label

• Chat assistants with access to your documents, tickets or codebase.
• Embedded copilots that appear inside a help desk, an editor or a CRM you already pay for.
• Agent builders that chain steps, call tools and keep going without a human between the steps.
• Model gateways that sit between your code and several providers, handling keys, routing and spend.

The pricing pages look similar. The buying questions are not, because a copilot is judged on whether it fits a workflow and an agent builder is judged on what happens when it makes a mistake at three in the morning.

Whose model is underneath, and does it matter

Most products wrap one or more foundation models. That is not an insult. The wrapper holds retrieval, permissions and workflow, which is where the value usually lives.

It matters for one reason: the wrapper decides what happens when models change. Ask which providers are supported, whether you can switch without rebuilding your prompts, and who absorbs the cost when the underlying provider raises its rate.

Retrieval quality is the honest differentiator. Two products pointed at the same wiki return very different answers depending on how they split documents, how they rank passages and whether they admit when nothing relevant was found. A tool that never says “not in your material” is a tool that invents.

Permissions, logging and the parts nobody demos

An assistant that indexes everything with one service account has quietly removed every access control you spent years setting up.

Check that the product inherits permissions from the source system per user, not per workspace. Check that answers cite the document they came from, so a wrong answer can be traced instead of argued about. Check that prompts and outputs are logged somewhere you can read.

For anything that writes rather than reads, ask what the blast radius is. A tool with permission to update records needs an approval step, a dry run mode or both.

How the money works

Three models are common, sometimes in combination.

Per seat is predictable and wasteful when half your licences go unused. Usage pricing tracks tokens, messages or runs, which is cheap at pilot scale and alarming once adoption arrives. Platform pricing charges for the workspace and meters the heavy parts on top.

Ask for a hard spend cap rather than an alert. Alerts arrive after the money has gone. Ask, too, which tier holds the connectors you need: the integration that makes the whole thing worthwhile is frequently one plan above the one being quoted.

What to test in the trial

Give it twenty real questions your team asked last month, not the demo prompts. Count how many answers you would send to a customer without editing.

Then test the failure case deliberately. Ask something the material does not answer and see whether you get an admission or a confident invention.

Finish with the plumbing. Connect one live source, check that a restricted document stays restricted, and read the audit log to confirm the session you just ran appears in it.

Piloting without wasting a quarter

The failure pattern here is a six-month evaluation that produces an opinion rather than a decision.

Pick one process with a measurable before and after. Time spent answering a category of question, hours spent summarising documents, tickets resolved without escalation. Anything where you can state the current number.

Run it for four weeks with the people who do that work, not with a volunteer group of enthusiasts. Enthusiasts make every tool look good.

Then compare against the number you wrote down. If the improvement is real, expand deliberately and write down what made it work. If it is not, the pilot cost a month rather than a year, which is the entire point of running one.

Keep a record of what the tool got wrong. That list is what tells you where the boundary sits.