How AI Actually Works: Claude, ChatGPT and LLMs Explained Simply

Your text gets split into tokens. A token is a small piece of text, not always a full word. "Hello world" might become ["Hello", " world"]. Longer or unusual words often get broken into smaller parts.

Try this simplified illustration. Real token splits vary by model and are more complicated than this display:

Each token then gets turned into numbers. In AI, those numbers are often called a vector or an embedding. Think of that as the model's internal way of storing meaning so related words and ideas end up closer together.

Attention is the part that helps the model decide what matters most in a sentence. Each token checks the other tokens around it to figure out which words are important for meaning.

When the model reads "The cat sat on the mat", the word "sat" is linked closely to "cat" and "mat" because those words help explain who did the action and where it happened.

Large models do this many times in parallel using attention heads. An attention head is just one small pattern detector focused on a certain kind of relationship:

• →One head may track who did the action
• →Another may track what the action applies to
• →Another may connect names, pronouns, and references
• →Many others learn patterns around order, grammar, tone, and structure

The last step is prediction. The model scores many possible next tokens and samples one, usually favoring the higher-scoring options. Those scores are called probabilities, which just means how likely each option is.

After it picks the next token, that token gets added to the running answer. Then the model does the same thing again. That loop is why replies appear word by word even though a lot of math is happening underneath.

When you ask AI to build software, it does not just guess. It considers options, checks its tools, thinks through the logic step-by-step, and then brings the app to life.

There is no universal cost per request. Providers publish current model and tool pricing, while subscription plans bundle changing usage limits. Estimate with the actual model, token volume, and tools your product uses.

How the system keeps its place

These systems need to remember where they were. Teams save the current state, which means the conversation, tool results, and next step, in a database. If the process stops or times out, it can restart from the last saved point instead of beginning again.

Where a person still has to approve

For important actions, a human still needs to sign off. The agent prepares the action, pauses, and waits for approval. This is common for money movement, risky customer messages, deletions, or policy exceptions.

Safety rules around tools

Not every tool is safe to let loose automatically. Real systems put clear limits around what the agent can do:

• →Rate limits per tool (max 10 DB queries per workflow)
• →Permission checks (agent can read orders, not delete them)
• →Cost limits (max $5 in API calls per workflow)
• →Audit logs (every tool call logged with timestamp, inputs, outputs)

How teams watch what the agent is doing

If you cannot see what the agent is doing, you cannot trust it. Teams track simple things like success rate, number of steps, common failures, and cost:

Tracing tools follow each workflow from start to finish. Dashboards show slow steps, repeated loops, and failures so teams can fix the system before it causes trouble.

Common software used to build these systems

A vocabulary is the complete set of units a model can recognize and produce. How you define those units involves a hard tradeoff with no perfect answer.

BPE is a bottom-up compression algorithm adapted for vocabulary construction. The loop is simple in principle:

The result: common strings like function or return get a single token. Rare words get decomposed into pieces, often slicing right through what a linguist would call morpheme boundaries. That is intentional: BPE optimizes for corpus frequency, not linguistic structure, and those two things do not align.

If you have spent time prompting models at scale, you have probably run into behaviors that trace back to the tokenization layer rather than the model weights.

Each token ID maps to a learned embedding vector. That vector is not engineered by hand. It starts random and gets updated continuously during training as the model learns to predict the next token across trillions of examples. By the end of training, the embedding for a given token implicitly encodes everything the model observed that token doing across the corpus.

This raises a real question: does the embedding for a token like deploy "know" it is spelled d-e-p-l-o-y? Formally, no. The token is just an integer. But research shows character-level information does bleed into embeddings. The most likely reason: the same root word surfaces in many tokenized forms across a large corpus (singular, plural, past tense, mid-sentence, sentence-initial, after punctuation, inside a code block) and the model is incentivized to build representations that generalize across those surface variations.

Practical implication: models handle spelling and character-level tasks better for common words (which appear in many tokenized surface forms during training) and worse for rare words or niche proper nouns that were almost always tokenized the same way. If you are building a prompt that requires character-level precision, explicitly spell out the string in your prompt rather than assuming the model can decompose it cleanly.

Before a model ever reaches you, it goes through a process called alignment training. This is where the model is trained not just on what is factually correct but on what is helpful, harmless, and honest.

Common techniques include RLHF (Reinforcement Learning from Human Feedback), where human reviewers rate model responses, and newer preference-optimization methods. The model is then updated to produce more helpful responses and fewer unsafe ones. Over many rounds, this shapes behavior before anyone outside the lab sees it.

• →The model learns to decline requests that could cause harm
• →It learns to flag uncertainty instead of making things up confidently
• →It learns to avoid helping with things that are clearly illegal or dangerous
• →It learns tone, nuance, and when to push back on a bad idea

This is not perfect. Models can still be pushed in wrong directions with the right prompts. But the baseline behavior is trained, not bolted on as an afterthought.

Many AI products add system instructions and other guardrails. Before the model sees your message, the company or developer may give it instructions about its role, available tools, and safety rules.

Think of it as an employer giving a contractor rules. Those rules influence behavior, but they are not a security boundary by themselves. Reliable systems combine them with permissions, validation, and monitoring.

On top of that, most platforms run content filters that check both input and output:

• →Input filters catch known harmful patterns before they reach the model
• →Output filters check the model's response before it reaches you and block or rewrite anything that crosses a line
• →Rate limits and monitoring flag unusual usage patterns and slow down or stop automated abuse

A base model cannot take actions outside its response. It can process the input it is given and generate text or other output, but it cannot reach the internet, execute code, send emails, move money, or control systems unless the surrounding application connects a tool and allows that action.

When a model does have tools, those tools are scoped. A customer support agent with access to your order data does not also have access to your bank account. The access is defined by whoever built the product, not decided by the model.

This is important because it makes the risk surface reviewable. An agent that can only read your calendar and draft meeting summaries is limited by those permissions. The question becomes what the people who built it connected, what data it can reach, and which actions still need approval.

Many major model releases go through red-team exercises. Red teaming is where people try to break the system: elicit harmful content, bypass safeguards, or trigger unexpected behavior.

Findings can inform mitigations before release, and problems found afterward need patches and monitoring. This is similar to security testing: evaluate, ship carefully, monitor, and improve.

Major labs publish different levels of safety documentation, and some releases include independent evaluations. The depth of reporting and third-party review varies by organization and model release.