The guide · The classroom
The lessons.
What the words mean and how the thing works, in plain English, before you buy any of it. Read what you need, then book the call.
What a language model is
Every AI product you will be shown sits on top of the same idea, and it is a simpler idea than the pricing suggests. Understanding it takes ten minutes and changes every vendor conversation you have after.
The whole trick
A language model reads everything before the cursor and guesses what comes next. Then it does it again. That is the entire mechanism. It learned those guesses by reading an enormous amount of text, so its guesses carry the shape of how people write about contracts, code, complaints and purchase orders. Nothing is looked up. Nothing is reasoned through the way a person reasons. It is a very good guess, made very fast, over and over.
Why that works better than it should
Guessing the next word well turns out to require a lot of structure underneath. To finish the sentence "the invoice was rejected because the purchase order" you need to know something about how purchasing works. So the model picked up patterns about the world as a side effect of getting good at the guess. That is why it can draft a decent reply to a supplier. It is also why it has no idea whether the thing it just wrote is true.
It sounds certain either way
The model has no signal that says "I am on firm ground here." A confident sentence about your return policy and a confident sentence about a return policy it invented are produced by exactly the same process and read exactly the same. People hear fluency as competence. That mismatch is the single biggest source of trouble in business use, and no amount of prompting removes it. You design around it instead.
What that means for your work
It is strong where a knowledgeable person would be nearly right on the first pass and the cost of being wrong is a quick correction: drafting, summarising, rewriting, sorting, pulling fields out of messy text. It is weak where the answer has to be exactly right and nobody will check: prices, quantities, dates, legal language, anything that leaves the building unread. The skill is not prompting. It is knowing which of those two piles a job sits in.
What to do with this
Take one task you were told AI would fix. Ask whether a smart new hire would get it roughly right with the context you could hand them in a page. If yes, it is a candidate. If the job needs a lookup in a system, the model alone is the wrong tool and the vendor is selling you the wrapper around the lookup. That distinction is worth more than any demo.
What a language model is
Why it guesses the next word
Your phone finishes your sentences. The tools you are being sold do the same thing with far more reading behind them. Knowing that one fact takes the mystery out of most of what follows.
One word at a time
The model does not plan a paragraph and then write it. It produces one word, adds it to what came before, and produces the next. Every word is chosen because it is a likely continuation of everything on the page so far, including the words it just wrote. That is why the tone of an answer settles early and stays: once it has started formal, formal is the likeliest next word every time.
Likely is not the same as true
A likely next word in a sentence about your return policy is whatever usually follows in sentences like that, drawn from everything it read. If your policy is unusual, the likely word is wrong for you and the model has no way to know. This is the root of the confident mistake: nothing in the mechanism checks the world, only the pattern.
Why more reading made it better
To guess the next word well across contracts, recipes, code and complaints, the model had to absorb how those things are put together. So a good guesser turned out to know a great deal, as a side effect. That is the whole story of why these tools got useful in the space of a few years. Nothing else changed in the trick, only the scale of the reading and the size of the guesser.
What this means when you buy
Anything sold as writing, summarising, rewriting, sorting or drafting is this mechanism with a good prompt in front of it. Anything sold as knowing your prices, your stock or your calendar has to be looking those up somewhere, and the lookup is the part worth asking about. The guess is the same in every product; the difference you pay for is what gets put in front of it.
What a language model is
Why it sounds so sure
The tone never changes. A right answer and a made-up one arrive in the same calm, complete sentences, and that is the property that catches people out. It is not a flaw a vendor can switch off; it is the mechanism.
There is no dial for doubt
A person who is unsure hedges, slows down, checks. The model has nothing that plays that role. It chooses the likeliest next word whether the ground is firm or not, and the likeliest next words in most written English are confident ones. So the answer about a regulation it half remembers is written in the same voice as the one it knows cold. The voice tells you nothing.
Why we hear competence
People judge expertise by fluency, because in a human that is a fair signal: someone who explains a thing smoothly usually understands it. The model is fluent by construction, so the signal is broken and our instinct is not. The mistake that costs money is almost never the obviously garbled answer. It is the polished one nobody thought to check.
Asking it to be unsure helps, a little
You can tell it to say when it is not certain, and to point at where an answer came from. Both help, and neither is reliable: it can produce an uncertain tone as easily as a certain one, and it can invent a source. The useful version is to give it the real source and ask it to quote from that. Then the check is a lookup, not a judgement.
Habits that work
Treat anything with a number, a date, a name or a promise in it as unverified until someone looks. Prefer tools that show the document they drew from. Put the human check where the answer leaves the building, not where it is produced. And teach the team the one sentence that matters here: it always sounds like this.
What a language model is
What it cannot know
The model read a great deal and stopped on a date. It has never seen your price list, your stock, your customers or this morning. Everything you want it to know about you has to be handed to it every time, by you or by the tool around it.
Three things it has no access to
The present: its reading stopped at some point in the past, and it does not know what happened after. Your business: nothing about your company was in that reading unless you are famous. The file you did not give it: it cannot open your shared drive, your inbox or your accounts system unless something is built to fetch from them. Ask it about any of these bare and you get a plausible guess in a confident voice.
How the tools get around it
A well built product fetches the relevant piece and puts it in front of the model before asking the question: the customer's last three orders, today's date, the paragraph of the manual that applies. The model then works from what it was shown. This is the single most important thing to understand about a product demo. Ask what was fetched, from where, and what happens when the fetch finds nothing.
Stale is a kind of wrong
If a tool was given your price list once, in January, it knows January's prices. Nothing warns it, or you, that the list has moved on. Anything that changes needs a live lookup, not a copy, and the question to ask is where the copy lives and how it is refreshed. A confident quote from last year's prices is the most expensive answer a tool can give.
The test to run
Ask the tool something only your business would know, and something that changed last week. Watch whether it looks it up, says it cannot, or guesses. Only the first two are acceptable. The third is the tool telling you, politely, that it will do the same thing to a customer.
What a language model is
Reasoning models, plainly
Some models now write out their working before they give an answer, the way a careful person does a calculation on paper. It makes them better at some jobs, no better at others, and slower and dearer at all of them.
What is actually happening
The model produces a run of text for itself, working the problem through, before producing the answer you see. It is still guessing the next word; it is just guessing its way through the steps first. Because each step is on the page for the next step to read, it makes fewer of the mistakes that come from jumping straight to a conclusion. Multi-step arithmetic, a plan with dependencies, a tricky bit of logic: these improve noticeably.
Where it changes nothing
Drafting an email, summarising a call, sorting messages into buckets, rewriting a paragraph in plain English. None of these has steps to work through, so the extra thinking adds time and cost and no quality. A lot of small business work is in this pile. Paying for a reasoning model to write a thank-you note is paying for a courier to walk next door.
The bill and the wait
The working is words, and words are what you pay for. A reasoning answer can cost several times a plain one and take ten or thirty seconds instead of two. That is fine for a quote checked once a day and wrong for a chat window a customer is staring at. Match the model to the job, and ask a vendor which model sits behind which feature.
The working is not proof
A written chain of steps looks like evidence and reads like it, and it can be wrong at step two with steps three to nine following neatly from the error. Treat it as you would a colleague's rough working: useful to check against, not a reason to skip the check.
What an agent is
Agent is this year's word, and behind it is one real change: the model stopped only writing and started doing. That is a genuine step up in usefulness and an equally genuine step up in what can go wrong.
What is actually different
A plain model takes text and gives back text. An agent is that same model wired to tools: read the inbox, query the database, create the ticket, send the email. It works in a loop. It decides which tool to use, sees the result, decides again, and stops when it thinks it is done. Nothing mystical happened. It is the same next-word guess, now choosing between actions instead of only words.
Where the value is
The value is in work with many small steps and no judgment worth protecting: pulling the attachment, reading the numbers, putting them in the right field, flagging the three that do not match. A person doing that is expensive and bored, and bored is when errors arrive. An agent doing it is cheap and tireless. It is not more intelligent than the chat window, it is just allowed to finish the job instead of handing you a draft.
Where the risk moves
A wrong paragraph costs you the time to read it. A wrong action costs you whatever the action did. The loop is the problem: a small misreading in step two is still there in step nine, and by then it has done nine things. Give an agent broad access and one bad afternoon touches a lot of records. This is not a reason to avoid agents. It is the reason the boring questions matter more than the demo.
What to demand before it touches anything
Narrow access, not convenient access: exactly the systems and exactly the permissions the job needs. A full log of every action, readable by a person who is not an engineer. A hard stop where a human signs off on anything that sends money, leaves the company or is hard to undo. And an off switch that someone in the office can reach without calling the vendor.
Reading a vendor's agent claim
Ask what it does when it does not know. A serious answer is that it stops and asks. A vague answer means it guesses and proceeds. Ask to see the log from a real run, not a slide. Ask what happens if your system is slow or returns something unexpected halfway through. The products that have been used in anger have crisp answers, because their customers have already asked.
What an agent is
What an agent can touch
The model on its own can only write. An agent is that model with hands: it can look things up, send things, book things, change things. The list of what it can touch is the whole risk and the whole value, and it is usually on page nine of the proposal.
Read, then write
Tools come in two kinds. Reading tools let the agent look: the calendar, the customer record, the stock level, a web page. Writing tools let it act: send the email, book the slot, raise the invoice, change the address. A reading tool can embarrass you. A writing tool can cost you. Any agent worth having starts with reading tools only and earns each writing tool one at a time.
The login is the thing
An agent acts through an account, and it can do whatever that account can do. If it books appointments through the owner's login, it can also see the owner's inbox. The right shape is an account of its own, with exactly the permissions the job needs and nothing more, so the question when something goes wrong is never whether it was the agent or the person.
Reading the vendor's list
Ask for the list of every tool the agent has, with read or write beside each. Ask which it uses without asking and which it asks first. Ask what it does when a tool fails: the calendar was down, the customer record was blank. A vendor who cannot produce this list has not built the thing carefully, whatever the demo looked like.
Start smaller than you want to
The agent that reads the inbox and drafts replies for a person to send is dull and safe, and it teaches you how the thing behaves on your real messages. Give it the send button after a month of reading its drafts, not before. Nobody has ever regretted the slow version.
What an agent is
Where an agent stops and asks
A good agent is not one that never stops. It is one that stops at exactly the right moments and knows who to hand to. Those moments are a list, and you should write it before the vendor does.
The three that are always on the list
Money: anything that spends, refunds, discounts or quotes a number a customer will hold you to. Promises: a delivery date, a fix by Friday, an assurance about what the product does. The irreversible: sending, deleting, cancelling, submitting. At each of these the agent should stop, show a person what it is about to do, and wait. Everything else can usually run.
What a good hand-back looks like
It arrives with the context: who the customer is, what they asked, what the agent proposes, why it stopped. A person can approve in one tap or change one thing. A bad hand-back is a bare notification that forces someone to go and reconstruct the situation, which is slower than having done the job by hand. The hand-back is a piece of design, and it is where most agent products are lazy.
The hand-back that never gets answered
If the person it hands to is in a van until six, the customer waits until six. Decide who catches the hand-backs, what the answer time is, and what the agent tells the customer meanwhile. An honest holding message with a real time beats silence, and the agent can send it without anyone's approval because it promises nothing.
Loosen it later, on evidence
After a month you will have a pile of hand-backs that were approved without a change. Those are candidates for letting the agent run. Loosen one at a time, keep the log, and tighten again the first time something surprising goes out. Confidence in an agent is built the same way as in a person: on what it did last month.
What an agent is
Agents that run on a schedule
The most useful agents in a small business are often the boring ones: they run at a set time, do one repeatable job, and leave something in a place a person will look. No chat window, no conversation, just a task that no longer needs remembering.
What suits a clock
The morning summary of yesterday's messages, orders and reviews. The list of invoices past thirty days, with a drafted reminder for each. The stock report against tomorrow's bookings. The weekly note of what customers complained about. All the same shape: gather, sort, draft, leave it somewhere. None of it needs to happen at the moment a customer is waiting, so speed does not matter and a cheap model does.
What does not
Anything a customer is waiting on belongs to a live tool, not a schedule. Anything that needs a judgement each time is a person's job with a draft in front of them. And anything that sends without a look is off the list until it has run for weeks landing in a folder instead.
Keeping it honest
A scheduled job fails quietly: the login expired, the source moved, the format changed, and the summary just stops arriving, or worse, keeps arriving half empty. Have it write a one-line receipt each run, including the count of what it processed, and have someone notice when the count is zero. Once a month, spot-check one output against the raw source by hand.
The value is in the habit it replaces
The point is not that the summary is clever. It is that a person used to spend forty minutes at eight in the morning producing something worse. Count the minutes, multiply by the days, and compare it with the subscription. Scheduled agents are where that arithmetic most often comes out clearly in your favour.
What an agent is
When you don't need an agent
If every message with the word invoice in it should go to Sam, that is a filter, not an agent. A surprising amount of what gets sold as autonomous work is a rule wearing a costume, and the rule costs nothing and never surprises you.
The index card test
Write the job down as steps. If every step is an if-this-then-that with no judgement in it, you want a rule, a filter or a workflow in the tools you already have. Agents earn their keep when a step needs reading and deciding: is this complaint urgent, which of these three products did the customer mean, what should the reply say. If none of the steps look like that, the agent is overkill.
The feature you already pay for
Most business software has automation built in: auto-replies, routing rules, reminders, templates, scheduled reports. Most of it is switched off because nobody had an afternoon. Before buying an agent to do a thing, ask whether the system that holds the thing can already do it. Often the honest answer is yes, and the hour it takes to set up is the cheapest automation you will ever buy.
Where the agent genuinely wins
Messy input. A voicemail transcript, a photo of a form, a customer email that rambles, a supplier document in a format you have never seen. Rules break on mess; a model reads it. If the job starts with something a rule could not parse, an agent is the right tool. If it starts with a tidy field in a tidy system, it usually is not.
The cost of the costume
An agent doing a rule's job is slower, dearer and occasionally wrong, where the rule would have been instant, free and always right. It also needs watching. Reserve the watching for the jobs that need it.
“Trained on your data”
You will hear it in every demo. It almost never means what it sounds like, and the difference matters for your cost, your exit and your data.
What it usually means
In most products, trained on your data means the tool searches your documents, finds the handful of passages that look relevant to the question, and pastes them in front of the model along with your question. The model then answers using that text. The model itself was never changed. Your data was fetched, used for one answer, and let go. This is the normal design, and it is a good one.
Why that is the right default
Because your information changes. Fix a price list at nine in the morning and the tool is right at nine oh one, because it reads the list fresh each time. A model that had genuinely absorbed your old prices would need redoing. Searching beats absorbing for anything that has a current version, which in a business is nearly everything.
When something really is trained
Actual training, usually called fine-tuning, adjusts the model itself on examples you supply. It is worth doing for style and format, teaching it to write the way your team writes, or to always return the same structure. It is a poor way to teach facts, because the facts get baked in and go stale, and it needs hundreds of clean examples. If a vendor claims fine-tuning for a knowledge problem, they are either loose with words or have chosen the harder road for no gain.
The question that separates them
Ask: if we correct a document this afternoon, when does the tool give the corrected answer? Immediately means it is searching, which is what you want. Next month, or after a retraining run, means something is baked in. Both are legitimate products. Only one of them keeps up with your business without a project attached.
What to pin down in writing
Whether your content is ever used to improve the vendor's model for other customers, and how to say no. Where your documents are stored and for how long. Whether anyone at the vendor can read them. And what you can take with you if you leave: your documents were always yours, but the work of organising them for search may not be, and that is the part people discover late.
“Trained on your data”
Training, tuning and reading
Training makes the model. Tuning nudges it. Reading is handing it a page at the moment of the question. Vendors say trained for all three because it sounds like the most, and it is almost never the one they mean.
Training
Building the model from scratch by having it read an enormous amount of text over weeks on expensive machines. Only a handful of companies in the world do this, and none of them did it on your documents. When a vendor says their product was trained on your data, this is not what happened. It cannot be; it would cost more than your building.
Tuning
Taking a finished model and adjusting it a little with a few thousand examples so it writes in a particular voice or format. It is real, it is affordable, and it changes how the model sounds more than what it knows. It is also a copy of those examples baked into a model, which is worth knowing if the examples were customer emails. Ask whether the tuned model is yours alone.
Reading
Fetching the right paragraph from your documents at the moment of the question and putting it in front of the model. This is what nearly every product means by trained on your data, and it is the good option: your documents stay where they are, an update is read the next time, and a deletion is honoured. The whole quality of it rests on the fetch finding the right paragraph.
The question to ask
Say: when I change a document, when does the tool know? If the answer is the next time someone asks, it is reading. If the answer involves a retraining run, it is tuning. If the answer is a pause, the vendor is not sure, and neither should you be.
“Trained on your data”
What “learning from you” means
A product that remembers you like short replies, that your busiest day is Tuesday, that you spell the company name a certain way, has written those things down and reads them back before each answer. Useful, ordinary, and worth understanding as what it is.
The notebook
Somewhere in the product is a list of facts about you, added as you go: corrections you made, preferences you stated, things it inferred. Each time you ask something, the relevant notes are placed in front of the model along with your question. The model has not changed at all. The notebook has grown. That is what learning means in every consumer and small business tool you will meet.
What it cannot do
It cannot get better at the underlying work by watching you. It will not become a sharper writer or a more accurate summariser because you used it for a year. If a task was beyond it in January, the notebook will not fix that by June. Improvement at the task comes from the vendor shipping a newer model, which has nothing to do with you.
What is in the notebook
Whatever the tool decided to keep, which can include things you would not have chosen: a customer's name and situation from a message you pasted, a detail about a supplier, a price. Look for the page that shows the memories and read it. A good product lets you see every note, edit it and delete it. A product that has learning but no such page is keeping a file on you that you cannot read.
Team or personal
If the notes are per person, the tool knows what Sam likes and nothing about the business. If they are shared, one person's correction helps everyone, and one person's pasted customer email is now in everyone's context. Decide which you want before the notebook fills up, because emptying it later is a chore nobody does.
“Trained on your data”
Will it leak to someone else
The fear people voice is that a competitor will ask the model a question and get your price list back. That is not how it leaks. The ways it does leak are duller and more likely, and every one of them is something you can check.
The fear, and why it is the wrong one
On a business plan that says your data is not used for training, your file does not become part of the model, and even on plans that do use it, the process does not store your document in a form that can be handed back whole. The exact-page leak to a stranger is close to a myth. Worry about the four things below instead.
Logs and the people who can read them
Your conversations are stored by the vendor, for some period, and some staff can see them under some rule. Ask how long, who, and why. The honest answers sound like thirty days, a named team, and to investigate abuse. A vague answer is a real exposure, because the leak path is a person, not a model.
The free tier and the personal account
The consumer version of a tool, on someone's personal login, is usually the version that does use conversations to improve the product, and the version with no business terms at all. The most common leak in a small firm is a well-meaning employee pasting a customer's contract into the free app on their phone. Give people a business account and a one-line rule, and that path closes.
Your own permissions
A tool that reads your shared drive reads everything the connected account can read, including the folder nobody meant to share. Before connecting, look at what the account can see. The answer the tool gives to a junior member of staff can include the contents of a document they were never supposed to open, fetched helpfully because it was relevant.
Where it gets it wrong
The failure everyone has heard of is invention, and the useful thing to understand is that it is not a bug anyone is about to fix. It falls out of how the thing works, so you plan around it the way you plan around any tool's limits.
Why it invents
The model is always producing a plausible continuation. When it knows, plausible and true line up. When it does not know, plausible is still available, so out it comes: a reasonable-looking part number, a case that was never decided, a clause that belongs in someone else's contract. It is not lying, which implies knowing better. It has no separate sense of knowing at all.
The dangerous kind is the small kind
Wildly wrong answers get caught. The expensive ones are almost right: one digit off in a quantity, last year's rate, the correct policy from the wrong region, a summary that keeps every sentence but drops the condition. Those slide through review because everything around them reads correctly, and a tired reviewer is scanning, not auditing.
Why more review is not the answer
Ask a person to check output that is right nine times in ten and they stop checking by the end of the first week. This is well understood in quality work and it is no different here. A process whose only safeguard is human attention on good-looking text is a process that will let the tenth one through. If you need catching, catch it with something that does not get bored.
What actually helps
Make it show its source, so checking is a glance at the quoted passage rather than an act of faith. Have it fill a form rather than write prose, because a missing field is visible and a missing caveat is not. Check the things that can be checked mechanically: does that part number exist, is that date in range, does that total add up. And put the human gate where the money and the outside world are, not on everything.
The one rule worth keeping
Never let it be the only thing between a number and a customer. Drafting a quote is fine. Sending a quote unread is not. That line holds regardless of which product you buy and how good the next model gets, and it is the line most of the public failures crossed.
Where it gets it wrong
Made-up facts, and where they come from
An invented fact is not a glitch. It is the mechanism doing exactly what it does, in a place where the right answer was not on the page. Once you know the places, you can see them coming.
A gap gets a plausible filling
Ask for the part number of a fitting the model has never seen, and the likeliest next words are a part number shaped like the ones it has seen. Ask for a case that supports your position and you get a case that sounds right. It is not lying, because it does not know the difference. It is completing the pattern, and the pattern of a confident answer includes specifics.
The situations that produce them
Specifics it was not given: numbers, names, references, quotes, dates. Questions phrased as though the answer exists: what is the warranty on this, rather than is there a warranty. Long conversations where the early facts have drifted off the desk. And anything obscure, where the reading it did was thin and the pattern is all it has.
Give it the source and ask for the quote
The single most effective change: put the real document in front of it and ask it to answer only from that, quoting the line. When the answer is a quote from a page you can open, a made-up fact has nowhere to hide. Products that show the source paragraph beside the answer are built on this idea, and it is the feature to insist on for anything factual.
Where the check belongs
Not on every sentence; on every specific. A person can read a drafted reply in ten seconds if they know to look at the numbers, the names and the promises and skim the rest. Teach that and the check becomes cheap. Try to check everything and it stops happening.
Where it gets it wrong
Wrong with numbers
A model is a reader, not a calculator. It has seen a great many sums written out and can reproduce the look of one. Whether the total is right is a separate question, and it is the one your customer cares about.
Why arithmetic is hard for a word guesser
Adding a column of figures is not a pattern in text; it is a procedure. The model has to arrive at the right digits by guessing likely ones, which works for sums it has seen often and fails quietly for the ones it has not. It also miscounts: items in a list, words in a paragraph, days between two dates. Anything where the answer is a count or a sum is a place to expect an error.
What the good tools do
They hand the number to something that can do numbers. A well built product lets the model write the sum and a calculator or a spreadsheet run it, then puts the result back in front of the model. The same goes for dates, currency and unit conversions. Ask a vendor directly: when your tool totals a quote, what does the adding?
Reading numbers off a page
Pulling figures out of a scanned invoice or a photographed meter is a different job, and it is one the tools are good at, with one habit: a digit read off a blurred image is a guess, and the model will not say so. For anything that will be paid or billed, have it show the crop of the image next to the figure it read, so a person can confirm at a glance.
Keep the number in the system
Prices, quantities, balances and totals should live in the system that owns them, and the model should read them from there and write them back there, never hold them in its head between steps. A quote drafted by the model from a price book is fine. A quote where the model remembered the prices from last week is not.
Where it gets it wrong
Wrong about dates and today
Every model has a cutoff: the point where its reading stopped. Nothing after it exists unless a tool fetches it. That includes today's date, which is why a bare model will cheerfully schedule you for a Tuesday that was last year.
The cutoff
The model read up to a certain date and was then finished and shipped. Ask about anything after and it will either say it does not know, or guess from the pattern of what used to be true. Vendors do not always say what the cutoff is. It is a fair question, and the answer tells you how much of the present the tool would have to be told about.
Today, the calendar and the clock
Unless the product tells it, the model does not know today's date, the day of the week, your time zone or whether the shop is open. Every tool that books, schedules or promises a time must be putting that information in front of the model at each request. If a demo gets a date right, ask how; if it gets one wrong, you have your answer.
Things that changed
Prices, staff, opening hours, the name of the person who handles refunds, which product was discontinued. All of it moves, and none of it moves in the model. A tool that read your website once knows the website of that day. The fix is the same as everywhere in this course: read it live at the moment of the question, from a source that someone keeps current.
A cheap habit
Start any prompt that touches time with the date, and any that touches your business with the fact that might have changed. In a product, look for the settings that connect the calendar and the source of truth. If there are none, the tool is guessing about now, and it will be right until the day it is not.
Where it gets it wrong
Catching it: cheap checks that work
Nobody has time to proofread everything a tool produces, and nobody needs to. The mistakes cluster in a few places. Look there, skim the rest, and the check takes seconds instead of the time the tool was meant to save.
The specifics
Read the numbers, the names, the dates and the promises. Skim the sentences between them. Nearly every costly mistake sits in one of those four, because that is where the model is filling a gap rather than shaping a phrase. Ten seconds on a drafted reply, done this way, catches most of what matters.
The source
If the tool shows where an answer came from, open it once in a while and see that it says what the tool says it says. If the tool does not show sources, ask it for the line it relied on. A source that cannot be produced is a reason to treat the answer as a draft.
The second opinion
Ask the same question again in a fresh conversation, or ask a second tool. Two different fluent answers to a factual question tell you at least one is invented, and the disagreement itself is the warning. This costs nothing and takes a minute, and it is the check most people never think of.
The sample, and the rule
For anything the tool does at volume, pull five a week at random and read them properly. Trends show up in a sample long before a customer complains. And one rule for everyone: nothing with a number or a promise in it leaves the building unread. The rule is short enough to remember and it covers the ground.
Prompting, plainly
There is an industry selling prompt tricks. Almost none of it matters. What matters is the same thing that matters when you hand work to a person, and once you see that, you stop needing the tricks.
The one idea
Write what you would say to a sharp new hire who knows the trade but not your company. They do not know that your second shift runs short, that this customer pays late, that you never quote that alloy. Neither does the model. Nearly every disappointing answer comes from missing context, not from missing magic words.
Four things that reliably help
Give it the material rather than asking from memory: paste the email, the spec, the last three quotes. Show one finished example, which teaches tone and shape faster than a paragraph of instruction. Say what the output should be: a table with these columns, under two hundred words, a yes or no with one reason. And give it an exit, telling it plainly to say what it lacks rather than fill the gap, which turns a silent invention into a visible question.
What does not help
Telling it to act as a world-class expert. Promising it a tip. Threats, flattery, elaborate personas. These circulate because someone once saw an answer improve and posted about it. Measured properly, the gains are noise. Meanwhile the thing that would genuinely have helped, attaching the actual document, went undone.
Stop rewriting, start saving
When a prompt works for a real task, save it where the team can find it, with the example attached. That file is worth more than any training course, because it encodes how your business wants the job done. The teams that get value from AI are not the ones with clever prompts, they are the ones who wrote the good one down and stopped reinventing it every Tuesday.
When prompting is the wrong lever
If you are on the fifth rewrite and still fighting, the problem is usually not the wording. Either the model cannot see what it needs, and the fix is access to the document or the system, or the task needs a real lookup and no phrasing will conjure the number. Knowing when to stop rewording and go get the data is the actual skill.
Prompting, plainly
Give it the job, not a hint
Most disappointing answers were asked for badly. Write a reply to this, and you get a generic reply. Tell it who is asking, what you want, and what good looks like, and you get something you could send. It is the same brief you would give a person.
Who, what, for whom
Start with the situation: you are replying for a plumbing company to a customer who has waited two days. Then the task: draft a short apology that gives a real new time. Then the audience: a homeowner, not a contractor. Three lines, and the answer moves from generic to usable, because the model is now completing a specific pattern rather than the average of all replies ever written.
What good looks like
Say the length, the tone and the shape: under a hundred words, plain and warm, one apology, one new time, one line on how to reach us. The model will match a description of the output far more reliably than it will infer one. If you have a reply you were proud of, paste it as the model to follow.
What to leave out
Say the things it must not do: no discounts, no promises about parts, do not mention the other customer. The model has no idea what is sensitive in your business unless told, and the list of don'ts is usually shorter and more important than the list of dos.
Iterate like an editor
The first answer is a draft. Say what is wrong with it: too long, too formal, it promised something. The second answer is usually right. People who get good results from these tools are not writing clever prompts; they are giving feedback the way they would to a colleague, and stopping when it is good enough to send.
Prompting, plainly
Show it one good example
Describing the reply you want is hard. Pasting one you already like is easy, and it works better, because the model is a pattern matcher and you have just given it the pattern.
Why the example wins
A rule like keep it warm but professional means something slightly different to everyone, including the model. A real reply that is warm and professional means exactly one thing. The model reads its length, its opening, where it puts the apology, how it signs off, and reproduces that shape for the new situation. Three lines of rules cannot carry that much.
Picking it
Choose something typical, not the heroic one-off. Choose one that was actually sent and went well. If the job has two common shapes, a complaint and a question, give one of each and label them. More than three examples adds little and starts to crowd the desk.
Strip it first
The example goes into the tool, and so does everything in it. Take out the customer's name, address, job details and anything you would not paste into a stranger's email. Replace them with placeholders. The pattern survives; the private detail does not travel.
The bad example
If drafts keep coming out wrong in the same way, show it one that is wrong and say why. Here is a reply that promised a date we could not keep; never do this. A negative example fixes a recurring fault faster than any amount of rewording the instruction.
Prompting, plainly
Tell it what to do when unsure
Left alone, the model fills every gap. Told what to do at a gap, it mostly does that instead. The instruction is one sentence, and it belongs in every prompt that touches a fact.
The default is a guess
Nothing in the mechanism prefers silence to an answer. If the information is not on the desk, the likeliest continuation is still an answer, so that is what you get. The model needs to be given an alternative that is likelier than guessing, and the only way to give it one is to say it.
The four alternatives
Say you do not know, in these words. Ask the customer for the missing detail. Leave a marked blank for a person to fill. Hand the whole thing to a person with a note on why. Pick the one that suits the job and write it into the brief. For a customer-facing reply, asking or handing off is usually right; for an internal draft, a marked blank is fine.
Make the blank visible
If you choose the blank, make it loud: square brackets, capitals, a phrase that could never be sent by accident. A subtle gap gets skimmed past. A line that says CHECK PRICE BEFORE SENDING does not.
It is still not a guarantee
The instruction lowers the rate of invented answers a great deal; it does not take it to zero. The model can still produce a confident wrong fact where it believes it knows. So the instruction goes alongside the checks, not instead of them. Together they get you to a place where the checking is quick and the guessing is rare.
Prompting, plainly
The prompt you write once
Every tool has a place for instructions that apply to every conversation: sometimes called custom instructions, a system prompt, a profile, a workspace setting. It is the most valuable page in the product and the one most people never open.
What goes there
Who you are: the company, what it does, who the customers are. How you write: short, plain, no exclamation marks, sign off with a first name. What never to say: no discounts, no delivery promises, no medical or legal advice. What to do when unsure. And a good example or two. Once written, every conversation starts from there and nobody retypes it.
What to keep out
Facts that change: prices, hours, staff names. They go stale in the instructions and nobody remembers they are there. Those belong in a source the tool reads live. And anything private: the instructions are sent with every request, so they should contain nothing you would mind a vendor's logs holding.
One owner, one review
Give the instructions an owner. Review them monthly at first, then quarterly, against the drafts that came out wrong. Most of the improvement in a team's results over the first year comes from this page getting sharper, not from anyone learning to prompt.
Per person or per team
Some tools have both: a team page and a personal page. Put the business in the team page and let people add their own sign-off and tone on top. If the tool has only personal instructions, write the team's version once and have everyone paste it. It is a chore, and it is the chore that makes the tool consistent.
Why it forgets
People are surprised twice: that it forgets what they said ten minutes ago, and that it confidently summarises a document it only half read. Both come from the same limit, and it is worth understanding before you pick a tool.
The desk
Everything the model can use for an answer has to be on the desk in front of it: your question, the conversation so far, whatever documents were pasted or fetched. The desk has a fixed size. Nothing off the desk exists. There is no memory of you, your company or yesterday unless something put it back on the desk this time.
What happens when the desk fills
Something gets pushed off, usually the oldest material, which is often the instructions you gave at the start. That is the long conversation that slowly drifts back to generic answers. Some tools quietly summarise the older part to make room, so the details survive as a paraphrase, which is why a fact you stated precisely comes back slightly wrong an hour later.
The middle gets read least
Give it a long document and the beginning and end carry far more weight than the middle. This is measurable and it is consistent. A hundred-page contract summarised in one pass will be sound on the opening and the signature block and thin in the part where the liability lives. If it matters, work through it in sections and ask about each.
Memory features are a design choice, not magic
When a product remembers your preferences between sessions, it is storing notes somewhere and putting them back on the desk each time. That is useful and it is also a copy of your information sitting in a database. Worth knowing where it is, what is in it, and how to clear it, especially if a customer's details ended up in a note.
What to do about it
Prefer a tool that looks things up over one that is asked to hold everything. Start a fresh conversation for a new task rather than letting one run all day. For anything long, chunk it and check each part. And never assume that because you told it something once, it still knows.
Why it forgets
The context window, plainly
The context window is the size of the desk: everything the model can see at once. Vendors quote it in tokens, which are roughly three quarters of a word each. A window of a hundred thousand tokens is a novel; a window of a few thousand is a long email.
What counts against it
Your standing instructions. The conversation so far, every turn of it, including the model's own answers. Every document pasted or fetched. The question. All of it, every time, because the model reads the whole desk afresh for each answer. A long chat with three attached files can fill a large window sooner than people expect.
At the edge
When it fills, something is dropped or compressed. Which thing depends on the product: some drop the oldest turns, some summarise them, some refuse and ask you to start over. Refusing is the honest behaviour. Quietly summarising is the one that turns a fact you stated precisely into a paraphrase that is slightly off.
Bigger is not free
A model reads everything on the desk for every answer, so a full window makes each answer slower and dearer, and the attention it pays to any one line gets thinner. The largest window is not the best setting for every job. For a short task, a short conversation in a fresh window is faster, cheaper and more accurate.
Working with it
Start fresh for a new task. Put the instruction that matters at the end as well as the start. For a long document, work in sections and ask about each. And when the tool starts giving generic answers late in a long session, that is the window, not the model getting tired. Begin again with the facts restated.
Why it forgets
What memory features really do
The model itself has no memory between conversations. When a product remembers you, the product has stored notes and is putting them on the desk each time. That is useful, and it is a database of things about you and your customers, and it deserves five minutes of thought.
Two kinds of note
Things you told it to remember: my company is called this, sign off with Sam, never use exclamation marks. And things it decided to remember: a detail from a pasted email, a preference it inferred, a customer's situation. The first kind is exactly what you want. The second kind fills up unwatched and is where the surprises live.
Worth remembering
Your standing preferences and the shape of your business. Nothing else needs to live there, because facts that change belong in a live source, and facts about customers belong in the customer system. A memory full of stable preferences makes the tool feel like it knows you. A memory full of last month's cases makes it confidently wrong about this month.
The settings page
Find where the memories are listed. Read them. Delete what should not be there. Look for a switch that stops the tool adding memories on its own, and consider turning it on for anyone who handles customer information. If the product has memory and no such page, it is keeping a file it will not show you, and that is a reason to pick another product.
For a team
Decide whether memory is shared. Shared memory means one correction helps everyone and one person's pasted contract is in everyone's context. Personal memory means the business is re-explained by each person. Most small firms are best served by shared standing instructions and personal memory switched to manual, and by writing that choice down.
Why it forgets
The middle of a long document
Hand the model a sixty-page contract and ask what it says about liability, and you will get a confident answer weighted toward the opening and the signature pages. The clause on page thirty-one is on the desk, and it is the part read least.
What the measurements show
Put a fact in the middle of a long document and ask about it, and the model finds it less reliably than the same fact placed at the start or the end. This has been measured across many models and it is consistent. The bigger the document, the deeper the dip. It is not a bug in one product; it is how attention spreads over a long page.
Where it bites
Contracts, where the clause that matters is rarely on page one. Manuals, where the warning is in the middle of chapter six. Long email threads, where the decision was made in message fourteen of thirty. Any summary of these will be sound on the edges and thin in the middle, and it will not say so.
Work in sections
Split the document at its natural joins and ask about each part on its own. Ask a specific question rather than for a summary: what does this section say about payment terms. Then ask for the whole. The section answers keep the whole one honest, and the cost is a few extra minutes on a document that took someone a week to write.
Or let the tool find the page
Products that search the document for the relevant passage and hand only that to the model sidestep the problem: the desk holds two pages instead of sixty, and both get read properly. That is what a good document tool is doing behind the answer, and it is worth asking whether yours does.
Fine-tuning or retrieval
Two approaches, forever confused, and the confusion is expensive because one of them is a project with an owner and a budget and the other is mostly housekeeping.
Retrieval: hand it the folder
Your documents are indexed. A question comes in, the relevant passages are found and put in front of the model, and it answers from them. Change a document and the next answer reflects it. It can show you the passage it used, which makes checking quick. This handles the overwhelming majority of business needs and it is what most products are doing under the marketing.
Fine-tuning: teach it the voice
You take a few hundred examples of a task done the way you want it done and adjust the model on them. What you get is consistency of style and shape: your tone, your structure, your fields, every time, without a long instruction each request. It is genuinely good at that. It is bad at facts, because a fact taught this way cannot be edited later, only retrained out.
The question that decides it
Does the answer change when a document changes? If yes, you need retrieval, and fine-tuning will make the tool confidently out of date. If the answer is always the same shape and only the wording is in question, fine-tuning earns its place. Most businesses need retrieval, and a smaller number need both, with fine-tuning handling the format and retrieval handling the facts.
What each costs to keep
Retrieval costs housekeeping: someone keeps the document set clean, removes the superseded version, and notices when an answer cites a file from four years ago. Fine-tuning costs a project each time the underlying model is upgraded or your examples go stale, and models are upgraded often. Ask any vendor proposing fine-tuning what happens at the next model version, and who pays.
What to ask a vendor
Which of the two are you doing, in those words. If retrieval, can it show me the source passage for an answer. If fine-tuning, how many examples, who prepares them, and what does the next model upgrade cost me. Vagueness here is the tell: the teams who have actually done it answer immediately, because they have a scar from each question.
Fine-tuning or retrieval
Retrieval, step by step
Nearly every product that answers from your documents does the same three things: searches them for the passage most like your question, puts that passage in front of the model, and asks. The quality of the answer is decided in the first step, before the model is involved at all.
Step one: the search
Your documents are cut into chunks, a paragraph or so each, and each chunk is indexed by meaning rather than by exact words, so a question about a leaking valve can find a passage that says drip. When you ask, the tool pulls the handful of chunks closest to your question. If the right paragraph is not among them, nothing that follows can save the answer.
Step two: the desk
Those chunks are placed on the desk with your question and an instruction to answer from them. The model reads a few pages, not your whole archive, which is why this works on a hundred thousand documents when pasting them all would not. It is also why the answer is only as good as the chunks: a missing paragraph is an invented fact waiting to happen.
Step three: the answer, with its source
A good tool returns the answer and the passages it used, so a person can check in seconds. Insist on this. A tool that answers from your documents without showing which ones has removed the only cheap check there is.
Where it breaks
Documents that were never indexed. Scans that were indexed as images and contain no words. Two versions of the same policy, both indexed, one out of date. A question that uses different words from the document and finds the wrong chunk. Ask a vendor how each of these is handled, and try the two-versions case in the demo.
Fine-tuning or retrieval
What fine-tuning is good for
Fine-tuning sounds like the serious option, and vendors like to offer it. It adjusts a finished model on a set of examples so it produces output more like those examples. That is a useful thing, in a narrower set of cases than the word suggests.
What it changes
The style, the format, the habits. A model tuned on a thousand of your quotes will lay out a quote the way you do without being told each time. A model tuned on support replies will sound like your best agent. It learns the shape of the output, and it learns it well.
What it does not change
What is true. A tuned model does not know your prices or your stock any more than an untuned one; it has learned to write a quote, not to know the numbers in it. People expect tuning to install knowledge and are surprised when the tuned model invents a part number in a beautifully formatted line. Facts come from retrieval. Tuning is for voice.
When it pays
A high-volume output with a strict format that instructions keep getting slightly wrong. A voice that matters commercially and that a standing instruction cannot capture. A small model you want to run cheaply that needs to behave like a bigger one on one narrow task. Outside those, a good standing instruction and a couple of examples get you ninety percent of the result for none of the cost.
The cost you keep paying
A tuned model is a version. When the vendor ships a better base model, your tuning does not carry over; someone re-runs it. When your examples change, someone re-runs it. And the examples went into a model that now exists, which is worth thinking about if they were customer emails. Ask who owns the tuned model, and what happens to it when you leave.
Fine-tuning or retrieval
Keeping the answers current
A tool that reads your documents is only current if the documents are, and if it noticed the change. Both of those are someone's job, and in most small businesses that someone has not been named.
One source, not a copy
If the tool was handed a folder of files in March, it knows March. If it is connected to the live folder and re-reads on a schedule, it knows the last run. If it reads the document at the moment of the question, it knows now. Ask which of those you are buying. The first is common, cheap and quietly dangerous.
The two-versions problem
The old policy and the new one both live in the folder, because nobody deletes anything. The search finds both. The model gets both on the desk and picks one, or blends them. The fix is not in the tool; it is a habit of archiving old versions somewhere the tool does not read, and a person whose job that is.
Re-indexing, and when it happens
A change to a document is not seen until the tool re-indexes it. Some products do that within minutes, some nightly, some when someone presses a button. Find out, and match it to how fast your facts change. Prices that move weekly need nightly at worst. A staff list that changes twice a year can wait.
The owner
Name one person who owns the sources the tool reads: what is in the folder, what is archived, when re-indexing runs, and who checks a sample of answers each month. Without that person the tool drifts, and the first sign is a customer being told last year's price in a confident voice.
How it reads a document
This is where most document projects actually fail, and it has nothing to do with the intelligence of the model. It is the boring question of whether the text can be got at at all.
Two kinds of PDF
One was made from a document and still contains real text. The other is a photograph of paper in a PDF wrapper, and contains no text at all, only pixels. They look identical to you. To a tool they could not be more different. Try selecting a sentence: if you cannot, neither can the software, and everything downstream now depends on character recognition and its mistakes.
Tables and drawings are where meaning leaks
Extracting a table flattens it. Rows run together, merged cells scatter, a column heading ends up attached to the wrong number. The model then reads that soup and answers confidently from it. Anything where the meaning lives in the layout, specification tables, dimensioned drawings, forms, multi-column price lists, deserves a look before you trust an answer drawn from it.
Chunking, and why an answer misses the obvious
Long documents are cut into pieces so the right piece can be found later. Cut badly, a clause is severed from its exception, or a heading ends up in a different piece than the paragraph it governs. The search then returns a passage that is technically relevant and materially incomplete. When a tool misses something that is plainly in the document, this is usually why.
Versions do more damage than quality
Three copies of a policy from different years, all indexed, and the tool will happily quote whichever it found. It has no way to know which one is current. Sorting out which document is the live one is unglamorous and it does more for accuracy than any model upgrade. This is work your side has to do, and it is the work vendors are politest about.
A test before you spend
Pick twenty documents that represent the messy reality, not the clean examples. Count how many are scans. Open the worst table. Then ask the tool ten questions you already know the answers to, and check the passage it cites, not just the answer. Twenty minutes of that tells you more than a month of demos.
How it reads a document
Scans, photos and handwriting
A scanned invoice is a picture. Before the model can read it, something has to turn the picture into words, and that step is where the trouble starts. Modern tools are good at it, and good is not the same as certain.
The picture becomes words
The tool looks at the image and produces text: printed text very reliably, typed forms well, clean handwriting reasonably, a plumber's notes on a damp carbon copy less so. The output looks like text either way. There is no wobble in the letters to show which ones were guessed, and a 7 read as a 1 arrives as a perfectly confident 1.
Where it is safe
Pulling the supplier name, the date and the description off a printed invoice. Sorting a pile of scans by type. Transcribing a typed letter. Drafting a summary of a photographed page. Anything where a misread word is an inconvenience rather than a cost.
Where it needs a look
Totals, quantities, account numbers, part codes, anything handwritten that turns into money or a shipment. The tool should show the crop of the image next to each figure it read, so a person can confirm in a glance rather than re-reading the whole page. Products built for accounts payable do this; general chat tools do not.
The habit
Confirm the figures against the picture, not against the text. Ten seconds per document, on the numbers only. Better still, have the tool flag the ones it is least sure of, which the good ones can, and look at those first.
How it reads a document
Tables, forms and layout
A price list is a table: the meaning is in which number sits under which heading beside which item. Turn it into a run of words and the meaning goes. The model then reads the words, in a confident voice, and puts the wrong price on the wrong part.
What gets lost
Reading a page into text keeps the words and drops the geometry. Column headings float away from their columns. A cell that spans two rows attaches to one. A form's label ends up two lines from its answer. The model is then working from a jumble that looks like text and reasoning about a structure it can no longer see.
What the good tools do
Products built for documents detect tables and extract them as tables, cell by cell, and forms as pairs of label and value. They show the result in a grid a person can scan. The difference between a general chat tool and one of these on a twelve-column delivery note is the difference between a guess and a record.
The two-page table and the merged cell
The classic failures: a table that continues on the next page and loses its headings, a merged cell that applies to five rows and is attached to one, a totals row read as a line item. Test with your own ugliest document, not the vendor's clean sample.
Go around it when you can
If the table came out of a system, the system can usually export it as data. A spreadsheet or a file from the supplier's portal beats the most careful reading of the PDF they printed from it. Ask for the data before you build a tool to recover it from a picture.
How it reads a document
Spreadsheets and the numbers in them
The model is good at spreadsheets in one way and hopeless in another. It can write a formula, explain a sheet, spot a column that looks wrong. It cannot add up the column reliably in its head. The tools that work know which is which.
Reading and explaining
Hand it a sheet and ask what it does, and you will get a fair account: which columns feed which, where the totals come from, what looks inconsistent. This is genuinely useful for the spreadsheet somebody built in 2019 and left with. It is reading structure, and it is good at that.
Writing formulas and code
Describe what you want, get a formula. This works well and saves real time, with one rule: test the formula on rows where you know the answer. A formula that is nearly right is worse than none, because it looks finished.
The arithmetic
Ask it for the total of column D and it will guess a total. Good tools do not do this; they have the spreadsheet compute it and read back the result. The tell in a demo is whether the tool shows you the formula or the code it ran. If it just states a number, ask where the number came from.
Cells, not screenshots
Give the tool the file, or connect it to the sheet. A screenshot of a spreadsheet is a picture of numbers, and now you are back to reading digits off an image. The file carries the structure and the formulas; the picture carries neither.
How it reads a document
Drawings, photos and what it sees
Show the model a photo of a boiler nameplate and it will read the model number. Show it a drawing and ask for the length of the flange and it will give you a number, which is the problem. It sees the way a person glances, not the way a person measures.
What it does well
Reads text in the image: nameplates, labels, signs, a serial number. Describes what is there: a corroded fitting, a cracked tile, three vans in a yard. Sorts photos by what they show. Drafts the note a technician would write from the picture. For a trade that lives on photos from the job, this is real time saved.
What it cannot do
Measure. A dimension off a drawing, a distance in a photo, the size of a crack: any number it gives you is a guess dressed as a reading. Count reliably past a handful: twelve bolts might come back as eleven. Judge fine condition: whether that weld is acceptable is a person's call, from the part, not the picture.
Drawings in particular
It can read the title block, the notes and the dimensions that are written as text. It cannot derive a dimension from the geometry, follow a section view, or tell you the drawing is at the wrong revision. Treat it as a reader of the words on the drawing, never as a reader of the drawing.
Where it pays
The photo becomes the job note. The nameplate becomes the parts lookup. The pile of site photos becomes a sorted folder with a draft report. Each of those is a description task, and each one takes a person a minute they will not miss.
What happens to what you type
Nearly every company we speak to already has people using AI at work, usually on a personal account, usually with real information. Understanding the plumbing is how that becomes a decision rather than an accident.
The path
Your text leaves your machine, travels to the provider, is processed, and an answer comes back. In transit it is encrypted. On arrival it is handled according to whatever account you are using, and that is the part that varies enormously between the free tab someone opened and the business agreement someone signed.
The difference that matters
Consumer accounts commonly reserve the right to use what you type to improve the service, and often keep a history by default. Business and enterprise agreements typically commit to the opposite: not used for training, retained only briefly for abuse monitoring, deletable on request. Same underlying model, materially different contract. Most of the alarming stories are a consumer account being used for company work.
Retention is not the same as training
Two separate questions, often blurred. Is it kept, and for how long, is retention. Is it used to change the model is training. A vendor can honestly say we do not train on your data while still holding it for thirty days for support and safety. Both answers matter, and you should ask for both in writing rather than accept the reassuring half.
The forwarding problem
Many tools you buy are a layer over someone else's model. Your text may pass through the vendor and on to a model provider, and possibly a search provider too. Each hop is a company with its own terms. Ask any vendor which model providers they send your data to and what those providers' terms say. A vendor who cannot answer has not read them either.
What to do this week
Assume it is already happening and ask, without blame, so you find out honestly. Give the team an approved place to do it, because a ban only moves the activity out of sight. Say plainly what must never be pasted anywhere: customer lists, anything under a confidentiality agreement, personal records, credentials. One page, in their words, beats a policy nobody opens.
What happens to what you type
Who can see it
What you type travels: to the product you are using, often on to the company whose model sits underneath, and sometimes across to a colleague's screen. Each of those is a different question with a different answer, and a vendor should be able to give all three.
The vendor's staff
Conversations are stored, and some people at the vendor can read them: to investigate abuse, to fix a bug, to review a complaint. Ask who, under what rule, and for how long the conversations are kept. A good answer names a team, a reason and a retention period. A vague answer means the rule is whatever the engineer on call decides.
The company behind the model
Most products are built on a model from one of a few companies, and your text passes through that company's systems too. On a business arrangement it is normally not stored beyond a short abuse window and not used for training. Ask the vendor to say which model company they use and what terms they have with it. If they will not say, you cannot know where your text goes.
Your own team
In a shared workspace, an administrator can often see everyone's conversations, and shared memory or shared documents can surface one person's paste in another person's answer. Decide what should be private and check the settings against it. The most common leak inside a small firm is a salary spreadsheet pasted by one person and found by another.
The straight questions
Who at your company can read my conversations, and when? Which model provider do you use, and are my inputs used to train? How long do you keep what I type? Can my colleagues see it? Four questions, all with short factual answers. A vendor who has them ready has thought about it.
What happens to what you type
Is it used to train the next model
The same product can use your conversations to improve its models on one plan and promise never to on another. The difference is usually a paid business tier and a checkbox, and most small firms have never looked at either.
The consumer default
Free and personal plans commonly use conversations to improve the product unless you opt out, and the opt-out is in a settings page nobody visits. This is the plan people sign up for on their phone on a Saturday to try it. It is also the plan half of a typical small team is on when nobody has set anything up.
The business default
Business and team plans generally promise the opposite: your inputs are not used for training, retention is short and stated, and there is an agreement you can read. This is what you want, and it costs more per seat. The cost is the price of the promise being in a contract rather than a blog post.
What training use actually risks
Not your document being handed back whole to a stranger; that is not how training works. The risk is subtler: turns of phrase, unusual names, a distinctive pattern from your data becoming faintly more likely in a model everyone uses. For most businesses that is a small risk. For one with a trade secret in its documents, it is a reason to be on the plan that promises not to.
What to do this week
Find out which plan each person is on. Move work onto a business plan with training use off. Turn the opt-out on for anyone who must stay on a personal plan. Write one line for the team: work goes in the work account. That closes most of the gap in an afternoon.
What happens to what you type
Where it is stored, and for how long
Type it, and it is written to a disk somewhere, kept for a period, backed up, and eventually deleted, or not. The period and the place are facts the vendor knows and will state if asked. Most small firms have never asked.
Retention, plainly
Retention is how long the vendor keeps what you typed. Some keep it until you delete it; some keep it for thirty days after that; some keep it indefinitely on a plan that does not say otherwise. Deleting a conversation in the app removes it from your view, and the file may persist for the stated period, and in backups for longer. Ask for the number.
Where the servers are
For most businesses the country does not matter. For some it does: a customer contract that says their data stays in a region, a professional rule about client files, a sector with its own requirements. If any of those apply to you, ask where the data is stored and processed, and get it in writing rather than in a demo.
Export and delete
You should be able to take everything out and remove everything, for one person or the whole company. Check that both exist before you need them. The day someone leaves, or a customer asks what you hold about them, is the wrong day to discover the delete button removes the label and keeps the file.
Keep the sensitive things out
The simplest retention policy is the one where the sensitive material never went in. Names replaced with placeholders, account numbers left out, the contract summarised by a person before the summary is pasted. It costs a minute and it makes every other question smaller.
What happens to what you type
Settings to change on day one
Every tool ships with defaults chosen for the vendor's convenience, not yours. Ten minutes on the settings page, once, on the day it is set up, changes what happens to everything typed into it afterwards.
Training use: off
Find the switch that stops conversations being used to improve the model, and turn it off for the workspace, not just for yourself. On a business plan it may already be off; confirm it. On a personal plan, this is the one setting that matters most.
Memory: deliberate
Decide whether the tool should remember things on its own. For anyone handling customer information, set memory to manual, so it only keeps what it is told to. Read the list of existing memories and clear anything that should not be there.
Sharing and administrators
Check who can see whose conversations. Check who is an administrator, because administrators usually can see everything, and the person who signed up for the trial is an administrator by default whether or not that was the plan. Make it the person who should be, and nobody else.
Retention and the one-page note
Set retention to the shortest period the tool allows that still suits the work. Then write one page for the team: which account to use, what never to paste, what to do when unsure, who to ask. Pin it where the tool is. That page does more for safety than any setting.
Open or closed models
Someone will eventually tell you to run your own model for control and savings. Occasionally they are right. More often the savings do not survive contact with the staffing, and it is worth knowing which case you are in.
What the two mean
A closed model is rented: it runs on the provider's machines, you send requests and pay per use, and you cannot inspect or alter it. An open-weight model is published, so you can download it and run it on hardware you rent or own. It is not open in the sense that you could rebuild it, but you can put it where you like, including inside your own network.
The real reasons to run your own
A rule or a contract that genuinely forbids the data leaving your control. A workload so steady and so large that per-use pricing dominates your costs. A need for the model to sit next to something with no outside connection. These are legitimate and they are specific. Notice that being uneasy about the cloud is not on the list, because a business agreement usually addresses the uneasiness more cheaply.
What self-hosting actually costs
Hardware or rented machines that cost the same whether busy or idle. A person who understands them, on call, forever. Upgrades, because a self-hosted model does not improve on its own while the rented one improves monthly. Capacity planning for your busiest hour. The licence is free. Everything around it is not, and the total lands above rental for most mid-sized businesses.
The capability gap, honestly
Open models have closed much of the gap and for many tasks, sorting, extracting, drafting routine text, you would not notice the difference. The gap persists on the hardest reasoning and on long, complex documents. Test both on your own work rather than trusting a leaderboard, because your work is not the benchmark.
The middle path most people want
A business agreement with a rented provider: your data is not trained on, retention is short and contractual, and you can be told where it is processed. That covers the concern behind most self-hosting requests at a fraction of the cost and none of the staffing. Start there, and revisit if a real rule or a real volume pushes you.
Open or closed models
Running a model on your own machine
Some models are published for anyone to download and run. Run one on a machine you own and nothing you type goes anywhere. That is a real benefit with a real price, and the price is mostly paid in someone's time.
What you need
A computer with a capable graphics card, or a small server, and someone to install the model, keep it updated and fix it when it stops. For a small model that is a decent desktop. For a large one it is real hardware. The software to run it is free and getting easier every month; the person is the part that is not free.
What you get
Privacy that is a fact rather than a promise: the text never leaves. No per-use bill, so a job that runs a hundred thousand times costs electricity. Independence from a vendor changing its terms, its prices or its model under you. And the ability to run at night on documents you would never upload.
What you give up
The best models are not the ones you can download; the gap has narrowed and it is still there. Speed, unless you buy the hardware. Convenience: no app, no phone version, no support line. And when it breaks at four on a Friday, it is your problem.
Where it makes sense
One narrow job, at volume, on sensitive material: sorting incoming documents, redacting names before something is sent to a hosted tool, drafting from a private archive. Not the general assistant for the whole team, which is better and cheaper rented. Many firms end up with both: a rented assistant for people, a private model for the one job that needs it.
Open or closed models
What you give up with each
Open and closed are not sides to join. They are two ways of paying for the same thing: with money and dependence, or with hardware and time. Most small businesses end up paying both ways, for different jobs.
Quality
The closed models from the big companies are, at any moment, somewhat better than the best you can download. For drafting a reply the difference is invisible. For a hard reasoning task or a long, messy document it shows. Try both on your real work before believing either side's chart.
Cost and its shape
Rented is per seat or per use: small to start, and it grows with success. Owned is a lump up front and a person's time forever: expensive to start, and flat. A job you run twice a day rents cheaply. A job you run twenty thousand times a night is where owning starts to pay.
Dependence
A rented model can change: a new version that answers differently, a price rise, a feature withdrawn, an outage on your busiest day. An owned model does exactly what it did yesterday until you change it. That stability is worth more than it sounds for anything a customer interacts with.
Deciding without a side
List the jobs. For each, ask: does the text have to stay in the building, and how many times a day does it run? Private and frequent leans open. Public-enough and occasional leans closed. Most lists split, and the answer is two tools with a clear line between them.
Open or closed models
Small models, and when they are enough
Models come in sizes. The largest are the ones in the news and the ones vendors default to, because they look best in a demo. A great deal of daily work is done as well by a model a tenth the size, at a tenth the cost, in a fifth of the time.
What a small model does well
Sorting messages into categories. Pulling a name, a date and an amount out of an email. Drafting a routine reply from a template and a few facts. Summarising a short call. Flagging the complaint in a pile of reviews. Anything with a clear pattern and a short answer, which is most of the volume in a small business.
Where it falls short
Long documents with subtle contradictions. Multi-step reasoning. Writing that has to persuade. Unusual situations the pattern does not cover. When a small model is wrong it is wrong in the same confident voice as a large one, so the test is the same: run both on real work and read the results.
Why it matters at volume
A task that costs a few cents per run with a large model and a fraction of a cent with a small one is a rounding error at ten runs a day and a line on the accounts at ten thousand. Speed matters too: a customer waiting on a chat reply notices the difference between two seconds and eight.
Ask for the choice
Good products let you set which model sits behind each job, and route the easy ones to the cheap model automatically. Ask a vendor whether you can, and what the default is. If every task runs on the largest model, you are paying for a courier to walk next door, all day, every day.
The human in the loop
Everyone agrees there should be a human in the loop. Far fewer have decided which human, at which step, checking what, which is where the phrase stops meaning anything.
Blanket review fails, predictably
Put a person on everything the tool produces and within a week they are approving without reading, because almost all of it was fine and attention is finite. This is not a discipline problem. Checking work that is usually correct is a task humans are known to be bad at. A process that depends on it will let through exactly the ones you care about.
Gate the consequence, not the volume
Sort the output by what happens if it is wrong. Anything that sends money, commits you contractually, reaches a customer unedited or is hard to undo gets a real human decision. Internal drafts, first passes and suggestions go through untouched, because the next step already involves a person who will notice. Two categories, decided once, beats a review queue nobody trusts.
Make checking cheap
A reviewer who has to verify a claim from scratch will not. A reviewer who sees the quoted source beside the sentence will. Show the passage. Show what changed from the last version. Flag the three fields the tool was least sure about instead of presenting twenty with equal confidence. The goal is a check that takes ten seconds and actually means something.
Accountability does not move
The person who signed the quote still signed the quote. Nobody outside your company cares that a tool drafted it, and no regulator or customer has ever accepted that answer. Say this out loud early, because teams quietly assume responsibility shifted to the software, and that assumption is where the careless approvals come from.
Watch the trend, not the item
Keep the correction rate. If reviewers are fixing a third of the output, the tool is not ready for that task. If they are fixing almost none for months, the gate may be theatre and the check could move elsewhere. Either way it is the trend that tells you something, and nobody collects it unless somebody is asked to.
The human in the loop
Draft, review, send
The tool writes, a person reads, a person sends. It is not the exciting version and it is the version that survives contact with real customers. Almost every good use of AI in a small business is this shape with different words in the middle.
Why it works
The model does the part it is good at, the first draft, which is the part that takes a person the longest. The person does the part the model cannot, which is knowing whether it is true and whether it should be sent. The mistake is caught where it is cheapest, before it leaves, by someone who would have written the thing anyway and is now reading instead.
Put the draft where the person already is
In the inbox as a reply waiting to be sent. In the job system as a note waiting to be saved. Not in a separate tool that someone has to remember to open. The workflow fails when the review is a chore in another window and succeeds when it is one click in the window that was open anyway.
Make the review a look, not a read
Teach the reviewer where to look: numbers, names, dates, promises. Have the tool mark anything it was unsure of. A review that takes ten seconds happens; one that takes two minutes stops happening by week three, and then the shape is draft, send.
Loosen on evidence
Keep a count of drafts sent unchanged. When a category runs at a hundred unchanged in a row, consider letting that category go without review, with a weekly sample instead. Tighten again the first time the sample turns up something wrong. That is how trust in a person is built, and it works the same way here.
The human in the loop
What to let it do alone
Not everything needs a person. Sorting mail does not; a refund does. The line between them is not how clever the tool is. It is three questions about the job, and any job that passes all three can run alone.
Can it be undone
A label applied to a message can be removed. A draft saved to a folder can be deleted. A reply sent to a customer cannot be unsent, and a refund issued cannot be un-issued without a conversation. The reversible jobs are the candidates. The irreversible ones stay behind a person, however good the tool gets.
What a mistake costs
A mis-sorted email costs a minute of someone's time. A wrong price on a quote costs the margin or the customer. A wrong promise about a delivery costs a reputation. Put a number, even a rough one, on the worst mistake the job could make. Under a few pounds or dollars and a minute, let it run. Above that, a person looks.
Is someone watching
Alone does not mean unwatched. Every job that runs without review needs a weekly sample read by a person, a count that would show if it stopped, and a way to pull it back behind review in a minute. Without those, alone means unnoticed until a customer notices.
Jobs that pass, and jobs that never will
Pass: sorting, tagging, summarising for internal use, drafting into a folder, the morning report, the reminder that a person approved the wording of once. Never: money, promises, deletions, anything legal or medical, anything sent to a customer that has a number in it. The list is shorter than vendors suggest and it is enough to save real hours.
The human in the loop
Who signs, and what they are signing
A review step with nobody's name on it is a box that gets ticked. The person who approves an AI output is vouching for it the way they would for their own work, and they should know exactly what they are vouching for.
Name the person
For every kind of output, one person or one role owns the approval: quotes are Sam's, customer replies are whoever is on the desk, the weekly report is the owner's. Not the team, not whoever is free. A review owned by everyone is done by no one, and the tool learns nothing from it because nothing is fed back.
Say what they are signing
Write the one sentence: I have checked the price against the price book and the date against the calendar. Or: I have confirmed this says nothing we cannot deliver. A reviewer who knows the sentence checks in ten seconds. A reviewer told to just look it over reads for tone, misses the number, and signs.
What signing means
When it goes out with a person's approval, it is that person's work, the same as if they had typed it. That is fair only if the review was real and the person was given the time for it. Make it real: the sentence above, the time in the day, and the standing to reject a draft and write it by hand.
Cover and record
Name a second person for when the first is away, so the queue does not either stall or get waved through. Keep the record: who approved what, when, with what changes. It is the log that shows a job is ready to run alone, and the log that shows what happened when something went wrong.
The human in the loop
When the reviewer stops reading
The tool is good, so the reviewer approves. It is good again, so they approve faster. By the fortieth it is a reflex, and the review has stopped existing while still appearing on the process diagram. This is not a character flaw. It is what people do, and the process has to be built for it.
Why it happens to everyone
Attention follows surprise. A stream of correct drafts trains the reviewer that the stream is correct, and the reading turns into a glance, then into a click. It happens to pilots, to inspectors and to proofreaders, and it happens faster when the reviewer is busy and the tool is good. The better the tool, the sooner the review hollows out.
How to see it
Count changes. A reviewer who has not changed a draft in two weeks is either looking at a perfect tool or not looking. Time the review; when the average drops under the time it takes to read the numbers, the numbers are not being read. Neither measure blames anyone; both tell you the process has drifted.
Four ways to keep it real
Narrow the review to the specifics, so it stays short enough to do properly. Have the tool mark what it was unsure of, so the reviewer has somewhere to look. Rotate reviewers, because a fresh pair of eyes has not been trained by the stream yet. And plant a deliberate error now and then, tell the team you do, and see whether it is caught.
Or stop pretending
If a category of output has run for months with no changes, the honest move is to let it run alone with a weekly sample, rather than keep a review that has already stopped. A real sample read properly beats a hundred reflexive approvals, and it frees the person to review the things that still need it.
The words vendors use
Nobody wants to stop a meeting to ask what a word means. So proposals get signed with a fog in the middle of them. Here is the fog, cleared, with the question each word should prompt.
The basics
A model is the trained thing that produces the output. A large language model is one that works in text. A token is the chunk of text it counts in, roughly three-quarters of a word, and it is how you are billed. Context or context window is how much it can hold at once. Inference is one run of the thing, which is what you pay for each time.
How it gets your information
Retrieval, or RAG, means your documents are searched and the relevant passages are put in front of the model. An embedding is the numeric fingerprint that makes that search work, and a vector database is where those fingerprints live. Fine-tuning means the model itself was adjusted on your examples. Ask which of these is happening, because vendors use trained for all of them.
When it does things
An agent is a model wired to tools that can act. Tool use or function calling is the mechanism. Orchestration is the code deciding which step comes next. The Model Context Protocol is an open standard for connecting a model to tools and data, and a vendor supporting it is a mild good sign, because it suggests you are less locked in.
Words about failure
Hallucination means it made something up. Grounding means answers are tied to real source material. Guardrails are the rules meant to stop bad output, and their quality varies wildly. Evaluation, or evals, is the testing that proves any of it works. Ask to see the evals. The absence of an answer is itself an answer.
Words that should slow you down
Enterprise-grade, best-in-class, state of the art and AI-powered mean nothing on their own. Each should be met with the same question: what specifically, and can I see it. A vendor with substance welcomes that question because it separates them from the ones repeating the words. A vendor without substance changes the subject, and you have learned what you needed.
The words vendors use
“Agentic” and “autonomous”
Agentic is the fashionable word, autonomous the older one. Both mean the same thing in a pitch: the tool does not just write, it acts, and it acts without a person approving each step. That is either the whole value or the whole risk, and the word does not tell you which.
Translate it
Every time you hear either word, ask the vendor to replace it with a list: it can send email as you, it can book into your calendar, it can change a customer's address, it can issue a refund up to this amount. A vendor who can produce the list has built the thing carefully. A vendor who keeps saying agentic has not, or does not want you to see the list.
Autonomous has a dial
There is a range between a tool that drafts and a tool that acts, and a good product lets you set where on it each job sits: draft only, act and tell me, act and tell me only if unusual, act silently. The pitch will be at the far end. You should start at the near end and move along the dial on evidence.
The login and the limits
An autonomous tool acts through an account, and it can do whatever that account can. Ask for its own account, with limits: a refund cap, a list of who it may email, calendars it may write to. Limits enforced by the account hold when the model has a bad day. Limits written in the prompt are a request.
The reference question
Ask what it did for another customer that they did not expect. Every vendor of an acting tool has a story; the honest ones tell it and say what they changed. A vendor with no story either has few customers or is not listening to them.
The words vendors use
“Enterprise-grade” and “secure”
Every product is secure in its brochure. The word costs nothing to print. What costs something is the specific answer to a specific question, and a vendor who has done the work has the answers ready.
Five questions instead
Who at your company can read my data, and under what rule? Where is it stored and processed? How long is it kept after I delete it? What happens when you have a breach, and how fast do you tell me? Is any of that in the contract, or only on the website? Each has a short factual answer. The answers are the security review; the adjective was the cover.
Badges and what they show
A certification badge means an auditor checked that the vendor has certain processes. It does not mean your data is handled the way you want; it means there is a process. Ask for the report behind the badge and read the scope. It is often narrower than the badge suggests, and sometimes covers a different product.
Enterprise-grade, translated
It usually means: we have a tier that big companies bought, with the settings they asked for. Whether you are on that tier is a separate question. The small business plan of an enterprise-grade product is frequently the consumer product with an invoice. Ask which tier you are being sold and what is different about it.
The contract is the product
If the promise is not in the agreement you sign, it is a hope. Read the data section of the terms; it is usually two pages. Anything the salesperson said that is not in there, ask to have added or accept that it was conversation.
The words vendors use
“Powered by”, “built on”, “trained on”
Powered by means someone else's model is doing the writing and this company built what sits around it. That is not a criticism; nearly every product works that way. It does tell you where your text goes and what you are actually paying for.
The model and the wrapper
The model produces the words. The wrapper decides what goes in front of it: your documents, your standing instructions, the lookup in your calendar, the step that checks the number, the screen you see. A good wrapper is most of the value in a business tool. A thin wrapper is a chat window with a logo, sold at a markup.
Why it matters for your data
Your text passes through the wrapper company and on to the model company. Two sets of terms, two places it is stored, two sets of staff who might see it. The vendor should say which model company they use and what their agreement with it says about your data. If they will not name the model company, you cannot know where your text goes.
Thin or thick
Ask what the product does that the bare model does not. Good answers: it reads our job system, it checks quotes against the price book, it hands off to a person when unsure, it shows the source. A weak answer: it has a nicer interface and templates. The second kind is worth trying for a month and rarely worth a contract.
Trained on, one more time
When the same pitch says trained on, it almost always means the wrapper fetches your documents at question time. That is the good version. It is worth confirming, once, with the question that settles it: when I change a document, when does the tool know?
The words vendors use
“Hallucination”, “grounding”, “guardrails”
You will hear all three in the first ten minutes of any demo. They describe one problem, the confident wrong answer, and the two things products do about it. Neither thing removes the problem. Both make it smaller, in different ways.
Hallucination
The industry's word for an invented answer. It sounds like a rare malfunction, and it is the normal behaviour of the mechanism in a gap. When a vendor says their product does not hallucinate, they mean they have done the two things below and it hallucinates less. Ask for the rate, measured, on real customers. An honest vendor has a number.
Grounding
Giving the model the source before asking: your document, your price list, today's date. An answer grounded in a passage you can open is checkable in seconds. Ask what it is grounded in and whether the answer shows the passage. Grounded in our knowledge base, with no passage shown, is a claim; grounded in this paragraph, here it is, is a feature.
Guardrails
Rules around the model: do not discuss pricing, do not give medical advice, hand off if the customer is angry, never promise a date. Some are enforced in the wrapper, which holds; some are a line in the prompt, which is a request. Ask which. And ask what happens when a rail triggers: does the customer get a graceful hand-off or a refusal that reads like a wall?
What none of it replaces
A person reading the specifics before anything with a number or a promise goes out. Grounding and guardrails make that read shorter and the errors rarer. They do not make it optional, whatever the slide says.