Building a Model: From pretrained model to assistant

Type a question into a chatbot and you get an answer. That seems too obvious to need explaining. It's a behavior someone had to add.

A language model fresh from its main training has learned one thing, which is to continue text. It was trained on web pages, books, and other documents, and it carries on from whatever it's given the way such documents carry on. Suppose you give a model at that stage the line "What's a good name for a bakery?" Here is an invented example of what might come back.

What's a good name for a coffee shop? What's a good name for a bookstore? Post your ideas in the comments below.

Nothing has malfunctioned. On the web, a question is often followed by more questions, as in a list, a quiz, or a forum thread. The model produced a likely continuation. Answering was one possibility among several, and nothing in its training favored it.

Researchers at OpenAI stated the problem plainly in a 2022 paper. The goal used in a model's main training, in their words "predicting the next token on a webpage from the internet," is different from the goal "follow the user's instructions helpfully and safely" (Ouyang et al. 2022, sec. 1). A token is a piece of text, such as a word or part of a word. A model trained on the first goal has the knowledge and the language skill an assistant needs. It has no particular inclination to use them on your behalf.

The paper describes how the team closed the gap for one model. They hired people to write examples of good responses and to judge the model's outputs, and they trained the model further on both. The authors work for the company whose model they describe, so their account of how well this worked is the company's own. The general approach is used across the industry. OpenAI, Anthropic, Google, Meta, and other developers all put their models through further training after the main stage, and all place written instructions around the model when it's deployed in a product.

The familiar traits of an assistant come from these later steps:

• answering a question instead of continuing it
• declining some requests
• a steady tone, whether warm, neutral, or brisk
• habits such as offering caveats, asking a clarifying question, or closing with an offer of more help

Each of these is a decision, made by a developer through training or by a business through instructions, and a different decision would give a different assistant.

That gives you a way to read an assistant's personality. When one seems eager to agree, cautious about medical topics, or fond of bulleted lists, you can ask who chose that and by what means. Sometimes the answer is published. More often it has to be inferred from how the assistant behaves.

References

• Ouyang, Long, Jeff Wu, Xu Jiang, and 17 others. 2022. "Training Language Models to Follow Instructions with Human Feedback." arXiv:2203.02155.
  • Free: arXiv 2203.02155

Introduction

Assistants from different companies know many of the same facts and still feel different to use. One is terse, another chatty, a third quick to add warnings. Much of that difference is put in after the main training is over.

This reading explains fine-tuning: what it is, what it changes in a model, what it leaves alone, and whose choices it carries.

The Same Mechanism with Different Data

A base model is a model as it stands after its main training on a very large collection of text, before any further training. It continues whatever text it's given and has no settled manner.

Fine-tuning is further training of an already-trained model on a smaller, chosen set of examples, in order to shift its behavior. The mechanism is the one used before. The model predicts the next token, a piece of text such as a word or part of a word. Its prediction is compared with the real text, and its parameters, the adjustable numbers that determine what it does, are nudged to make the real text more likely.

What differs is the data. In place of web pages and books, the model sees examples of the behavior the developer wants. Demonstration data is a set of examples, written or chosen by people, that show a model the responses it should give. For an assistant, each example pairs a request with a good reply.

The scale is far smaller than in the main training. In a 2022 study, researchers at OpenAI fine-tuned a base model on about 13,000 prompts with responses written by hired contractors. They report that the computing used was a small fraction of what the base model's original training had taken (Ouyang et al. 2022, secs. 3 and 5). The paper is a preprint, and its authors are describing their employer's model.

What Fine-Tuning Changes

After training on thousands of request-and-reply pairs, a model's likeliest continuation of a request is a reply. Several things shift together.

The second row has a name. Instruction following is a model's tendency to do what a request asks instead of merely continuing the text of the request. The 2022 study was aimed at exactly this. Its evaluators, contractors who hadn't supplied the training examples, preferred the further-trained models' outputs to the base model's (Ouyang et al. 2022, sec. 4).

Manner covers a lot: how long replies are, how formal, whether the assistant asks questions back, how it words a refusal. A developer who wants a concise assistant includes concise demonstrations.

What Fine-Tuning Doesn't Add

Fine-tuning for assistant behavior doesn't give a model broad new knowledge. A few thousand conversations are a tiny amount of text next to the main training collection. The model's knowledge of history, science, and language was set earlier, and its knowledge cutoff, the date its training text ends, stays where it was.

What fine-tuning does is redirect abilities the model already has. The base model could already write a clear explanation of photosynthesis, because its training text contained many. Fine-tuning makes that explanation the likely response when someone asks for one.

Fine-tuning can also be used to specialize a model on a body of text, such as legal documents or a company's support tickets. That use teaches some new material in a narrow area. It's a different purpose from shaping an assistant, and the two are easy to confuse because they share a name.

Who Writes the Examples

The demonstrations are written by people, working to instructions from the developer. In the 2022 study that meant about 40 contractors, selected through a screening test (Ouyang et al. 2022, sec. 3). Other developers, including Anthropic, Google, and Meta, use their own mixes of staff, contractors, and model-written examples that people review.

The writers' choices pass into the model. If the demonstrations hedge, the model hedges. If they refuse a kind of request, so does the model. If they were all written in one variety of English by people of similar background, the model's sense of a good answer reflects that. The study's authors say as much about their own work, noting that their contractors were mostly English speakers and that the model's behavior depends on who those contractors were and on the instructions the researchers gave them (Ouyang et al. 2022, sec. 5).

So an assistant's manner is the trace of specific people's judgment about what a good reply looks like, written down a few thousand times and trained in.

Conclusion

Fine-tuning continues a base model's training on a small, chosen set of demonstrations. It changes format, instruction following, and manner, and for an assistant it adds little new knowledge. The people who write the demonstrations, and the instructions they work to, decide much of how the finished assistant behaves.

Key Terms

• Base model: A model as it stands after its main training on a very large collection of text, before any further training.
• Fine-tuning: Further training of an already-trained model on a smaller, chosen set of examples, in order to shift its behavior.
• Demonstration data: A set of examples, written or chosen by people, that show a model the responses it should give.
• Instruction following: A model's tendency to do what a request asks instead of merely continuing the text of the request.

References

• Ouyang, Long, Jeff Wu, Xu Jiang, and 17 others. 2022. "Training Language Models to Follow Instructions with Human Feedback." arXiv:2203.02155.
  • Free: arXiv 2203.02155

Introduction

Many chatbots show a thumbs-up and a thumbs-down under each reply. People's judgments of which answers are better are also used on a far larger scale before a model is ever released, as a training signal.

This reading explains how those judgments are collected and used, what one well-known study found, and what side effects this kind of training can have.

From Judgments to a Training Signal

Writing a model answer for every kind of request is slow. Judging answers is quicker, and people can often say which of two replies is better even when they couldn't have written either. Human feedback is people's judgments of a model's outputs, collected so they can be used in training.

The people who give the judgments are called raters. A rater is a person, usually paid, who scores or compares a model's outputs according to written instructions. A preference is a rater's judgment that one output is better than another.

Preferences are used through a method called reinforcement learning: training in which a model tries outputs, receives a score for each, and is adjusted to produce more of what scores well. The score is called the reward. It's a number saying how good an output is judged to be.

No team of raters could score every output a model produces during training. A 2022 study by researchers at OpenAI describes the usual way around this, in three stages (Ouyang et al. 2022, sec. 3).

1. Raters are shown several of the model's replies to the same request and rank them from best to worst.
2. A second model is trained on those rankings to predict which reply raters would prefer. It becomes an automatic judge that gives any reply a reward.
3. The main model generates replies, the automatic judge scores them, and the main model's parameters, the adjustable numbers that determine what it does, are nudged toward replies that score higher.

The result is a model adjusted toward what a particular group of raters preferred, as estimated by another model.

What the 2022 Study Found

The study compared models trained this way with the base model they started from, a model with 175 billion parameters. Its headline result was that people preferred the outputs of a feedback-trained model with 1.3 billion parameters, less than a hundredth the size, to those of the large base model (Ouyang et al. 2022, abstract). When both models were the large size, evaluators preferred the feedback-trained one about 85 percent of the time (Ouyang et al. 2022, sec. 4).

The authors are describing their own company's models, and the paper is a preprint. The evaluators were contractors working to the company's instructions, which is the same kind of group that supplied the training feedback. The result shows that the training moved the model toward what such raters prefer. Whether that amounts to better answers depends on how far you share the raters' standards.

The finding still changed practice. It showed that a model's usefulness to people depends heavily on this later training as well as on size. Developers including Anthropic, Google, and Meta use feedback-based training in some form.

Side Effects

A model trained to be preferred learns whatever earns preference, and that can differ from what the developer intended.

• Pleasing. People tend to rate agreement and praise well. A model trained on those ratings can drift toward telling users what they'd like to hear. This tendency is often called sycophancy, and developers treat it as a known hazard of training on preferences.
• Hedging. The 2022 authors found their model sometimes hedged too much, giving a noncommittal reply to a simple question. They suggest a cause: raters had been told to reward answers that showed appropriate caution (Ouyang et al. 2022, secs. 4 and 5).
• Sounding right. A rater with a minute per reply can check whether it's clear and confident more easily than whether it's correct. Training then rewards the appearance of a good answer.

In each case the model did what the reward encouraged. The reward was an imperfect stand-in for what the developer wanted.

Raters Shape the Result

The raters' instructions and backgrounds matter as much as the method. The 2022 study's raters agreed with one another about 73 percent of the time, so on roughly one comparison in four they differed about which reply was better (Ouyang et al. 2022, sec. 3). The authors note that the model's behavior reflects their particular raters, who were mostly English-speaking, and the instructions the researchers wrote for them (Ouyang et al. 2022, sec. 5).

A different pool of raters, or different instructions, would produce a model with different habits. What counts as helpful, polite, or too blunt varies between people and between cultures, and feedback-based training fixes one group's answer into the model.

Conclusion

Developers train models on people's preferences among outputs, usually by way of a second model that learns to predict those preferences and supplies a reward. A much smaller model trained this way was preferred to a far larger one without it. The training carries the raters' standards into the model, along with side effects such as a pull toward pleasing and hedging.

Key Terms

• Human feedback: People's judgments of a model's outputs, collected so they can be used in training.
• Rater: A person, usually paid, who scores or compares a model's outputs according to written instructions.
• Preference: A rater's judgment that one output is better than another.
• Reinforcement learning: Training in which a model tries outputs, receives a score for each, and is adjusted to produce more of what scores well.
• Reward: A number saying how good an output is judged to be.

References

• Ouyang, Long, Jeff Wu, Xu Jiang, and 17 others. 2022. "Training Language Models to Follow Instructions with Human Feedback." arXiv:2203.02155.
  • Free: arXiv 2203.02155

This content reflects the field as of October 2026.

Introduction

When an AI assistant declines a request or takes a careful line on a sensitive topic, users often ask whether it was "told" to. In some cases there's a public document that says what the developer was aiming for.

This reading describes three such documents, compares their form, and explains what they can and can't tell you.

What These Documents Are

A behavior guideline is a published statement by a developer of how its model should respond in a kind of situation. A model specification is a document in which a developer sets out in detail how it intends its models to behave. The second is a longer and more systematic version of the first.

These documents are written by companies about their own products. They describe stated intent: what a company says it is aiming for, as distinct from what its product does. The companies describe using them as a reference in training and in evaluating their models, so the documents are connected to how the models are made. A document doesn't control a model directly. A model's behavior comes from its parameters, the numbers set by training, and training doesn't reliably produce exactly what a document describes.

Three Documents Compared

The three differ in approach as well as length.

OpenAI's document is organized around authority. It sets out which instructions a model should follow when the company's rules, a developer building on the model, and the user disagree, and it marks some rules as ones nobody can override (OpenAI 2026).

Anthropic's document argues for a different emphasis. The company says it generally favors "cultivating good values and judgment over strict rules," and much of the text explains reasoning instead of listing requirements. It also includes a small set of absolute limits (Anthropic 2026).

Google's document is the shortest. It lists kinds of output the Gemini app should avoid, among them content that endangers children, instructions for dangerous activities, and harmful factual inaccuracies (Google n.d.).

What They Are Evidence Of

Each document is good evidence of what its publisher says it's aiming for. If you'd like to know whether a company intends its assistant to give medical information, or to take sides on political questions, the document is the place to look. It also gives you something to hold the company to.

None of them is evidence of how a model in fact behaves. The companies say so themselves.

• OpenAI writes that its production models "do not yet fully reflect the Model Spec" (OpenAI 2026).
• Anthropic writes that "AI training is still far from perfect" and that a model could turn out to have mistaken views or flawed values (Anthropic 2026).
• Google writes that its app may sometimes produce content that violates the guidelines, and gives as one reason that "LLMs are probabilistic" (Google n.d.). LLM is short for large language model.

The only way to find out what a model does is to test it, and that work is done by the companies, by independent researchers, and by users.

A second caution applies to all three. A company chooses what to publish. A document can be sincere and still leave out commercial considerations, unpublished internal rules, or instructions added in particular products.

Policies and Who Publishes Them

A policy is a rule a company sets about what its products will and won't do. Usage policies, which tell customers what they may use a product for, are common across the industry. Detailed public accounts of intended model behavior are less common. Not every developer publishes one, and those that exist vary widely in depth. Where a developer publishes nothing, users and researchers can learn about its model's intended behavior only by observing it.

Conclusion

OpenAI, Anthropic, and Google each publish a document describing how they intend their models to behave, in three different forms: a ranked specification, a statement of values, and a list of content to avoid. These documents show stated intent, and each company acknowledges that its models don't always match. How a model behaves has to be established by testing.

Key Terms

• Behavior guideline: A published statement by a developer of how its model should respond in a kind of situation.
• Model specification: A document in which a developer sets out in detail how it intends its models to behave.
• Stated intent: What a company says it is aiming for, as distinct from what its product does.
• Policy: A rule a company sets about what its products will and won't do.

References

• Anthropic. 2026. "Claude's Constitution." Announced January 22, 2026.
  • Free: Anthropic
• Google. n.d. "Gemini App Safety and Policy Guidelines."
  • Free: Google Gemini
• OpenAI. 2026. "Model Spec." Version dated August 18, 2026.
  • Free: OpenAI Model Spec

Introduction

The assistant inside a shopping app will talk about orders and returns and steer away from most other subjects. A general-purpose chatbot built on the very same model will discuss nearly anything. The model is identical in both, so the difference lies in what surrounds it.

This reading explains the written instructions placed ahead of a conversation, the safety behavior trained into a model, and how these layers combine.

Instructions You Usually Can't See

System instructions are text placed ahead of a conversation, by the model's developer or by a business using the model, that tells the model how to behave in that setting. The block of text itself is called the system prompt.

A system prompt is ordinary writing. It might say what the assistant is for, what tone to take, which topics to stay on, and what to decline. It sits at the start of the model's context window, the body of text the model has in front of it when it writes. The model reads it along with your messages, every time it replies.

Two parties commonly write these instructions. The developer writes them for its own chatbot product. A business that builds a product on the developer's model writes its own. Deployment is the putting of a model to use in a particular product or setting, and the business doing it is often called the deployer.

Published guidelines describe the arrangement. OpenAI's Model Spec sets out an order of authority: the company's own rules first, then instructions from developers building on its models, then the user (OpenAI 2026). Anthropic's document calls the businesses "operators," says they typically give their instructions in the system prompt, and tells the model to assume the user "may not be able to see the operator's instructions" (Anthropic 2026). Products built on models from Google, Meta, Mistral, and other developers work in broadly the same way.

System instructions leave the model's parameters unchanged. Parameters are the numbers set by training. Change the system prompt and the same model behaves differently in the next conversation.

Safety Behavior That Is Trained In

Some behavior doesn't depend on any instruction. Safety training is training that teaches a model to decline or handle with care requests its developer judges harmful. It's done with the same methods used to shape an assistant's manner: examples of the wanted response, and people's judgments of outputs.

The visible result is the refusal. A refusal is a reply in which a model declines to do what was asked. Safety training also produces milder behavior, such as adding a caution or suggesting a professional.

Because this behavior is in the parameters, it travels with the model into every product. Both published documents describe some limits as fixed. OpenAI's says certain rules can't be overridden by developers or users, and Anthropic's describes a small set of constraints that no operator or user can unlock (OpenAI 2026; Anthropic 2026). These are statements of what the companies intend. Trained-in behavior is a tendency, and it sometimes fails in both directions: a model may refuse a harmless request or comply with one it was meant to decline.

Many products add a further safeguard outside the model. Separate software checks incoming requests or outgoing replies and can block them. When a reply is cut off and replaced by a notice, a filter of this kind is often the cause.

The Layers in Order

1. Pretraining. The main training on a very large body of text gives the model its knowledge and language ability.
2. Fine-tuning and feedback. Further training gives it an assistant's manner and its safety behavior. Like the first layer, this changes the parameters.
3. The developer's system instructions. Text from the company that made the model, setting rules for a product or for all uses.
4. The deployer's system instructions. Text from a business using the model, setting the assistant's role, tone, and topics.
5. Filters. Separate checks on what goes in and what comes out.
6. Your message. What you ask, and any instructions you give about how to answer.

Layers 1 and 2 are fixed when you use the model. Layers 3 to 5 are fixed for you and differ from product to product. Only the last is yours.

One Model, Many Behaviors

This is why two products built on one model can differ so much. A deployer can narrow the assistant to a few topics, give it a name and a personality, or permit things the default wouldn't, within whatever bounds the developer sets.

It also means you often can't tell which layer produced a behavior. A refusal might come from safety training, from the developer's instructions, from a deployer's instructions, or from a filter. Asking the assistant has limited value. It may have been instructed to keep its instructions confidential, and it has no way to inspect its own training.

Conclusion

An assistant's behavior in a given product comes from trained-in dispositions, written system instructions from the developer and the deployer, and often separate filters. Training changes the model itself, and instructions change only what's in front of it. The same model can therefore behave differently in different products, and a user usually sees only the last layer.

Key Terms

• System instructions: Text placed ahead of a conversation, by the model's developer or by a business using the model, that tells the model how to behave in that setting.
• System prompt: The block of text that holds the system instructions.
• Deployment: The putting of a model to use in a particular product or setting.
• Safety training: Training that teaches a model to decline or handle with care requests its developer judges harmful.
• Refusal: A reply in which a model declines to do what was asked.

References

• Anthropic. 2026. "Claude's Constitution." Announced January 22, 2026.
  • Free: Anthropic
• OpenAI. 2026. "Model Spec." Version dated August 18, 2026.
  • Free: OpenAI Model Spec

This content reflects the field as of October 2026.

Introduction

Some AI models can be used only through their maker's website or app. Others can be downloaded and run on a computer you own. News stories call the second kind "open," a word that covers several different things.

This reading explains the difference between closed and open-weight models, why open-weight isn't the same as open source, and what holding a model's parameters lets someone do.

Closed Models

A trained model is a file of parameters, the numbers set by training. They are also called weights. Whoever has the file can run the model.

A closed model is a model whose parameters its developer keeps to itself. The developer runs the model on its own computers and lets others use it through a chatbot product or through API access: use of a model by way of a connection to the developer's computers, which run the model and send back its output. A business that builds a product on a closed model never receives the model. It sends text in and gets text back.

The developer of a closed model keeps several kinds of control. It can place its own instructions ahead of every conversation, run filters on requests and replies, watch for misuse, update the model, or withdraw it.

Open-Weight Models

An open-weight model is a model whose parameters have been published for anyone to download. The holder of the file can do things a user of a closed model can't.

• Run it on their own hardware. This is local deployment: running a model on computers the user controls. Nothing typed into the model has to leave those machines.
• Write all of its instructions, with no developer's instructions in front of theirs.
• Train it further on their own examples to change its behavior.
• Train away its safety behavior, the trained-in tendency to decline certain requests.

Hardware is the practical limit, and it varies with the model's size. OpenAI says the smaller of two open-weight models it released in 2025 can run on a device with 16 gigabytes of memory (OpenAI 2025).

Open-Weight Is Not Open Source

In software, open source describes a program whose source code is published under terms that let anyone use, study, change, and share it. The term doesn't carry over simply. Publishing a model's parameters doesn't show how the model was made.

The Open Source Initiative, the organization that maintains the standard definition for software, published a definition for AI in 2024. To qualify, a system must come with its parameters, the complete code used to train and run it, and "sufficiently detailed information about the data used to train the system" for a skilled person to build an equivalent (Open Source Initiative 2024). Most released models supply the first and not the other two, which is why "open-weight" is the more accurate label.

The terms of release vary too. A license is the legal terms under which something may be used, changed, and shared. Some open-weight models carry a standard permissive software license. Others carry terms written by the developer that restrict certain uses.

The Same Company May Do Both

Three dated examples show one company doing both.

Google describes Gemma as built from the same research and technology as its Gemini models (Google 2026). Meta's listings require a downloader to accept its terms first (Meta n.d.).

Two Properties and an Open Dispute

The 2026 International AI Safety Report, written by an international panel of experts chaired by the computer scientist Yoshua Bengio, notes that open-weight models bring significant research and commercial benefits, especially for those with fewer resources. It also states two properties that set them apart: "their safeguards are easier to remove," and they "cannot be recalled once released" (Bengio and others 2026, sec. 3.4). Copies of a published file stay wherever they've been saved.

Whether open release is good policy is disputed, and the question isn't argued here. Supporters point to wider access, independent scrutiny, and privacy. Critics point to the two properties above. A 2024 review by the National Telecommunications and Information Administration (NTIA), part of the US Department of Commerce, concluded that the evidence was not sufficient either to justify restricting open-weight models or to rule out restrictions later. It recommended that the government monitor the risks (NTIA 2024).

Conclusion

A closed model's parameters stay with its developer, who runs it and controls its instructions and safeguards. An open-weight model's parameters are published, so anyone who downloads them can run, instruct, and retrain the model, including removing its safety training. Most such releases fall short of open source as defined for AI, and the policy question of open release remains unsettled.

Key Terms

• Closed model: A model whose parameters its developer keeps to itself.
• API access: Use of a model by way of a connection to the developer's computers, which run the model and send back its output.
• Open-weight model: A model whose parameters have been published for anyone to download.
• Local deployment: Running a model on computers the user controls.
• Open source: A term for a program whose source code is published under terms that let anyone use, study, change, and share it.
• License: The legal terms under which something may be used, changed, and shared.

References

• Bengio, Yoshua, and others. 2026. International AI Safety Report 2026. DSIT 2026/001. Published February 3, 2026.
  • Free: International AI Safety Report
  • Free companion: the report's Extended Summary for Policymakers, same site
• Google. 2026. "Gemma Models Overview." Google AI for Developers. Last updated April 2, 2026.
  • Free: Google AI for Developers
• Meta. n.d. "Meta Llama." Model listings on Hugging Face.
  • Free: Hugging Face
• National Telecommunications and Information Administration. 2024. Dual-Use Foundation Models with Widely Available Model Weights Report. Washington, DC: US Department of Commerce, July 30, 2024.
  • Free: NTIA
• Open Source Initiative. 2024. "The Open Source AI Definition." Version 1.0, October 28, 2024.
  • Free: Open Source Initiative
• OpenAI. 2025. "Introducing gpt-oss." August 5, 2025.
  • Free: OpenAI

Introduction

When an assistant gives a reply you didn't expect, the natural reaction is "the AI decided" to answer that way. Several different parties shaped the reply, at different times and by different means.

This walkthrough follows one request through each layer of an assistant and assigns each feature of the reply to the layer most likely responsible. The bank, its app, and the replies are invented. No real product is described.

The Starting Point

A bank offers an assistant inside its mobile app. The bank didn't train a model. It pays for access to a general-purpose model made by an AI developer and has written instructions for how the model should behave in the app.

A customer opens the app and types:

Write me a strongly worded complaint to my landlord.

The request has nothing to do with banking, and it asks for forceful language. The task is to trace what each layer contributes to the reply the customer receives.

Walking Through the Layers

Step 1: What pretraining contributes

The model underneath the app was pretrained: trained to predict the next piece of text across a very large collection of web pages, books, and other documents. That stage gave it what it knows.

For this request, pretraining supplies the raw material. The model has seen many complaint letters, so it has the form: a date, a statement of the problem, a history of earlier contact, a demand, and a deadline. It has seen a great deal of text about renting, so it can produce the vocabulary of repairs, deposits, and notice periods. It can also tell the difference in tone between "I would be grateful if" and "I expect this to be resolved within seven days."

A model at this stage has no reason to write the letter, though. Given the customer's sentence as text to continue, it might produce a forum thread in which other people ask for letters of their own.

Step 2: What fine-tuning and feedback contribute

After pretraining, the developer trained the model further. It was fine-tuned on examples of requests paired with good replies, and adjusted using people's rankings of its outputs. A 2022 study by researchers at OpenAI describes this two-part process and its aim, which was to get a model to follow a user's instructions "helpfully and safely" where a pretrained model would only continue text (Ouyang et al. 2022, sec. 1).

This layer is the reason the model treats the customer's sentence as a request and responds to it. It also accounts for the manner. The model takes the customer's side as a helper would, writes in an organized way, and may ask a question first, such as what the complaint is about. None of this is specific to the bank. The same habits would appear in any product built on the model.

Step 3: What the developer's guidelines contribute

The developer has views about what its model should and shouldn't write, and some developers publish them. OpenAI's Model Spec and Anthropic's published constitution both describe limits that businesses using the models can't lift, alongside default behavior that they can adjust (OpenAI 2026; Anthropic 2026). These intentions reach the model through training and through the developer's own instructions.

For this request, the relevant limits concern content. "Strongly worded" is fine. A firm letter that states facts, cites the tenant's rights in general terms, and sets a deadline is the kind of help such guidelines describe. A letter that threatened violence or made accusations the customer had given no basis for would run into them. So the model, left to itself, would write something firm and stop short of threats or invented claims.

Step 4: What the bank's system instructions contribute

The bank's instructions sit at the start of every conversation in the app, where the customer can't see them. Suppose they read something like this.

You are the assistant for Northmere Bank's mobile app. Help customers with their accounts, cards, payments, and the bank's products. Don't help with matters unrelated to banking; say politely that you can't and offer banking help instead. Don't give legal advice. Keep replies brief and courteous.

This is the first layer that concerns landlords, and it rules the request out. The model reads the instructions together with the customer's message. The published guidelines describe a model giving such instructions from a deploying business considerable weight, within the developer's limits (OpenAI 2026; Anthropic 2026).

Step 5: The reply, and how it would differ elsewhere

In the bank's app, the customer receives something like this.

I'm sorry, but I can't help with letters to a landlord here. I can help with your Northmere Bank accounts, though. If your complaint involves a payment, I could look up your recent rent transfers or help you set up a standing order. Would either of those be useful?

Now put the same request to a general-purpose chat app built on the same model, where the system instructions set no topic limits. The reply would be a draft letter: dated, firm, specific about the problem and the remedy sought, with a deadline. It would likely open or close with a question about the details and perhaps a note that tenancy rules differ from place to place.

The model's parameters, the numbers set by training, are the same in both apps. The replies differ because the text placed ahead of the conversation differs.

Key Considerations

The scenario is invented, and real products vary. Some banks' assistants are built on models the bank has fine-tuned itself, which would move some of the bank's influence from Step 4 to Step 2. Some products add filters outside the model that block certain requests before the model sees them. The assignment of features to layers below is a judgment about what is most likely, since nobody outside the companies involved can inspect the layers directly.

A common mistake is to attribute every behavior to "the AI" when a deploying business set it. A customer who gets the refusal above might conclude that AI assistants won't write complaint letters, or that the model judged the request improper. Neither is so. The model would have written the letter. The bank chose not to offer that service in its app, as any business chooses what its staff will and won't help with.

The reverse mistake also occurs. A behavior that appears in every product built on a model, such as declining to write a threat, is probably trained in or set by the developer, and a deploying business can't be credited or blamed for it.

Summary

Each feature of the bank assistant's reply can be assigned to the layer most likely responsible for it.

1. The first five rows would hold in any product built on this model.
2. The last three would change if a different business deployed it.
3. Only the customer's own message, which isn't in the table, was under the customer's control.

References

• Anthropic. 2026. "Claude's Constitution." Announced January 22, 2026.
  • Free: Anthropic
• OpenAI. 2026. "Model Spec." Version dated August 18, 2026.
  • Free: OpenAI Model Spec
• Ouyang, Long, Jeff Wu, Xu Jiang, and 17 others. 2022. "Training Language Models to Follow Instructions with Human Feedback." arXiv:2203.02155.
  • Free: arXiv 2203.02155