That is the uncomfortable part of building with AI right now. Trust is the thing every AI product needs most, and it is the one thing no team can build directly. It only ever arrives as a byproduct of two things you can control.

I call it ITT.

Intentionality is your why. Transparency is your how. Trust is the result.

It shows up in that order or it does not show up at all.

The Product Version of AI Slop

AI Slop is content nobody believes in.

That definition has been floating around the writing world, and it transfers cleanly to product. AI slop in a product is a feature nobody believes in. The chat sidebar that got added because the board asked what the AI story was. The summarize button nobody on the team uses. The assistant that exists so the release notes have a paragraph about AI in them.

Nobody sets out to build that. It happens when the model comes first and the reason comes second. Someone has access to a capability, so they go looking for a place to put it. The feature ships. It works, technically. And users open it once, get something plausible and useless, and never touch it again.

That is not a model quality problem. It is an intentionality problem, and no amount of model improvement fixes it.

Intentionality

Intentionality is knowing what job the feature does before you know what technology does it.

Not the demo. The job. What is the user actually trying to get done, what does done look like to them, and what would have to be true for this to be the best way to get there. If the answer is “our competitor shipped one,” you are building AI slop, and everyone on the team already knows it.

Everyone has access to the same models. That is the defining condition of this moment. The model is table stakes. What differentiates one product from another is the harness built around it: the context it sees, the constraints it operates under, the tools it can reach, the judgment encoded in how it fails. Two teams with identical model access ship wildly different products, and the gap between them is entirely the harness.

Without intentionality, you drift to the middle. There is a strong pull toward the center of the distribution in this work, and you can watch it happen across an entire category at once. Every product gets a chat panel in the corner. Every product gets a summarize action. Every product gets a rewrite button. None of it is wrong. It is just what the average looks like when it gets rendered as a UI, and users can feel that they have seen it before, because they have.

The teams doing interesting work started somewhere else. They started with a job that was actually hard in their domain and asked what a model makes newly possible about it. That question produces something nobody else is shipping. The other question produces a sidebar.

Transparency

Intentionality is what you decided. Transparency is what you tell the user about it.

This is where most AI products are currently failing, and they are failing in ways the teams do not think count. A support chat that answers in a person’s tone and never says it is not one. A summary with no path back to the source. A confidence-free answer delivered in the same voice as a verified fact. A model swap that changes the behavior of a feature overnight with no note anywhere.

None of those are lies exactly. All of them spend trust the team did not realize it was spending.

The pattern underneath is mismatch. A user thought they were getting one thing and got another. They thought a person read their ticket. They thought the number came from their data. They thought the tool worked the way it did last week. The injury is not that AI was involved. The injury is that their expectation was quietly wrong and they found out on their own.

We are writing these norms in public right now with very little to copy from. We never needed a rule about disclosing that software answered a support message, because it was never possible. The moment it became possible, everyone discovered they had held an opinion about it all along. Same with generated summaries presented as sourced fact. Same with synthetic voices on a call. Each new capability drags an unstated expectation into the open, and the products that survive that moment are the ones that got there first and said so plainly.

The test I use is whether the behavior survives being described. If you can tell a user exactly how this works and they shrug and keep going, you are fine. If describing it plainly would make them uncomfortable, you already know what you built. Ship the description, not just the feature.

Trust

Trust is earned in small confirmations and lost in one.

Trust used to have a natural proxy in software: polish was evidence of care. If an output looked finished, a person had checked it. Fluency cost effort, so fluency meant something.

Fluency is free now. A wrong answer arrives with exactly the same confidence and formatting as a right one. That proxy is gone, and users are adjusting faster than most teams realize. They are learning to hold a low-grade question open at all times: is this real, and can I act on it without checking?

That question is the actual cost. Not the one bad output. Products survive bad outputs. What they do not survive is a user who now verifies everything, because a user who verifies everything has stopped getting value from the feature. They are doing the work twice. The feature is technically live and functionally dead.

Worse, this does not stay contained. Trust in AI features is a shared resource. When one product burns a user with a confidently wrong answer, that user arrives at your product already suspicious, and you pay for someone else’s shortcut. Their suspicion does not come labeled with the name of whoever earned it.

Which is why trust behaves asymmetrically. It accrues quietly, in the background, while nothing goes wrong. It leaves loudly, and it does not come back when the bug is fixed, because the user has already changed how they read every output you give them. And it can never be added at the end, because it is not a component. It is a residue.

Why You Need Both

I have been sharpening how the two inputs fail on their own, and the failure modes are distinct.

Intentionality without transparency produces suspicion. You built the right thing for the right reason and told nobody how it works, so users fill the silence themselves, and they do not fill it generously. Good intent that stays private is indistinguishable from bad intent.

Transparency without intentionality produces noise. A disclosure banner on a feature nobody wanted. An AI-generated label on output nobody asked for. You have been honest about something that should not exist, and honesty does not redeem it.

Trust needs both. It is the output of a product that had a real reason to exist and was willing to explain itself.

What This Costs If You Skip It

Every input in this system is getting cheaper. Model capability is getting cheaper. Generation is getting cheaper. Shipping an AI feature is getting dramatically cheaper, which is exactly why so many bad ones exist.

User patience is not getting cheaper. It does not multiply this year or next. Every AI feature you ship is a withdrawal against it, and the feature either returns more than it took or it does not.

So the bar goes up rather than down. When a user gives your AI feature a chance, it has to be worth the chance. Not more impressive. Worth it.

That is the whole framework. Intentionality is having a reason you would defend out loud. Transparency is being willing to say how it works. Trust is what those two earn you, slowly, and what a single careless release can spend on behalf of a team that never agreed to spend it.

Being against AI slop is not being against AI. It is the most pro-AI position available, because it insists these tools get pointed at something worth a user’s time.

Trust is not a feature. It is what you have left when intentionality and transparency have been doing their job for a while.

This article was written with the help of AI. The thoughts, ideas, and beliefs here are mine. I use AI as a thought partner to enhance my thinking, not to do my thinking for me.

Which tools do we buy. Who gets access. What counts as an approved use case. Fair questions. Not the ones that matter most.

You can watch the pattern play out. A company signs the enterprise deal, sends the launch email, stands up a dashboard that counts how many seats got activated. Six months later the seats are activated and the work looks exactly like it did before. The logins went out. Nothing moved.

Access doesn't create adoption. And adoption doesn't create better work.

Think about a gym membership. Buying one doesn't make anyone fit. The membership is just the door. We all know the person who has paid for a year and been twice. Most of us have been that person. Showing up, knowing what to do once you're inside, having someone to copy on the days you'd rather not: that's the part that changes anything. AI is the same. Handing out logins is the easy ten percent. Capability is the other ninety.

So the real question was never which tools. It was how you build capability across hundreds of people who already have a full day job.

That is harder than it sounds, because the barriers are human, not technical. People are busy. People are quietly worried that reaching for AI makes them look slow, or that it looks like cutting corners. A manager doesn't always know what to ask their team for. Someone earlier in their career doesn't always know what they're allowed to try. So the question becomes practical. How do you make learning visible. How do you help someone experiment without it feeling like one more thing on the pile. How do you get a manager and their reports speaking the same language about what good looks like, when good keeps moving.

Solve that, and you notice something. What you've built is not a program. Programs end. This didn't.

It started to behave like an operating system. An operating system is the layer everything else runs on. You don't notice it when it works. It just makes the useful things possible. That is what this became, and it ran on three core parts.

Learning

A standing forum where people show the thing they actually shipped last week, not a slide about AI in theory.

Picture it. Someone stands up and walks through how they turned a two-day reporting slog into a one-hour pass. Not the polished version. The real one, with the dead ends and the prompt that finally worked. The room leans in, because it's recognizable. That's their Tuesday too. Someone demoing real work beats any training deck, every time. The deck tells you it's possible. The demo shows you it's Tuesday.

And it compounds. Every demo lowers the cost of the next attempt. The person who watches this week is the person who presents next month. Learning becomes social, and social learning spreads on its own. You stop pushing it uphill.

Shared Expectations

Write down what good AI use looks like for this role, at this level.

Without that, everyone is guessing. The manager sees a report built with AI and doesn't know whether to be impressed or concerned. The person who built it doesn't know if they're ahead of the curve or about to get flagged. That uncertainty is expensive. It makes people hedge, and hedging is the opposite of experimenting.

So make it plain. What should a manager enable. What should someone earlier in their career be trying. What does competent look like here, and what does exceptional look like. When the expectation is written down, the fear drains out of it. It stops being a risk someone is taking and becomes a thing the team simply does. Ambiguity is where adoption goes to die, so kill the ambiguity.

Recognition

Catch people doing it well and say so out loud.

Here is the part most teams skip: celebrate the experiment even when it flops. If only the wins get recognized, people learn to hide the failures, and the failures are where half the learning lives. Reward the attempt and you get more attempts. Reward only the outcome and you get people who wait until something is safe before they try it, which means they mostly never try it.

You get more of whatever you reward. So be deliberate about what you reward. Not only the finished thing that worked. The person who took the swing.

Those three hold each other up. Learning makes people aware. Expectations make it clear. Recognition makes it safe to try. Pull one out and the other two start to wobble. Learning without expectations is motion without direction. Expectations without recognition is a rulebook nobody is excited to follow. Recognition without learning is applause for work people don't yet know how to do.

Two more things sit around that core.

Mentorship, because confidence gets caught more than it gets taught. You can read every guide on the platform and still freeze at the blank prompt. What unlocks people is watching someone a little further along do it in front of them, then trying it with that person still in the room. What actually transfers is permission, and a pattern they can copy.

And workflow redesign, the unglamorous work of walking through what your team does every week and asking, plainly, what should the agent own here, what should the human keep, and where does the handoff get messy. That last question is where most of the real gains hide. The messy handoff, the step everybody quietly dreads. The goal is to find those seams and re-cut them, the handful of steps where the agent is clearly the better owner and the human is freed to do the part only they can.

If you take one thing from this, take this. AI adoption is not a technology problem. It is an organizational design problem. The teams that pull ahead won't be the ones with the most logins. They'll be the ones who built the conditions for people to learn, to know what good looks like, to get recognized for trying, and to reshape the work around what AI is genuinely good at.

Access doesn't create adoption. Capability does.

That's the job. Not administering tools. Architecting capability.

Where to Start

If you're starting cold, don't try to stand all of it up at once. Sequence it.

Stand up the learning forum first. It's the cheapest thing to launch and it gives you momentum you can point at. One recurring slot, a few people showing real work, and you have proof the thing is alive.

Expectations and recognition come next. Tie the expectations to how people already get promoted, so it reads as how we grow here, not as another initiative landing on their desk. When the standard lives inside the career conversation people are already having, it stops feeling like extra.

Then pick one recurring workflow, just one, and actually re-cut it into agent work and human work. Not a plan to redesign everything. One process, taken apart and put back together, in front of the team. One real example teaches more than a manifesto.

Introduction

Large language models can feel like magic. You type a question, and fluent, often useful text comes back. But behind that text box there is no mind reading the internet in real time and no database being queried. There is a single, understandable idea: a system trained to predict the next chunk of text, one piece at a time, based on patterns it absorbed from a huge amount of writing.

Understanding how that system is built makes it far easier to use well. A model is created in three broad stages that loosely mirror how a person learns: first it reads enormous amounts of text to build a general knowledge base, then it studies worked examples of good answers, and finally it practices on problems where the right answer can be checked. Each stage shapes a different part of what the model can do and how it behaves.

This guide walks through those stages in plain language, then looks at how the model "thinks," where it tends to slip, and how to get reliable results from it. The throughline is simple: the model is the medium we are building with, and the better we understand that medium, the more we can innovate with it. Knowing what is happening under the hood is the difference between being impressed by these models and actually being good with them.

Stage One: Pre-training

The first step is to download and filter a huge slice of the public internet. The goal is a large, diverse collection of high quality text. Raw web data is cleaned in many passes: stripping out unwanted sites, pulling clean text from the HTML, filtering by language, removing duplicates, and removing personal information. A representative dataset might be tens of terabytes of text, on the order of trillions of words.

What a token is, and how it's made

Before any training happens, the text has to be turned into something the model can process: a sequence of symbols from a fixed vocabulary. Those symbols are called tokens, and the conversion is called tokenization.

A token is usually a chunk of text a bit smaller than a word, a common word, a word fragment, a space, or a punctuation mark. "Tokenization," for example, might split into a few pieces, while a frequent word like "the" is a single token. Each distinct token is assigned a number, an ID, so under the hood the model sees a sequence of IDs rather than letters.

Why chunks instead of single characters? It is a trade-off. If every character were its own symbol, sequences would be extremely long and expensive to process. If the vocabulary were enormous, each symbol would be rare and hard to learn. Tokens sit in the middle. The vocabulary is built by scanning a large amount of text and repeatedly merging the most common pairs of characters into new, reusable symbols, growing the vocabulary until it reaches a practical size (commonly around 100,000 tokens). Frequent patterns end up as single tokens; rare ones get split into several.

This one detail explains a lot of a model's quirks. Because it sees tokens, not letters, it can struggle with spelling, counting characters, or questions like how many of a given letter appear in a word, even while it handles much harder problems with ease.

During training, the model is shown windows of tokens and asked to predict the next one. It outputs a probability for every possible token, and when it guesses wrong, its internal parameters (billions of adjustable values) are nudged so the correct token becomes slightly more likely next time. Repeated across enormous batches, the model's predictions come to match the statistics of the data. Internally this runs on a structure called a Transformer, but the key idea is simple: it is a fixed mathematical function with no memory, turning input tokens into a prediction.

The result of this stage is a base model. It is essentially an internet text simulator: give it a prefix and it will continue it, producing fluent but unguided text. It has absorbed a great deal of knowledge, but it is not yet an assistant. It does not answer questions so much as autocomplete them.

Stage Two: Supervised Fine-Tuning

To turn a base model into an assistant, you keep training it, but you swap the dataset. Instead of raw web pages, you use a large collection of example conversations between a user and an assistant, covering many topics. Nothing about the method changes; only the data does. Because this dataset is far smaller, this stage is much faster than pre-training.

These conversations start from human-written examples that follow detailed guidelines: be helpful, be truthful, decline what you should decline. Today, models help generate and edit much of this data, but it still traces back to human judgment about what a good response looks like.

This reframes what you are talking to. When you get an answer, you are essentially getting a statistical imitation of a skilled human following those guidelines, compressed into the model. If your exact question appeared in the training data, the answer will resemble what a human wrote; if not, the model blends its background knowledge with the patterns it learned to produce something new.

How the Model Thinks (and Where It Slips)

A few behaviors follow directly from this design.

Hallucinations. If the training data always answers "who is X" confidently, the model learns to answer confidently even about people it has never encountered, inventing plausible details. Two fixes help: teaching the model to say "I don't know" where it genuinely doesn't, and giving it tools so it can look things up instead of guessing.

Memory vs. working memory. Information stored in the parameters is like something you read long ago: fuzzy and unreliable for rare facts. Information in the context window is directly available, like notes in front of you. So if you want an accurate summary of a document, paste the document in rather than trusting recall. This principle has hardened into standard practice: many systems now automatically retrieve relevant text and place it in front of the model before answering, so responses are grounded in source material rather than memory alone.

Tokens to think. Because each token does only a little computation, a model that jumps straight to an answer is forced to guess; everything after is just justification. Letting it work step by step, or asking it to use code for arithmetic and counting, produces far more reliable results.

Jagged edges. Capability is like Swiss cheese: brilliant across many hard problems, then failing on something that looks trivial. The failures are often unintuitive, so the model cannot be treated as infallible.

Stage Three: Reinforcement Learning

The final stage is practice. Rather than handing the model a worked solution to imitate, you give it problems with known answers and let it try many approaches. The attempts that reach the correct answer are reinforced. Over many problems, the model discovers, for itself, the reasoning paths that work, sometimes finding strategies a human wouldn't have written down.

This is where "thinking" or "reasoning" models come from. They produce longer responses that check their own work, backtrack, and try different angles, and this behavior emerges from the training rather than being hand-coded. It works best in verifiable domains like math and code, where any answer can be scored automatically, and that is exactly where these models have advanced fastest, now matching expert humans on problems that looked out of reach only a year or two ago.

Reasoning is no longer a novelty bolted onto a separate model. It has become a standard capability, and the line between a "thinking" model and a "regular" one is fading. The newest systems fold both into a single model that decides how much to deliberate based on how hard the task is, spending more computation on a thorny problem and answering a simple one quickly, without you having to pick a mode. The underlying idea is unchanged; it is just becoming a built-in dial rather than a separate product.

In domains without a clear right answer, like creative writing, training relies on a learned model of human preference instead of a hard check. This helps, but it is gameable: pushed too far, the optimization finds nonsensical outputs that score well anyway. So this kind of training is applied in moderation, not run indefinitely.

How to Use One Well

These models are genuinely powerful and can accelerate a wide range of work. They are also confidently wrong sometimes, will skip steps, and will occasionally fail at something simple. The reliable approach is to treat the model as a tool in your toolbox: use it for inspiration and first drafts, give it the context and tools it needs, and always check and verify the result.

The most important part is owning the final product. The model can generate, draft, and suggest, but it has no stake in the outcome and no real understanding of your situation. You are the subject matter expert. You bring the judgment about what good actually looks like, the intent behind the work, and the context the model can't see: who it's for, what's at stake, which details matter, and where a plausible-sounding answer would quietly be wrong. The model supplies raw material at speed; you supply the discernment that turns it into something correct and worth putting your name on.

That division of labor is also where the value is. Treat the output as a starting point you interrogate, not an answer you accept. Ask whether it matches reality, fits the goal, and holds up under scrutiny, and revise accordingly. Used that way, the model amplifies your expertise rather than replacing it, and the result is better than either of you would produce alone.

The model is the medium we are building with. The more deeply we understand it, the more we can innovate with it, and the more the work that comes out the other side is unmistakably ours.

Pro Tips

- Give it the material, don't make it remember. Paste in the document, data, or context the task depends on. Grounding the model in source text beats relying on its fuzzy recollection, and it cuts hallucinations sharply.

- Let it think before it answers. For anything that needs reasoning, ask for the steps, not just the conclusion. A model that jumps straight to an answer is guessing; one that works through it is far more reliable.

- Push arithmetic, counting, and exact text to tools. When precision matters, have it use code or a calculator rather than doing the math in its head. The same goes for counting or manipulating characters.

- State the goal, the audience, and the constraints up front. The model can't see what's in your head. The more it knows about who the output is for and what "good" means here, the closer the first draft lands.

- Reach for a reasoning model on hard problems, a fast one for simple asks. Deep deliberation is overkill for a quick factual or formatting task, and waiting for it just slows you down.

- Treat confidence as style, not proof. A fluent, assured answer is not evidence it's correct. Verify anything that carries real consequences.

- Iterate in small, specific passes. Correct one thing at a time and tell it exactly what to change. Vague "make it better" prompts drift; surgical notes hold the line.

- Watch for the trivial miss. Capability is jagged, so the failure is often hiding in the easy part of an otherwise impressive answer. Read with that in mind.

- Own the result. Use the model for speed and first drafts, but bring the judgment, intent, and final sign-off yourself. The work is yours, not the model's.

Diego Martins is a Strategist, Writer, and Design Engineer Leader who consults with companies on AI, product cycles, and team structure. He scans future signals and writes about where things are heading. He has been writing about the future of AI and design before it becomes table stakes.

Author of Agentic Design https://agenticdesign.diegomartins.com