Topic 35

Every AI Feature Is a Request

Concept

Something changed in the week after Milo turned his laptop around, and it was not the software.

The airline's support chat, which Tessa has used twice a season for years, stopped being a support chat. The CRM's suggest-a-reply button, which appeared in the spring and felt like a small miracle, stopped being a miracle. The booking system announced a summarize button on every enquiry thread, and instead of wondering how it worked she found herself wondering what it sends.

Because that is what all three of them are. An AI feature is a program that fills in the request from the last chapter and dresses up the answer. Not a smaller model tucked inside the product. Not a private arrangement with something clever. The same message list, the same two settings riding along, the same reply with a token receipt attached — built by somebody else's code and carrying somebody else's key.

This page re-introduces the products Tessa already uses, from underneath.

Every AI feature, every vendor, no exceptions
Gathermaterial you never see it collect
Buildstanding instructions · the material · what you typed
Sendone ordinary request over the internet
Shapea bubble, a suggested paragraph, three bullets

The Anatomy of a Feature

Four steps, in order. Every AI feature, every vendor, no exceptions.

Gather. The program collects the material the answer will depend on: the support ticket plus your last three bookings, the document you have open, the twelve emails above the reply box. You never see this step, and it decides almost everything.

Build. It assembles the request — standing instructions about how to behave, then the gathered material, then whatever you typed — as the list of messages Tessa read line by line in Chapter 7.

Send. It makes the call over the internet with the product company's key attached, and waits. Everything from the last chapter applies unchanged: the status code, the rate limit, the timeout, the retry that is never free.

Shape. It pulls the reply out of the response and puts it on screen as something that looks like a feature — a chat bubble, a suggested paragraph in the drafting pane, three bullet points at the top of a thread.

Notice how little of that is model. One step out of four involves the provider at all; the other three are ordinary programming of the kind that has been going on for fifty years. Which is the first useful correction this page makes: most of what makes an AI feature good or bad was written by the vendor, not by the model.

Take the airline's support bot through the four steps and it comes apart in about a minute. Tessa types "where is my refund". The program gathers: her account, her recent bookings, the two support tickets she has open. It builds a request whose first message says something like you are the assistant for an airline, answer only about bookings and refunds, be brief, never promise a date, followed by her booking history, followed by her question. It sends. The answer comes back as one message, and the bot renders it in a bubble with the airline's typeface around it.

Nothing in that description needed a new idea. Tessa has met every part of it in the last four chapters, and the only thing she was missing was permission to believe that a real product is this plain underneath.

Where the Differences Live

If the machinery is identical everywhere, then products cannot differ in the machinery. They differ in two places, and both are choices made by people at the vendor.

The first is what they gather. The support bot puts your order history in the payload. The writing aid puts the document you are editing. The summarize button puts the whole email thread. That single decision — what goes in front of the model — is the difference between an assistant that knows your booking reference and one that asks you for it.

The second is what they instruct. Two products can gather the identical material and give completely different standing orders about what to do with it: be brief, refuse anything off-topic, always answer in three bullets, never quote a price. That is the next page's subject, and it deserves its own.

Put those together and you get the sentence that changes how Tessa reads a demo. Feature quality is mostly payload quality. The vendor's real work is Chapter 2's context habit, done by a program, thousands of times an hour, for people who will never know it happened.

There is a street market near Waymark's office where a dozen food stalls sell lunch, and for years Tessa assumed they were a dozen different kitchens. Then she was in early one morning and watched the same wholesale truck stop at all of them. Same vegetables, same bread, same fish, unloaded down the row. It did not make the stalls identical — one buys the good end of the box, one seasons like somebody's grandmother, one is cheap and knows it. What it did was change what she compares. Not the ingredients. What each one chooses, and what it does with them.

Whose Key, Whose Bill

One question from the last chapter now has an interesting answer. If every feature sends a request, and every request carries a key, and every key belongs to somebody's account — whose account is Tessa spending when she presses the summarize button?

The vendor's. The product company holds the provider account, the product company's key goes out with every call, and the tokens land on the product company's invoice. Then that cost is folded into the price of the plan Waymark already pays.

Which means the vendor has a cost problem, and Tessa can now see it from the outside. Every AI feature has somebody at the vendor watching the same three dials from the end of Chapter 7: send less, receive less, right-size the model. Turn them too far and the feature gets thin.

So a whole class of product annoyance decodes itself. The assistant that answers in three sentences when you wanted a page: a length cap. The feature that is generous on the paid tier and clipped on the free one: the same cap, set twice. The summarize button that handles a short thread beautifully and a long one badly: gathering trimmed to keep the payload small. The queue at nine on a Monday: rate limits, met by someone else's account.

None of that is the model being moody. It is a budget, expressed as software, and Tessa can name the specific dial.

Reading Products Like Payloads

Waymark evaluates vendors two or three times a year, and Tessa has been the person in the room who nods. She is not that person any more, because she now has questions with checkable answers.

What does this feature send? Not "does it use AI" — what material does it gather and put in the request. Ask for the list. A vendor who cannot answer plainly has either not thought about it or would rather not say, and both are findings.

Where does it go? Straight to Chapter 6. The material leaves Waymark's boundary the moment it enters a payload, so the questions from that chapter apply to a vendor's feature exactly as they applied to Tessa's own pasting: what is retained, for how long, and is it used to improve anybody's model.

What happens when it is wrong? Chapter 3 did not stop applying because the text arrived inside a product. Does the feature show its sources, mark what it inferred, leave a way to check — or does it hand over a confident paragraph with a product's logo on it? Confidence with branding is still confidence.

Who checked? The last one, and the one vendors least expect. Somebody at that company decided what to gather, what to instruct, and how much output to pay for. Ask what they tested, on how many cases, and what they found.

Four questions, all of them answerable, none of them requiring Tessa to write a line of code. That is the payoff of the reveal, arriving one chapter after the reveal itself.

And there is a second payoff, quieter, which the rest of this chapter is about. If an AI feature is a template, some gathered context, two settings and a loop — then Tessa has already built three of those four things by hand. She has the template from Chapter 5, the checks from Chapter 5, and the wire from Chapter 7. What she does not have is the loop, and the loop is twenty lines long.

Common Confusions
  • "Each of these products built its own AI." Almost all of them rent the same handful of models by sending requests, exactly as Chapter 7 described. What the product built is the gathering, the instructing and the shaping — the wrapper, industrialized.
  • "The feature only sees what I type into it." It sends whatever the program was told to gather, which is routinely far more than your sentence. That is a question to ask of every vendor, and Chapter 6 is the reason it matters.
  • "AI features are a free extra on top of the plan." Their tokens are metered to the vendor and priced into what you pay. The meter did not disappear when the feature got a button; it moved to somebody else's invoice.
  • "A thin, clipped answer means a weak model." It usually means a cap set low or a payload trimmed to save money, both chosen by the vendor. The same model, generously fed, would have answered at length.
Why It Matters
  • Evaluating an AI product stops being a matter of impressions. A feature is a payload-builder, so it can be interrogated about what it builds — and a vendor meeting where somebody asks that is a different meeting.
  • It also sets up the rest of the chapter. If products are programs filling in requests, then a person with a proven template, a set of checks and a readable wire is one short program away from having one of her own.

Knowledge Check

What are the four steps behind an AI feature?

  • Gather, build, send, shape
  • Train, tune, deploy, serve
  • Design, code, test, release
  • Listen, think, store, answer

Two AI features are built on the same model and behave very differently. Where does the difference usually come from?

  • From the way each one connects to the provider over the internet
  • From what each one gathers and what it instructs the model to do
  • From a private version of the model that each vendor had adjusted
  • From how quickly each vendor's servers can return an answer

Waymark's booking system has a summarize button. Whose provider account pays for the tokens it uses?

  • Waymark's, because Waymark opened a provider account this year
  • Nobody, since the tokens are waived for features inside products
  • The booking vendor's, with the cost folded into the subscription
  • Tessa's, since the button was pressed on her computer by her

Which question tells Tessa the most about a vendor's AI feature?

  • Which model is behind it, so the answer can be compared with rivals
  • Whether the feature can be demonstrated live during the meeting
  • How fast it answers when several people use it at once
  • What material it gathers and sends off with each request

You got correct