Introduction

Building with LLMs is easy to start and easy to misunderstand. You paste a prompt into an API, get text back, and ship a demo. Then retrieval fails, costs spike, an agent loops forever, or nobody can say whether the new prompt is actually better.

This article is Essentials: a map of the territory. Each following article does a deep dive into one layer — how LLMs work, prompts and context, embeddings and retrieval, RAG, tools and agents, orchestration, observability, and evals. The goal is the same as Go Internals: connect behavior you already see in apps to the machinery underneath, in an order that levels the knowledge before the harder pieces.

What "AI internals" actually covers

When people say "AI internals" in an application sense, they usually mean two stacks that meet at the API boundary:

1. The model stack — tokens, training vs inference, context windows, sampling. This is what turns a prompt into a completion.
2. The app stack — prompts, retrieval, tools, orchestration frameworks, tracing, and evals. This is what turns a completion into a product.

Your HTTP handler is not the whole system. The provider runs inference; your code owns everything around it: what goes into the context, what gets retrieved, which tools can fire, and how you measure whether answers are any good.

Most of the series lives on the app side of that diagram, but we start with enough model mechanics that later articles are not magical. How LLMs Work is the first deep dive; Evals closes the loop once there is something worth measuring.

Series roadmap

An LLM app is not one blob of "AI code." It is layers that depend on each other. Later articles assume earlier ones; that is why the series is vertical instead of one giant post.

Examples in this series show up in Go, Python, and TypeScript where code helps. Use the language tabs on those blocks; the idea is the same in each language.

From a prompt to a completion

A minimal request is enough to anchor the rest of the series. You send messages (and maybe tools or retrieved docs later); the provider tokenizes the input, runs inference, samples the next tokens, and returns text.

Conceptually:

Here is the same idea as a tiny client call — not production code, just the shape of the boundary we will keep returning to:

Everything later in the series — RAG context, tool results, agent steps — is still this loop: assemble messages, call the model, read the completion. The hard part is what you put in the messages and how you judge the output.

How to follow along

You do not need to train a model. You need a provider API key (or a local model later) and the habit of running small experiments.

Useful habits for the deep dives:

• Small prompts — one behavior per experiment (temperature, tool choice, retrieval hit/miss).
• Log the raw request — messages, tool calls, retrieved chunks. Guessing from the UI wastes time.
• Measure something — even a crude checklist beats vibes once prompts start multiplying (Evals).
• Prefer one language for drills — switch tabs when you want another ecosystem; do not rewrite every example three times by hand.

We will not treat "pick the hottest framework" as a goal. Frameworks appear when they clarify composition (Orchestration) or production debugging (Observability).

What you should already know

This series is about systems around LLMs, not a language tutorial. Comfortable reading of:

• HTTP APIs and JSON
• basic async or concurrent request patterns in at least one of Go, Python, or TypeScript
• the idea that prompts are data you control, not magic strings

is enough. If you have shipped any backend that calls a third-party API, you are in the right place.

Conclusion

Essentials sets the route: the model turns tokens into text; your app owns context, retrieval, tools, and measurement. Each upcoming article isolates one layer.

Next up is How LLMs Work — tokens, training versus inference, context windows, and sampling, before we climb into prompts and retrieval.