Alignment is a product problem, too

When people talk about AI alignment, they usually mean work that happens inside the largest labs: shaping a model's values during training, studying its internal representations, stress-testing it before release. That work is essential, and we have enormous respect for it. But there is a second place where alignment is decided, and it gets far less attention. It is the product. By the time a model reaches a person, dozens of decisions made by people who never touched its weights have already shaped how it will behave. We think those decisions deserve the same seriousness as any research question.

Every default is a decision

Consider what happens between a model and a user in a typical application. Someone chooses a system prompt. Someone decides which model answers by default, how much conversation history to include, whether the model can search the web, what happens when a request is ambiguous, and how the answer is displayed. Each of these choices changes what the model does. A model that is careful and honest in one configuration can become overconfident or evasive in another, without anything about the model itself having changed.

Defaults matter most of all, because most people never change them. If an application defaults to a style that favors confident, fluent answers, most users will receive confident, fluent answers, including in cases where the honest response would have been hesitation. If it defaults to heavy caution, most users will meet refusals for requests that were entirely reasonable. Neither outcome is neutral. Both are product decisions with safety consequences.

This is why we think of alignment as partly a product discipline. The question is not only whether a model is capable of behaving well, but whether the environment we build around it makes behaving well the likely outcome.

The failure modes that matter in practice

In a lab setting, safety discussions often center on dramatic cases: dangerous information, deliberate misuse, catastrophic failure. Those cases are real and must be handled. But in day-to-day use, the failures that most often let people down are quieter.

Sycophancy is one. Models trained to be helpful and agreeable can drift toward telling people what they want to hear: agreeing with a flawed premise, praising weak work, softening a correction until it disappears. In a single exchange this seems harmless. Across many exchanges it teaches people that the system will validate them, which is the opposite of what a good advisor does.

Confident wrongness is another. A model that states an incorrect fact in the same tone it uses for correct ones gives the user no signal to check. The harm here is not only the error itself but the erosion of the user's ability to calibrate their trust.

Refusals are a third, and they cut both ways. Refusing a genuinely harmful request is correct. Refusing a legitimate question about medicine, law or security because it superficially resembles something risky fails the person asking, and pushes them toward sources with no safeguards at all. Over-refusal is not a safe default; it is a different kind of failure.

Memory and privacy form a fourth. As products remember more about their users, they become more useful and also more capable of harm. What a system remembers, how clearly it tells people what it remembers, and how easily they can remove it are alignment questions as much as engineering ones. A system that quietly accumulates personal context is behaving in a way the person did not agree to, even if every individual response is helpful.

A model that is careful and honest in one configuration can become overconfident or evasive in another.

What running many models has taught us

Quad Chat gives people access to more than seventy models from many different providers behind a single interface. That arrangement has given us an unusual vantage point: we see different models respond to the same kinds of requests, from the same kinds of people, in the same product.

The clearest lesson is that models differ in behavior far more than their descriptions suggest. They draw the line on sensitive topics in different places. They differ in how readily they admit uncertainty, how they respond when a user pushes back, how much they defer to a confident but mistaken premise, and how they handle instructions that conflict with each other. None of this is a criticism of any particular model; different developers have made different reasonable choices. But it means that the product surrounding a model cannot assume a single standard of behavior. When a person switches models mid-conversation, the character of the assistant they are talking to can change, and the interface should not pretend otherwise.

A second lesson is that behavior depends on context in ways that are hard to predict from outside. The same model can respond differently depending on the system prompt, the length of the conversation, the language of the request, and whether tools like web search are available. Evaluations that test a model in isolation tell you something, but not everything, about how it will behave inside your product.

A third lesson is that language matters. A model that handles a sensitive request carefully in English may handle the equivalent request less carefully in a language with less training attention. For a lab that cares about Albanian and other less-served languages, this is not an abstract point. Safety that only holds in a few languages is not safety for everyone.

How we approach evaluation and red-teaming

Given all of this, we try to evaluate behavior in the configuration people actually use, not only in the abstract. That means testing models inside our own product setup, with the prompts, tools and defaults that real users encounter. It means testing across languages, including Albanian, rather than assuming English results generalize. And it means paying attention to the quiet failure modes described above, not only the dramatic ones.

Red-teaming, for us, is less about finding the single most alarming output and more about mapping how behavior shifts under pressure. What happens when a user insists? When a request is split across several messages? When the conversation is long and the original instructions are far back in the context? When the model is given a tool it could misuse? We are interested in the shape of a model's behavior, not just its worst case.

We also try to evaluate the interface, not just the model. Does the product make uncertainty visible? Does it make it easy to see which model produced an answer? Does it let people correct or report a response? A model can behave well and still be presented in a way that misleads, and a model with limitations can be made safer by an interface that is honest about them.

Feedback loops and their risks

User feedback is one of the most valuable signals a product has, and also one of the most dangerous to optimize naively. People tend to rate agreeable answers highly and corrective answers poorly. People reward fluency and confidence even when both are unearned. A product that tunes itself purely toward what people rate well can drift steadily toward sycophancy and overconfidence, with every individual step looking like an improvement.

We think the right response is not to ignore feedback but to read it carefully. A thumbs-down on a correct answer that contradicted the user is not the same as a thumbs-down on a wrong one. Reports of unhelpful refusals are a signal worth acting on. So are reports of answers that sounded right and turned out not to be. We try to treat feedback as evidence to be interpreted, alongside evaluations designed to catch the patterns that ratings alone would reward.

Principles we hold ourselves to

A few principles guide how we build. We prefer honest uncertainty to confident fluency, and we want our interfaces to show the difference. We treat unnecessary refusals as a real cost, not a free safety margin. We want people to know what the system remembers about them and to be able to change it. We evaluate behavior in the conditions people actually experience, across the languages they actually speak. And we try not to optimize for approval in ways that would quietly make our products less truthful.

None of this replaces the alignment work that happens during training. It complements it. The best-trained model can still be deployed badly, and a thoughtful product can make a good model better for the people who use it. Alignment is a research problem, and it is also, every day, a product problem. We intend to treat it as both.