AI fundamentals · Overview

How AI Is Built and Implemented

The lifecycle, the mechanism inside the model, the scale economics, and the software layer that turns a model into a product.

REV 1.2 19 September 2026 Confidence-tagged · provenance at end Download PDF · light Download PDF · dark

1. The lifecycle: two phases with different economics

"AI" as shipped today is a large neural network whose behavior is set in a one-time training phase and then used in a per-request inference phase. Training produces a frozen file of numbers called weights. Inference is that file being run, over and over, for every request. Every later cost and performance question traces back to this split: building is a capital expense paid once, implementing is an operating expense paid per token.

AI lifecycle: build versus implement Two bands. Build: data, pretraining, post-training, evaluation. Implement: weights, serving, orchestration, application. Evaluation hands off to weights, and usage feeds the next training run. Build: training (one-time, capital-heavy) DataCurate + tokenize PretrainingNext-token loss Post-trainingSFT, RLHF, RL EvaluationTests + red-team Implement: inference (per request, operating cost) WeightsFrozen parameters ServingBatching + cache OrchestrationContext + tools ApplicationChat, IDE, API ↻ Usage data, failures and new evals feed the next training run
Figure 1. The build phase (blue) ends in a frozen set of weights. The implement phase (green) runs those weights for every request.

What each build stage contributes

2. Inside the model: one pass per token

The frozen weights implement a transformer. The model does not look anything up or run a program in the usual sense. It converts text to numbers, pushes those numbers through a deep stack of identical layers, and produces a probability for every possible next token. One token is chosen, appended to the input, and the whole process runs again.

Token generation loop Left column: prompt text, tokenizer, embeddings. Center: transformer block repeated N times containing self-attention and feed-forward layers. Right column: probabilities, sampler, output token, which is appended to the input. Prompt text TokenizerText → token IDs EmbeddingsIDs → vectors Transformer block × N Self-attentionTokens read each other Feed-forward (MLP)Applies learned knowledge Stacked tens to 100+ times ProbabilitiesOver whole vocabulary SamplerPicks one token Output tokenAppended to input ↻ One full pass through all N blocks per output token, then repeat
Figure 2. Input and output handling (cyan) surrounds the transformer stack (purple). Generation is a loop: every output token costs one full pass.

Three consequences of the loop

3. Scale: why building is a capital project

Capability has tracked training compute closely, so labs have scaled it relentlessly. Epoch AI's trend dashboard puts frontier language-model training compute at about 5× per year since 2020, a doubling roughly every 5.2 months, with training costs rising about 3.5× per year and power requirements doubling annually. HIGH

Developer-reported (circle) Third-party estimate (triangle) 2025–26 frontier band (secondary source)
Training compute of landmark AI models, 2012 to 2024, log scale AlexNet 2012 4.7e17 FLOP; Transformer 2017 7.4e18; BERT-Large 2018 2.9e20; GPT-3 2020 3.1e23; PaLM 2022 2.5e24; GPT-4 2023 2e25; Gemini Ultra 2023 5e25; Llama 3.1 405B 2024 3.8e25. A dashed band marks 1e26 to 1e27 FLOP for 2025 to 2026 frontier runs. 1e171e181e191e201e211e221e231e241e251e261e271e28 201220142016201820202022202420262028 Release year Training compute (FLOP, log scale) 2025–26 frontier training runs: roughly 1e26 to 1e27 FLOP (LOW confidence, secondary source) 2025–26 frontier runs (LOW) AlexNet (2012): ~4.7e17 FLOP — third-party estimate Transformer, big (2017): ~7.4e18 FLOP — third-party estimate BERT-Large (2018): ~2.9e20 FLOP — third-party estimate GPT-4 (2023): ~2e25 FLOP — Epoch AI estimate Gemini Ultra (2023): ~5e25 FLOP — Epoch AI estimate GPT-3 175B (2020): 3.14e23 FLOP — developer-reported PaLM 540B (2022): ~2.5e24 FLOP — developer-reported Llama 3.1 405B (2024): 3.8e25 FLOP — developer-reported AlexNet Transformer BERT-Large GPT-3 175B PaLM 540B GPT-4 Gemini Ultra Llama 3.1 405B
Figure 3. About eight orders of magnitude in twelve years. Marker shape encodes provenance: circles are developer-reported, triangles are third-party estimates. Hover a marker for its value. The 2025–26 band is drawn as a range, not as points, because it is not lab-disclosed.

Epoch's own estimates put GPT-4 at about 2e25 FLOP and Gemini Ultra at about 5e25, against GPT-3's roughly 3e23 in 2020. HIGH A secondary analysis places 2026 frontier runs in the 1e26 to 1e27 window. LOW

The physical stack, bottom to top

LayerWhat it isTypical binding constraint
Power and datacenterGigawatt-scale sites, cooling, grid interconnectEnergy availability, build time
AcceleratorsGPUs and TPUs with high-bandwidth memory (HBM)Chip and HBM supply, advanced packaging
InterconnectNVLink, InfiniBand or Ethernet fabrics linking tens of thousands of chipsAll-to-all bandwidth during training
Systems softwareCUDA / ROCm, PyTorch or JAX, parallelism frameworksUtilization, fault recovery at scale
ModelArchitecture plus trained weightsData quality, algorithmic efficiency
ServingvLLM, TensorRT-LLM, llama.cpp, quantizationMemory bandwidth, KV cache size
Orchestration and appContext assembly, tools, agents, user interfaceReliability, security, cost per task

The "binding constraint" column is synthesis, not a sourced ranking. MED

4. Implementation: the model is one component

A deployed AI product is mostly conventional software wrapped around the model call. The model is stateless and knows only what is in its context window on that pass. Everything that feels like knowledge of your files, memory of past conversations, or the ability to act is the orchestration layer putting text into that window and executing what comes out.

AI implementation architecture Top row: user or app, orchestrator, model. Bottom row: instructions, retrieval and memory feed the orchestrator; tools exchange calls and results with the model. Retrieval and tools are marked as the entry points for untrusted content. User or appSends request OrchestratorBuilds the context window ModelGenerates tokens InstructionsSystem prompt Retrieval (RAG)Docs, vector search MemoryChat history ToolsCode, search, APIs call result Amber = where untrusted external content enters the context ↻ Agent loop: tool result re-enters the context and the model runs again until done
Figure 4. The orchestrator assembles instructions, retrieved documents and history into one context window. Tools close the loop that makes a model an agent.

Implementation patterns, in increasing order of autonomy and risk

Security note: the lethal trifecta. An agent becomes dangerous when three things coincide: access to private data, exposure to untrusted content, and the ability to act autonomously. In Figure 4, retrieval and tool results are the entry points for untrusted content, and tools are also the action surface. The risk therefore concentrates in the orchestration layer, not in the model. Section 5 treats this as a layer in its own right.

Where the weights run: three deployment modes

ModeWho holds the weightsCost shapeTrade-offRouting lane
Local open weightsYou (llama.cpp, Ollama, quantized to fit consumer VRAM)Hardware capex, near-zero marginal costPrivate and free per token; capability capped by memoryLane 1
Hosted open weightsA cloud host behind a routerLow per-token opexCheap and capable; endpoint reliability variesLane 2
Closed frontier APIThe lab onlyHighest per-token opexTop capability; no weight accessLane 3

The routing decision across these modes is an intelligence-per-dollar question: cost per unit of completed task, including endpoint reliability, rather than headline capability.

5. The security layer: prominent, specified, not yet deployed

Figures 1 and 4 have no security component, and that omission mirrors the field. As of September 2026 the controls for AI systems are well specified in OWASP's Top 10 for LLM and Agentic Applications, MITRE ATLAS and the NIST AI Risk Management Framework, yet the incident record shows them deployed unevenly, and one class of threat has no complete fix at any layer. This is now a prominent issue that needs to be addressed, not a footnote to the architecture. The evidence divides into three tiers, and each carries a different status.

2026 evidence. Figures are as reported by the cited source; most sources sell security products or research, so treat counts as indicative.

Three tiers of status

Defense in depth for an AI system, with deployment status Five horizontal bands from outside in: perimeter, content, action, supply chain, observability. Each names its controls and carries a status badge: partial, unsolved, rare, rare, partial. Perimeter Input classifiers · egress allow-list · no external images Partial Content Retrieved docs and tool results treated as data · dual-model isolation Unsolved Action Least-privilege scopes · read-only default · human gate · sandbox Rare Supply chain Authenticated MCP servers · pinned dependencies · signed weights Rare Observability Prompt and tool-call logging · spend caps · alerts · playbook Partial Status = author's assessment of typical 2026 production deployments, from the evidence above. Partial: common but inconsistent. Rare: specified, seldom deployed. Unsolved: no complete control exists.
Figure 5. Defense in depth, outside in. Every band is specified in OWASP, ATLAS or NIST guidance; the badges record how often it is found in practice.

Build-side threats and controls

ThreatWhere it entersControlStatus
Data poisoning, backdoorsPretraining and fine-tuning dataProvenance filtering, dedup, canary strings, held-out backdoor evalsPARTIAL
Malicious model filesWeight downloads; pickle-based formats can execute code on loadsafetensors or GGUF only, checksum and signature verification, trusted hubsPARTIAL
Model theft, distillationInference endpointRate limits, output watermarking, terms of serviceWEAK
Evaluation gamingBenchmark contaminationHeld-out and private evals, contamination checksPARTIAL
Unsafe capabilityPost-trainingRefusal training, constitutional methods, red-teaming, independent safety evalsDEPLOYED vendor-reported

Implement-side threats and controls

ThreatWhere it entersControlStatus
Direct prompt injection, jailbreaksUser inputInput classifiers, system-prompt hardening, output filteringPARTIAL
Indirect prompt injectionRetrieved documents, web pages, tool results, emailTreat fetched content as data; separate the model that reads from the model that actsUNSOLVED
Data exfiltrationTool calls, markdown image URLs, outbound requestsEgress allow-lists, no auto-rendered external images, tool-result redactionRARE
Excessive agencyAgent loopLeast-privilege tool scopes, read-only default, human approval on irreversible or financial actionsRARE
Insecure output handlingDownstream codeNever eval or shell model output unsandboxed; parameterize; sandbox code executionPARTIAL
Supply chain: MCP servers, plugins, skillsOrchestration layerAuthentication on, pinned versions, third-party review, scoped credentials per serverRARE
Secrets and billing exposureAPI keysPer-use-case keys, hard spend caps, no keys in prompts or repositoriesPARTIAL
Privacy and residencyContext window, logsData minimization, retention policy, zero-retention endpoints where offeredPARTIAL
ObservabilityEverythingLog prompts, tool calls and outputs; anomaly alerts; incident playbookPARTIAL

The architectural answer to Tier 2

Because no filter reliably separates instructions from data inside one context window, the defense that works is structural: two models with different privileges. A quarantined reader sees untrusted content but has no tools. A privileged actor has tools but never sees raw untrusted text, only structured output from the reader that the orchestrator validates against a schema. Injected instructions cannot reach anything that can act.

Dual-model pattern Untrusted content flows to a quarantined reader with no tools, which emits structured output checked by the orchestrator against a schema, which flows to a privileged actor with tools, which produces actions. A barrier separates the reader side from the actor side. UntrustedDocs, web, email Quarantined readerModel · no tools Schema checkOrchestratorStructured fields only Privileged actorModel · tools · no raw text Reads untrusted text, cannot act Can act, never reads untrusted text Red barrier: only validated structured data crosses. Cost: two model calls per step and a narrower interface.
Figure 6. The dual-model pattern (also called dual LLM, or CaMeL in the research literature). It is the one control that addresses indirect prompt injection structurally rather than probabilistically.

The closing point is about adoption, not invention. Nearly everything in the two tables is conventional security engineering applied to a new component: authenticate, scope, log, cap, verify. A single operator can apply most of it in an afternoon: per-use-case API keys with hard credit limits, headless jobs restricted to read-only, dependency pinning, mandatory access control left enforcing. The controls are cheap and known. What is missing in 2026 is the expectation that they ship by default.

6. How a model reads one token, and where backpropagation fits

A common mental model is that a language model "reads" a character such as A, tries several interpretations, and backtracks when one fails. The real mechanism is different in two ways. First, the model never sees a shape: the tokenizer hands it an integer ID, and the work is deciding what that ID means here (the article "a", the letter's name, a grade, a blood type, a musical note, a variable). Second, within a single forward pass nothing backtracks. Each layer rewrites the token's vector, so an early, generic reading is overwritten by a context-specific one. Interpretability researchers call reading those intermediate states out the logit lens; the process itself is iterative refinement in the residual stream.

Layer3 of 6
Attention from the token A to its context, by layer Sentence: She got an A on the exam. Curved lines from the A position to other tokens grow thicker on got and exam as the layer index rises. Sentence: "She got an A on the exam." — the amber token is the one being resolved Line thickness = how much the "A" position reads from each token at this layer
Figure 7. Per-layer resolution of one token. The web edition is interactive: drag the layer slider. The PDF edition shows layer 3, where the reading flips from "letter" to "grade". Values are illustrative, not measured from a real model.

Two things to notice. The "article" reading at layer 0 was never wrong: it was the correct prior with no context. And the flip at layer 3 is not a decision the model could revisit; it is arithmetic. Attention added the "exam" vector into the "A" position, and the sum now points in the "grade" direction.

Recognizing A as a shape is the job of a vision encoder in a multimodal model. It is also a single forward pass, but the hierarchy is spatial rather than contextual, and it is the one place where the picture of competing hypotheses is closest to literal.

Vision path for the letter A Left to right: a pixel patch grid containing an A, edge features, stroke features for left diagonal, right diagonal, crossbar and apex join, and a hypothesis bar chart where A wins over H, Lambda and 4. 1. Pixels → patches Each cell → one vector 2. Edges Orientation, contrast 3. Strokes Left diagonal ✓ Right diagonal ✓ Crossbar ✓ Apex join ✓ Mid-layer features 4. Hypotheses A H Λ 4 Crossbar kills Λ, apex kills H
Figure 8. Spatial hierarchy in a vision encoder. Λ and H are not tried and abandoned; their evidence is simply outweighed in the same forward sum.

The correct terms

What is happeningTermWhere it runs
Token meaning refined layer by layerIterative refinement in the residual stream; read out with the logit lens or tuned lensInference, inside one forward pass
Competing readings coexisting until one dominatesSuperposition of features, resolved by contextualizationInference, inside one forward pass
Model writes a hypothesis, then corrects itSelf-correction, self-verification, reflectionInference, in the output tokens
Several candidate continuations kept, losers droppedBeam search; search over reasoning paths (tree of thoughts, best-of-N)Inference, across candidate outputs
Error pushed back through the layers to adjust weightsBackpropagation, with gradient descent as the update ruleTraining only

So the process that resembles backtracking through the layers is backpropagation, and it happens only during training. After a wrong prediction, the backward pass computes how much each weight contributed to the error, layer by layer from the output back to the input, and gradient descent nudges each one. It is how the stroke detectors in Figure 8 were learned. Once the weights are frozen for deployment it never runs again.

One training step: forward pass, loss, backward pass, update Forward pass produces a prediction, the loss compares it to the correct token, backpropagation sends the error back through every layer, and gradient descent updates the weights. A note states that the backward side costs about twice the forward side. Forward passPredict next token Lossvs. the true token BackpropagationGradient per weight UpdateNudge weights ↻ Repeated for trillions of tokens; the loop stops when the weights are frozen for release Cost: the backward side is about 2× the forward side, so a training token costs ≈ 3× an inference token, and needs full-precision weights plus optimizer state in memory. Inference can run quantized on frozen weights.
Figure 9. Backpropagation is the training-time loop. Its roughly 3× per-token cost and memory footprint are the mechanical root of the capex/opex split in Figure 1.

7. Provenance and confidence

Sources