I keep hearing a familiar phrase.

AI did it.

Sometimes it is a triumph. Sometimes it is a complaint. AI wrote something brilliant. AI made something up. AI could not do the job. AI is going to do everybody's job.

And I keep wanting to ask the same question.

Which AI?

Imagine telling somebody, I used a human. Absolutely brilliant. You should get one.

For what? Fitting the boiler? Reviewing the accounts? Writing a play? Performing surgery?

We would immediately want to know rather more about the human.

I think we need a little of that same curiosity when we talk about AI.

AI is a category, not a colleague

People have different skills, experience and strengths. Being excellent at one job does not automatically make somebody excellent at another.

The analogy is useful up to a point. AI systems are not people, and I am not suggesting that they learn, understand or carry professional responsibility in the same way. But treating an enormous category as one interchangeable worker is not helping us.

Nor are the words we use all describing the same layer:

  • Machine learning describes methods for learning patterns from data, including making predictions or generating content.
  • Neural networks are a family of model architectures used within machine learning. A large language model is not an alternative to a neural network; it is built using neural-network techniques.
  • Language, image, speech and robotics applications concern different kinds of input, output or work. One system may span several of them.
  • An agent harness is the surrounding software that organises model calls, tools, context, permissions and the work being attempted. It is not simply another name for the underlying model.

Google's introduction to machine learning and its language-model explanation are useful starting points for the model distinctions. Anthropic's engineering guide describes how retrieval, tools, memory and workflows can sit around an LLM. These are educational and vendor engineering sources, not evidence that a particular product is best.

A calculator, a permissions check or a search index in that wider system may be ordinary software. Calling the whole thing AI does not mean every part is a model.

And calling something a judgement engine does not tell me how its judgement is produced or tested. I would still want to look underneath the label.

Even the same model is not the same setup

Imagine asking a model to check a supplier's proposal.

In one case, it gets a paragraph and a vague instruction to tell you whether the deal is good.

In another, it gets the proposal, your actual requirements, the budget, the contract terms, relevant source documents and an instruction to flag what it cannot establish. It can use a calculator, but cannot send an acceptance or change a record.

Those are different working arrangements. A different result would not, by itself, tell us that the underlying model had become more intelligent.

There is research behind taking the setup seriously. In Lost in the Middle, published in TACL in 2024, Liu and colleagues found that moving relevant information within a long input could substantially change performance on question-answering and retrieval tasks. Information in the middle was often used less effectively than information near the beginning or end.

That concerns the models and tasks tested, not a universal ranking of today's systems. The useful lesson is narrower: having the information available and using it reliably are different things.

The 2024 SWE-agent research version also tested changes to the interface a coding agent used. Tests using a GPT-4 setup on SWE-bench Lite, a set of software-repair tasks, found that choices around editing, search and file viewing affected success. That is evidence about one coding benchmark, not proof that every agent becomes reliable with a better wrapper.

Still, it is a good reason to ask about more than the name on the model selector.

The work around the AI is work

People sometimes ask why the things I am doing seem to work when their own experience has been full of hallucinations or wrong turns.

Part of my answer is that I have spent a huge amount of time on the setup. The rules. The context. What the system is allowed to do. What it should stop and ask about. How the work is checked.

You see the useful result. You do not necessarily see all the work that went into getting there.

That is my experience, not a controlled experiment or a promise that my agents never get things wrong. They do.

It is also not an excuse to blame every disappointed user for failing to find the magic prompt. Sometimes the model is not capable enough. Sometimes the product is badly designed. Sometimes the task is unsuitable or the information simply does not exist.

Better context is not a cure for every limitation. More context is not automatically better context.

Anthropic's September 2025 context-engineering article treats managing instructions, tools, external data and conversation history as an engineering job. I find that a useful description of the work, while recognising that it is the vendor's guidance rather than independent proof of my results.

We do not expect human specialists to arrive unprepared

Think about how seriously we take preparation for human work.

Here are a few UK examples, checked on 20 October 2026. These are selected formal routes, not a universal stopwatch for becoming competent. They exclude earlier schooling, and qualifications do not mean somebody has finished learning.

Examples of formal professional preparation, not AI-equivalence claims
Role or routeWhat the preparation involves
GPOn a standard route: a five-year medical degree, two-year foundation programme and three years of GP specialty training. About ten years on that route. Graduate entry and other routes differ. National Careers Service.
VetA veterinary degree commonly lasts five or six years. Accelerated graduate-entry routes also exist; specialist development can come later. RCVS role guidance and entry routes.
ElectricianEngland's installation-and-maintenance apprenticeship, ST0152 v1.2: typically 54 months (four-and-a-half years) of training, plus a typical six-month end-point assessment period. These are typical periods, not guaranteed minimum durations. Skills England.
Chartered accountantICAEW says the ACA usually takes three to five years, including exams and at least 450 days of professional experience alongside study. That experience is not an extra 450 days added afterwards. ICAEW.
TeacherEngland postgraduate example: with an existing degree, teacher training usually takes nine months full-time. Statutory induction normally adds two school years full-time-equivalent for those required to complete it. That is supported professional work after initial qualification, not two years of being unqualified. DfE training; induction guidance.

I am not arguing that an agent needs ten years of calendar time before it can help. The model already comes with substantial training, and a narrow automated task can be useful without recreating a human career.

I am asking why we sometimes skip the equivalent questions about its working arrangement. What is it prepared for? What has been tested? What can it do independently? Where does somebody qualified need to check?

A fluent answer about medicine does not confer medical qualifications. Calling an agent your accountant does not make it an ICAEW member. The analogy stops well short of professional status, human learning or legal responsibility.

And what do we mean by training an agent?

There is another word worth being careful with.

When I give an agent instructions, examples and access to the right documents, I may casually call that training. Technically, I may be configuring a workflow or supplying context to an already trained model.

Adding an instruction at runtime is not, in itself, fine-tuning. Google's explanation distinguishes prompt-based guidance, which uses the existing model without changing its parameters, from additional training that changes them. Parameters are the model's learned numerical settings.

Similarly, keeping a note for the next run does not, by itself, mean that the underlying model has acquired a new skill. The system may simply retrieve that note later.

That can still be enormously useful. It just helps to know which thing we have actually changed.

A small piece of AI etiquette

I am not asking everybody to deliver a machine-learning lecture before recommending a tool.

I used AI is a perfectly reasonable beginning. It is a rather incomplete ending if you want somebody to learn from the experience.

Here is the little reporting habit I would suggest:

  1. Which system? Product, model and version if known. Say if the app selected a model and did not tell you which.
  2. For what task? Drafting a reply is not the same as autonomously negotiating a contract.
  3. With what information? A blank conversation, selected documents, retrieved sources or company context? Describe it without disclosing private material.
  4. With which tools and limits? Could it search, calculate, read files or act? What settings, instructions, permissions and budget mattered?
  5. How was it checked? A good-looking draft, verified sources, tests, a qualified review or a confirmed outcome? What failed or remains unknown?

For example, instead of AI sorted out our supplier selection, I would find this more useful:

I used a language model in our research workflow to compare three supplier proposals against agreed requirements. It had the proposals and current source documents, could search and calculate, and could not contact suppliers. I checked the important claims. We still need to make the decision.

That is an illustrative example, not a report of a completed project.

Five connected reporting questions: which system, for what task, with what information, with which tools and limits, and how was it checked? A proposed habit, not a reliability guarantee.
A small reporting habit: name the system, task, context, tools and checks. Unknowns are useful information too; private material need not be disclosed.

You do not need to know a proprietary model's entire training history. The provider does not disclose that or I do not know which model the app used is an honest and useful answer. Nobody should need privileged technical access before their experience counts.

The same courtesy applies to failure. Show what you tried, where it went wrong and what harm or extra work it caused. That is more useful than dismissing either the whole technology or the person who used it.

Less mystique, more useful conversations

NIST's 2024 generative-AI risk profile explicitly cautions against extrapolating capabilities from narrow, non-systematic anecdotes and recommends verifying sources and citations. It is risk-management guidance, not a guarantee that a particular process is safe.

For me, that cuts both ways. One impressive demonstration does not prove that everything is solved. One poor answer does not tell us that every model, tool and application will fail in the same way.

None of this asks us to tolerate unsafe products or explain away repeated failures. It asks us to make the claim precise enough to investigate.

In this AI Etiquette series, I have been thinking about what we owe the person on the other end of an AI-assisted interaction. One of those things, I think, is a description they can actually use.

Not I used a human. You should get one.

Which AI, doing what, with what context, and checked how?

Then we can have a useful conversation.

Sources and notes

Checked on 20 October 2026. My experience of building agent workflows is personal experience. The reporting checklist, supplier example and analogy are proposals, not measured interventions or claims that people and AI learn alike. The profession examples describe selected UK/England routes, not universal minimum times to competence or career advice for every applicant.