# The AI Field Guide, 2026 Edition - Full Text > Fifteen Tufte-coded cards on how AI actually works, written for the people who approve the strategies, sign the contracts, and answer for the outcomes. A four-week Beyond Reason series by Eric Porres, Chief AI Officer at Logitech. Free. Licensed CC BY 4.0. Web home: https://porres.com/aifieldguide/ About this file: This is a plain-text rendering of the entire guide for machine reading. The fifteen cards are visual infographics; their text has been transcribed here. The canonical artifacts are the full-size card images (one PNG per card, linked on each card page) and the 22-page PDF at https://porres.com/aifieldguide/assets/ai-field-guide-2026-beyond-reason-eric-porres.pdf. Every card is captioned "Prepared by Eric Porres, Chief AI Officer, Logitech." Numbers and figures are transcribed faithfully; where the densest comparator tables were ambiguous in the source art, this text errs toward the clearly disclosed primary figures. Contents: six wrapping pages (About This Guide, How to Read This Guide, The Argument This Guide Defends, Receipts and Further Reading, About the Author, Colophon) and the fifteen cards, organized in three parts plus a synthesis. --- ## About This Guide This is a field guide for situations where the AI bird is already gone. You know the situations. A vendor demo where you got the answer in two minutes and could not draw the system that produced it. A board meeting where the question that mattered came after the slide had advanced. A regulatory conversation where the lawyer needed a vocabulary you had not yet built. I made these cards over four months in 2026 because most AI literacy for decision-makers is anecdotal. Fifteen cards is not exhaustive. It is the minimum vocabulary I think the people in those rooms need to argue. The cards borrow from Edward Tufte without apology. The aesthetic is restrained because the substance is dense. None of these cards is the front of a brochure. All of them belong on a workbench. If you find them useful, share them. If you find them wrong, tell me. This guide will need updating in eighteen months. The plumbing changes. The questions do not. - Eric Porres --- ## How to Read This Guide The fifteen cards come in three clusters and one closer. Cards 01-05 cover the runtime of a single AI request. What happens when you hit send. Where the context comes from. What the model actually sees. Why the same prompt can cost a tenth of a cent or ten cents. Why the chat does not remember you. Cards 06-10 cover where the answers come from. The training run. What knowledge cutoff really means. How retrieval gets the model past the cutoff. The physical buildings where any of this actually happens. The water, energy, and carbon footprint of a single prompt. Cards 11-15 cover the trust layer. Agents and how they fail. Permissions and identity. Routing across multiple models. Evaluation as a discipline. And the synthesis on Card 15: the enterprise AI control plane, the layer between the people who use AI and the systems that AI touches. The cards are designed to stand alone, in any order. The strongest reading is sequential, because Card 15 depends on the layers the earlier cards make legible. Read them once for breadth. Read them again, slowly, when you have a specific decision in front of you. The card you need will surface. If you would rather read the long-form essays the cards came from, the four Beyond Reason pieces are linked at the back of this guide. --- # Part 1 - What Happens When You Hit Send (Cards 01-05) The runtime of a single AI request. ## Card 01 - An LLM Request, End to End Subtitle: What changes when training data is OFF versus ON. Important: the model is not retrained during a live request. The setting only affects whether eligible data may later be used to improve future model versions. The request path is the same whether training data is OFF or ON - eight steps: 1. User enters prompt - text, files, images, or voice. Raw user input enters the system. 2. Application receives request - account, settings, and permissions applied. Identity, plan limits, and preferences shape the request. 3. Safety and policy checks - abuse screening, malware checks, policy filtering. Protects users and the service before any model computation. 4. Context assembly - system instructions, conversation history, your prompt, retrieved tool outputs, and optional retrieved documents. The context window is the information assembled for this request. 5. Model inference - frozen model weights generate the next token; no live training occurs here. Inference is generating tokens from existing model parameters. 6. Response post-processing - formatting, tool results, citations, and final safety checks. Ensures helpful, safe, well-formed output. 7. Answer returned to user - the user sees only the final visible output in the chat. 8. Operational logging - service reliability, debugging, billing, and abuse detection. Logs support operations and compliance. Notes: Tools and retrieval can change the answer without changing the model. The model is frozen during a request; no learning happens there. Training is a separate offline process using many examples. The setting (OFF or ON) affects what may be used later, not the current reply. Training data OFF: (A) user content is excluded from training pipelines; (B) data may still be retained for operations, security, legal compliance, and product reliability; (C) it is available for abuse monitoring and service diagnostics; (D) it is not added to model-improvement datasets; (E) it does not influence future model versions through training. OFF means your request can power the service, but not future model training. Training data ON: (A) eligible request data may be retained for model improvement, subject to eligibility criteria and user agreements; (B) sampling, filtering, and review - privacy and quality filters, deduplication, and policy review; (C) curated training/evaluation datasets - selected examples, feedback, red-team cases, preference data; (D) offline model improvement - future training, fine-tuning, alignment, and evaluation happen later, outside the live request; (E) updated future model versions - improvements appear only in later releases, not the current request. ON means eligible request data may later help improve future models. Comparison - OFF vs. ON: live response quality is the same request path either way; used for training is No (OFF) vs. Possibly, if eligible (ON); any training effect appears Never via training (OFF) vs. Only in later model versions (ON). KEY TAKEAWAY: Turning training data OFF prevents your request from being used to improve future models. Turning it ON allows eligible data to flow into a careful, separate pipeline that can improve future versions. ## Card 02 - Caching, Cost, and Latency Subtitle: Why the same request can be fast, slow, cheap, or expensive. User experience does not depend on model speed alone. Context size, model choice, tool calls, caches, and output length all shape cost and latency. A cache hit can return saved output in one short hop, skipping retrieval, tools, and model work; a cache miss runs the full path. Typical wall-clock time: a cache hit is roughly 0.3-1.2 seconds; a cache miss is roughly 2-20+ seconds. A cache hit is the cheapest path; a cache miss is the most expensive. Notes: A cache hit can avoid most repeated work. Cache is not always cheaper, and cheaper is not always faster. Tool calls often dominate latency. Long contexts and long outputs increase both cost and delay. Latency, freshness, and correctness can be in tension - pick what matters most for each request, and manage staleness. Main sources of latency, highest impact first: network and transport (round trips, TLS, congestion, geo-distance, retries); retrieval and reranking (vector search, DB reads, reranking, query expansion); tool calls and external APIs (waiting on external services, timeouts, third-party latency); model queueing and selection; inference time (first-token time, tokens generated, context length, hardware); post-processing and streaming (formatting, citations, conversion). Main cost drivers: input tokens (usually linear); output tokens (scale with length); model choice (larger or premium models cost more per token); reasoning depth or extra passes (chain-of-thought, self-critique, retries); tool invocations (external API pricing, calls per request); image/audio/vision (encoding, resolution, processing models); retries or loops (can spike sharply). Where caching helps: (A) prompt/response cache - normalized prompts and their model responses, for repeated identical or near-identical requests; (B) embedding cache - computed embeddings for vector search, for repeatedly revisited text; (C) semantic cache - search results and ranking for a given query and corpus, for stable corpora; (D) tool-result cache - computed results from external tools and APIs, when stable external results make repeated expensive computation avoidable. Caution: never assume every cache is fresh - stale cache hits can lead to unreliable answers; freshness and cache permissions matter. Hit vs. miss: a hit does minimal work (lookup and return) at very low cost, best for stable, low-variance requests; a miss runs the full path (retrieve, model, tools, formatting) at higher cost, needed for dynamic, personalized, or high-stakes requests. Trade-offs and operational levers: use a smaller model for speed and cost (may reduce quality on hard tasks); trim context to reduce tokens; limit tool calls (each adds latency, cost, and failure points); stream early to improve perceived speed; cache carefully to cut repeated work (risky if data is stale). KEY TAKEAWAY: Cost and latency come from the whole system - caching, context, tools, inference, and cache behavior. Smart caching can cut repeated work, but only when freshness and permissions allow. ## Card 03 - How Tools Fit Into an LLM Request Subtitle: Where external capabilities enter the 1-8 request path, especially steps 4 and 6. Tools do not retrain the model. They extend what the system can fetch, compute, transform, verify, or execute during a live request. In the live request path, the two tool moments are step 4 and step 6: 1. User enters prompt - text, files, images, or voice. 2. Application receives request - identity, permissions, settings, and limits applied. 3. Safety and policy checks - initial filtering before processing. 4. Context assembly and tool selection - the system decides what additional capabilities or sources may be needed. This is the major tool-routing point. 5. Model reasoning and orchestration - the model plans, requests, or sequences tool use as needed; it may call one or more tools. 6. Tool-results integration and post-processing - fetched data, calculations, citations, files, or actions are woven into the response. This is the second major tool-touch point. 7. Answer returned to user - the user sees the composed result, not the raw plumbing. 8. Operational logging - telemetry, debugging, billing, and abuse monitoring. Notes: Tools expand capability without changing model weights. Some tools only read; others can write or act. Some are synchronous; others are long-running or agentic. Access may be bounded by identity, permissions, and policy. Step 4, context-time tools: (A) retrieval and search - web search, document retrieval, RAG, knowledge bases; (B) skills and built-in capabilities - calculators, code interpreters, image understanding, summarizers, planners; (C) plugins and APIs - third-party services, SaaS integrations, business systems, custom endpoints (CRM, ticketing, calendars, finance, mapping); (D) MCP servers and connectors - Model Context Protocol servers, tools, and governed data gateways; (E) agentic handoffs - workflows, sub-agents, or orchestrated processes combining several tools. Step 4 is where the system decides what outside help is needed. Step 6, response-time tools: (A) normalization of results - parse and clean raw tool outputs into model-usable content; (B) computation and transformation - calculation, code execution, table building, chart generation, file conversion, synthesis; (C) verification and citation - freshness checks, source attribution, grounding, evidence assembly; (D) action execution - sending emails, creating tickets, updating records, scheduling tasks, triggering workflows, only when the system has the right permissions; (E) final packaging - response formatting, refusal handling, safety review, delivery. Step 6 is where tool outputs are verified, transformed, and woven into the final response. Tool families and their common purpose: skills and built-ins compute, transform, analyze, summarize; plugins, APIs, and MCPs access external systems, enterprise data, or actions; search, retrieval, and agents fetch context, ground answers, or orchestrate multi-step work. KEY TAKEAWAY: In a live LLM request, tools matter at two moments - when context is assembled and when results are integrated into a finished answer. Skills, plugins, APIs, MCP servers, retrieval systems, and agents all extend the request path without changing the underlying model. ## Card 04 - Context Assembly, End to End Subtitle: How an LLM request gathers, filters, ranks, and packs what the model gets to see. (If a colleague has time for exactly one card, send this one - it is the card most likely to change a buying decision.) Notes: Context assembly decides what the model actually sees. The available universe is large. Good answers often depend more on context quality than on raw model power. Permissions, ranking, and token budget all shape the final answer. Missing context, wrong sources, or conflicting context can degrade quality. Live request path: user request arrives; identity, roles, and app settings apply; candidate sources are gathered; context assembly and selection choose the most relevant, allowed, and useful pieces; ranking, filtering, and dedup; context-window packing fits the token budget; the model answers; the response is returned and logged. Where context comes from - six categories: (A) instruction stack - system instructions, developer/product instructions, policy overlays; (B) user-supplied input - prompt text, uploaded files, images, form fields; (C) conversation history - session turns, thread state, temporary working memory; (D) retrieval and evidence - search results, RAG documents, knowledge bases, citations and links; (E) tools and external systems - API outputs, calculators, code execution, enterprise connectors; (F) profile and preferences - saved preferences, locale and language, formatting preferences, access controls. Many sources may exist, but only a subset is selected and packed. From possible context to packed context, the funnel narrows at each layer: the available universe (everything the system could theoretically access) -> the permitted universe (only what identity, policy, and permissions allow) -> the retrieved universe (what search, RAG, tools, and connectors actually fetched) -> selected context (the pieces chosen as most useful for this request) -> the packed prompt (the final bundle that fits the token budget) -> model-visible context (what the model actually sees). Token budget and packing: the context window is finite and must hold the instruction stack, user input, conversation history, retrieved context, tool outputs, and reserved output space - the total must not exceed the window. The window is finite, so selection is unavoidable. Too much history: older items are summarized or dropped (keep key points, summarize the rest). Too many sources: chunks are ranked, deduplicated, or compressed (keep top-k, merge or summarize). Long tool outputs: trimmed or excerpted (filter, truncate, extract key data). Need space for the answer: output tokens are reserved in advance. Common failure modes: the right source exists but is never retrieved (query mismatch, poor metadata, index gaps, retrieval limits); a source is retrieved but a better source outranks it (weak ranking signals, noisy records, mis-weighted relevance); good evidence is packed but conflicting evidence is also packed (the model must reconcile sources); context is stale, redundant, or low-signal; permissions block the most relevant data. A weak answer may reflect weak context assembly, not a weak base model. KEY TAKEAWAY: Context assembly is the hidden engine of modern AI systems - it determines what evidence, instructions, and constraints reach the model before it answers. Without strong context assembly, answers are generic, shallow, dated, and prone to hallucination. With it, answers are grounded in the right sources, current, tailored to the user and role, more useful in the enterprise, and less likely to be irrelevant. ## Card 05 - The Context Window Is Not Memory Subtitle: What persists, what is temporary, and what the model actually sees during a request. People often say a model "remembers" something, but several different systems are involved. Model weights, the active context window, external memory stores, and logs each behave differently. Notes: The context window is temporary working memory, not long-term memory. Weights are not a transcript of your chat. External memory must be retrieved to matter. Persistence depends on the application, not just the model. Four kinds of memory-like state: (1) model weights - learned parameters from training; persistent and stable across the model; (2) context window - a temporary working set for this request only; (3) external memory or retrieved store - saved notes, vector stores, user profile, enterprise knowledge, conversation summaries; (4) logs and application state - operational records, audit trails, tool state, thread metadata. What survives across requests: model weights persist (locked, global to the model, not updated by a live request); the context window exists only for the single request; retrieved documents are per-request; saved memory and profile persist across sessions if the application saves them; application state and logs persist at the thread, workspace, or system level. How a chat thread actually works: recent turns are kept in full; older turns may be summarized or dropped; a compressed summary of earlier conversation, plus facts and preferences stored externally, can be re-injected. Each live request is assembled from system instructions, recent turns kept in full, a compressed summary, and retrieved memory or context. What "the model knows" can mean: (A) learned in weights - broad patterns, language, and concepts from training; (B) present in the context window - specific instructions, the current conversation, and evidence in this request; (C) retrieved from external memory - saved profile, documents, or knowledge fetched and injected now; (D) stored in app state - thread metadata, tool state, workflow preferences, user settings. If something is not in weights or in the assembled context, the model cannot reliably use it. Common confusions: "It remembered my preference" - the app may have injected saved preferences. "It forgot my earlier point" - it may have fallen out of the context window. "It knows our company policy" - only if trained on it, or, more likely, if it was retrieved or given. "The model learned from this chat" - usually false during normal inference. "The logs are the same as memory" - no; logs can exist without being fed back into the next prompt. Context window vs. long-term memory: the window is temporary (exists only for this request), limited (a finite token budget), constantly changing as the request builds, and already present in the request; long-term memory is durable across requests and sessions, large (bounded by storage, not tokens), updated when the application saves or syncs, and must be retrieved and injected to help. KEY TAKEAWAY: The context window is the model's temporary working set. Durable memory must live outside the model, and it only helps when the application retrieves and injects it. --- # Part 2 - Where the Answers Come From (Cards 06-10) Training, retrieval, infrastructure. ## Card 06 - An LLM Training Run, End to End Subtitle: How a model is trained, and what a knowledge cutoff date really means. Training is separate from live inference. A model's knowledge cutoff reflects the latest period represented in its trained parameters, not what it can fetch later with tools. Notes: Knowledge cutoff is about what is baked into the model. It is not a promise that every fact before that date is perfectly known. It does mean the model has no native awareness of events after that date. New native knowledge requires a later training or update cycle. The training run, eight stages: (1) data collection window - public, licensed, synthetic, and approved internal sources are gathered during a defined period; (2) data freeze and cutoff established - the training snapshot closes, and later events are not natively baked into this run; this freeze is the basis of the knowledge cutoff date; (3) filtering and curation - privacy review, deduplication, quality filtering, safety filtering, dataset balancing; (4) tokenization and dataset assembly - text, code, images, and other modalities are converted into training-ready examples; (5) pretraining run - large-scale optimization adjusts model weights across enormous volumes of examples; this is where general capabilities are learned; (6) post-training - alignment, instruction tuning, preference optimization, and targeted safety work; (7) evaluation and release decision - benchmark testing, red-team exercises, quality gates, approval checks; (8) deployment as a model version - the resulting weights are packaged and released for inference, then static until a later update. Inside the training run: it uses a bounded snapshot of reality, not a livestream; learning is probabilistic - the model absorbs patterns, not a literal transcript, compressed into weights; it uses massive compute, far heavier than answering a query; it passes through multiple quality, policy, safety, and evaluation gates; and it produces a versioned outcome - a specific model version with a defined native knowledge boundary. What the cutoff means: before the cutoff, the model may know many facts and patterns, but coverage is uneven and incomplete; at the cutoff, the model knows the latest period that could have influenced the base weights - a boundary, not a guarantee of completeness; after the cutoff, the base model has no native knowledge of later developments (breaking news is not in the weights); tool-augmented answers - search, retrieval, APIs, and connectors - can still provide fresher information during a live request; future updates to native knowledge arrive only in a later model version or training cycle. Base model vs. tool-augmented answer: the base model draws on trained parameters, cannot include post-cutoff facts, and does not change during the chat; a tool-augmented answer uses live retrieval, APIs, or external systems, can include post-cutoff facts if tools are used, and changes through the current request pipeline. KEY TAKEAWAY: A training run produces a fixed model version from a curated historical snapshot. Anything newer must come from tools, retrieval, or a later model release. ## Card 07 - Inside an LLM Training Run Subtitle: A deeper look at tokenization, and what really happens in steps 4 and 5. Training does not simply store raw files. It converts data into model-readable representations, predicts what comes next, measures error, and updates weights across many iterations. Notes: Training uses repeated examples, not one shot. Weights are learned numerical parameters, not a library of copied files. Inference uses frozen weights; training changes them. Tokenization depends on modality - words, image patches, video frames, audio chunks, or learned latent units. How raw data becomes model input. Text example: "To be or not to be" becomes tokens (To - be - or - not - to - be), then embeddings (vectors). Text tokenization maps strings into reusable subword units and then into vectors. Image example: an image is split into patches (visual tokens), each encoded as a vector. Video example: frames are sampled and clipped into temporal embeddings, with optional audio. Vision and video models encode patches, frames, motion over time, and sometimes audio. What the pretraining run learns - the loop: input tokens and vectors flow through a token embedding, transformer layers, and a prediction head to produce a predicted next token, patch, or pixel. Then: (A) prediction - the model applies current weights to produce a prediction; (B) target comparison - the system compares the prediction to the truth from the training example; (C) loss - a loss function turns the error into one number; (D) backpropagation - the system tracks how each weight contributed to the error; (E) weight update - an optimizer nudges weights so the next prediction is a little closer to the target. A weight is just a small number; across many layers, billions of weights collectively encode patterns, associations, and structure. Training-time vs. inference-time, defined clearly: tokenization breaks input into model-readable units in both; embeddings map each unit into a vector space, frozen during inference; weights are parameters that transform tensors through layers - updated in training, read-only during inference; the prediction loop runs over many examples in training but is NOT performed during a normal inference request; inference holds weights fixed and generates output from live input. Training changes weights; inference reads frozen weights. Classic LLMs vs. world and multimodal models: classic LLMs usually train on a text-first corpus, learn token-to-token associations, are strong at language, code, summarization, and reasoning over text, often extend to images via added encoders or multimodal adapters, and predict the next token. World and multimodal models train on text, images, audio, video, and sometimes action or state data; learn relationships across space and time; can model scenes, motion, and state transitions; are useful for robotics, simulation, video, agents, and planning; and predict the next token, frame, state, action, or latent representation. KEY TAKEAWAY: The core idea is the same across model types - represent the world in machine-readable form, predict what comes next, and improve weights through repetition. World models simply broaden what "next" can mean. ## Card 08 - RAG and Retrieval Subtitle: How external knowledge enters the answer. Retrieval-augmented generation does not retrain the model on the fly. It finds relevant outside information, filters it, and injects selected references into the context before the model answers. The grounding path: a user question arrives; query understanding and intent; search for candidates; retrieve candidates; rerank and filter; pack evidence; the model receives context with the candidates; it answers. Notes: RAG gives the model evidence at answer time. Retrieval does not permanently change weights. Permissions filtering is essential in enterprise settings. Better retrieval usually matters more than stuffing more raw context into the model. Citations reflect source-selection quality. How the source corpus is prepared: source documents (PDFs, wiki pages, tickets, product manuals, transcripts, database rows) go through parsing and cleanup (normalize text, remove boilerplate and noise, de-duplicate, detect language, mask PII and secrets), then chunking (typically 200-800 tokens per chunk), then embeddings, then a vector index with metadata such as source_id, doc_type, permissions, updated_at, and tags. How a live question retrieves evidence: the user question is rewritten and expanded; hybrid search runs both a keyword rank (BM25) and a vector rank (approximate nearest neighbor); top-k candidates are gathered; reranking orders them by relevance and applies filters; selected evidence is passed on. Why ranking matters: lexical match catches exact tokens; semantic similarity captures meaning beyond words; metadata boosts trusted chunks; recency favors newer chunks; permissions ensure only allowed content is used. What reaches the model: a context window packed to fit the token budget - system instructions, the user question, retrieved evidence (the selected chunks), citations and links, and reserved answer space. The model reads the selected passages, not the whole corpus. Why RAG helps - without retrieval vs. with strong retrieval: freshness - knowledge limited to the training cutoff vs. the latest documents and data; factual grounding - higher hallucination risk vs. answers backed by real sources; enterprise specificity - generic, public-world answers vs. your organization's docs, policies, and data; citation - hard to cite precise sources vs. can cite exact passages or links; relevance - generic vs. precise and actionable. Failure modes: the right source was never indexed (the system cannot retrieve what it cannot see); chunking split the key fact badly (a fact spanning chunks is answered poorly); retrieval finds similar but irrelevant passages (noise competes with the right evidence); permission filters remove the best chunks (weaker evidence is used); the model overgeneralizes from thin evidence (the answer goes beyond what is supported). RAG quality depends on source quality, chunking, ranking, permissions, and context packing - not just the base model. Training vs. RAG vs. fine-tuning vs. inference: training learns patterns from data into weights; RAG, at answer time, retrieves external evidence and injects it into the prompt; fine-tuning retrains on domain data to specialize behavior and style; inference generates an answer given the prompt and the provided context. KEY TAKEAWAY: RAG produces corpus-grounded answers from outside references without retraining. It is retrieval, selection, and context injection working together. ## Card 09 - Where Your LLM Prompt Goes Subtitle: What "the cloud" means when an LLM answers you. An LLM request does not go to one magical cloud. It is routed across network edges, regional control planes, and model-serving clusters in real data centers. Eight stages: (1) the user device sends the prompt - text, image, audio, or file; (2) internet and secure transport - DNS, TLS, and backbone routing move the request; (3) provider front door - authentication, rate limits, and abuse checks; (4) region and capacity routing - the platform chooses a viable region based on latency, capacity, reliability, policy, and sometimes data residency; (5) context and orchestration layer - system instructions, conversation context, prompt caching, optional retrieval, and tool routing are prepared; (6) model-serving cluster - a tokenizer plus inference servers run the model on GPUs or TPUs, weights are loaded into accelerator memory, a high-speed interconnect (NVLink/InfiniBand) links them, and tokens are generated; (7) post-processing and streaming - safety filters, citations and tool-output integration, logging and observability, and formatting, with tokens streaming back to the client; (8) return path - the answer travels back to the user. Notes: The cloud is a network of regions, zones, and data centers, not one place. A named LLM does not live on one server - providers replicate model weights across many accelerator hosts and often across multiple regions. Exact replica counts, rack locations, and live routing decisions are usually not public. The same model family can exist in many copies, shards, and versions at once. What lives in the data center: edge and control planes (API gateways, schedulers, traffic managers decide where the request goes); storage and memory (weights stored persistently and loaded into GPU/TPU memory); replicas, shards, and batches (split and replicated for throughput, latency, and failover); networking and cooling (high-bandwidth leaf-spine networks feed accelerators; CRAC/CRAH units or liquid cooling remove heat; redundant power distribution and UPS; NVMe storage for weights, cache, and logs). Cloud scale, public footprints as of May 2026: Google Cloud - 42 regions, 130 zones, 200+ edge locations, about 10 million km of fiber; AWS - 39 geographic regions, 123 Availability Zones; Azure - 70+ regions, 400+ datacenters. (These figures describe cloud infrastructure, not the number of model replicas.) What the data center spends per prompt: electricity powers accelerators, CPUs, memory, networking, and cooling; water can be used directly for cooling and indirectly through electricity generation, depending heavily on cooling design and location; carbon depends on grid mix, utilization, cooling efficiency, and workload type. Currently disclosed simple-text-prompt benchmarks: a Gemini Apps median text prompt is 0.24 Wh, 0.26 mL of water, and 0.03 g CO2e; a ChatGPT average query is about 0.34 Wh and about 0.32 mL of water. Not all prompts cost the same - per the IEA, video generation, reasoning, and agentic tasks can consume hundreds or thousands of times more energy per query than simple text generation. What is public vs. not: cloud regions and zones are public, and model family and version are often visible; the exact model replica count, the exact rack or data-center placement, and the live route for your specific request are usually not public - they vary with demand, failover, maintenance, security, latency, load, policy, and capacity. KEY TAKEAWAY: Your prompt typically travels to a real regional data center where replicated model servers generate tokens on accelerators. The work is distributed, physical, and resource-intensive, even when the per-prompt footprint is small. ## Card 10 - A Prompt Footprint, in Human Terms Subtitle: How current AI footprints compare with everyday things. A simple text prompt is usually small. At scale, the total is not. Disclosed reference points: a Gemini Apps median text prompt - 0.24 Wh energy, 0.26 mL water, 0.03 g CO2e; an OpenAI-disclosed ChatGPT average query - about 0.34 Wh and about 0.32 mL water, with carbon varying with the electricity mix; a heavier disclosed inference case - Mistral Large 2 for a 400-token response - about 45 mL water and 1.14 g CO2e (lifecycle methodology differs, so treat this as a heavier-use-case marker, not a perfect apples-to-apples match). Notes: 2025-2026 direct disclosures place simple text prompts far lower than many older viral estimates. Prompt footprint varies with model size, output length, reasoning depth, tools, images or video, batching, utilization, and grid mix. Data-center water draws depend on cooling design, local conditions, and the water intensity of the local grid. Billions of small prompts still add up. Water - prompt ladder (simple-text benchmark): 1 prompt ~ 0.26-0.32 mL; 100 ~ 26-32 mL; 1,000 ~ 260-320 mL; 10,000 ~ 2.6-3.2 L. Everyday comparators include a pair of jeans at about 7,600 L (roughly 24-29 million prompt equivalents); at societal scale, U.S. golf facilities applied about 1.63 million acre-feet of water in 2024. Water use depends strongly on data-center cooling design, local climate, and the water intensity of electricity. Energy - prompt ladder (simple-text benchmark): 1 prompt ~ 0.24-0.34 Wh; 100 ~ 24-34 Wh; 1,000 ~ 240-340 Wh; 10,000 ~ 2.4-3.4 kWh. Everyday comparators: one median text prompt is similar to less than about 9 seconds of television; a sheet of paper or a cup of coffee at about 0.05 kWh ~ 150-210 prompt equivalents; manufacturing a smartphone at about 70 kWh ~ 200,000-300,000 prompt equivalents. Energy per task has fallen fast, but richer AI uses can climb back sharply. Carbon - per-prompt range: a simple-text prompt on clean infrastructure ~ 0.03 g CO2e; the same prompt on a more carbon-intensive grid is roughly a few percent of a gram; a heavier disclosed inference case ~ 1.14 g CO2e. Everyday comparators (illustrative): a short email ~ 0.3-4 g CO2e; a cup of coffee ~ 25-63 g CO2e. Carbon estimates vary by method, attachments, device use, and reading time; use them as fuzzy order-of-magnitude comparisons, not precise counts. How to shrink the footprint: (A) use the smallest model that can do the job; (B) ask for shorter outputs when you do not need long prose; (C) reuse context and batch work instead of prompting repeatedly; (D) prefer retrieval and precise instructions over brute-force regeneration; (E) run heavy workloads in cleaner, more efficient regions when you have that choice. What is small per prompt becomes large at scale: water (drops per prompt -> liters to millions of liters across heavy aggregate use); energy (fractions of a watt-hour -> meaningful data-center load when usage compounds); carbon (tiny on clean infrastructure -> material when multiplied by model scale and dirtier grids). KEY TAKEAWAY: One text prompt is usually small in water, energy, and carbon. The real environmental story is scale - billions of prompts, heavier multimodal tasks, and the physical cost of the data centers behind them. --- # Part 3 - Why You Can Trust Some AI Systems (Cards 11-15) The trust layer. ## Card 11 - Agents Subtitle: From one answer to multi-step work. A basic chatbot produces one reply. An agentic system interprets a goal, decides on steps, uses tools, manages state, checks results, and may loop until it completes the task or asks for help. Notes: Agents pursue goals, not just one-turn answers. Tool access spans multiple steps. Tool use, persistence, and verification define agentic value. A good agent often asks for approval before consequential actions. Agents maintain memory, can recover from failure, and can press ahead. The agent loop: (1) a goal arrives; (2) understand the task and constraints; (3) plan subtasks; (4) select tools; (5) execute subtasks; (6) observe results; (7) verify and retry; (8) deliver the outcome or request approval - looping back as needed. What an agent adds beyond chat: time horizon - one-turn, immediate reply vs. multi-step work over a longer span; tool use - minimal vs. calls to tools, APIs, and systems; memory and state - stateless or short context vs. state maintained across steps and sessions; ability to act - provides information vs. takes actions in systems on your behalf; need for approval - not typically needed vs. often required for sensitive or irreversible actions; observability - one message in, one message out vs. rich logs of steps, tools, outcomes, and decisions. Anatomy of an agentic run: a planner; working memory and state (facts, context, outcomes); a task list; a tool registry (tools, APIs, skills, permissions); an execution engine (runs steps, calls tools); a verifier/evaluator (checks results, detects issues); a human or parent agent (approves, denies, or requests changes); and a final report (summary, artifacts, recommendations). A worked example (account briefing): (A) understand the goal - confirm account basics, tenant, and activity (directory tool); (B) pull CRM and related records - open cases, tickets, customer history (CRM tool); (C) search open issues and recent emails - knowledge base, open issues, recent threads (KB search, email search); (D) summarize risks and opportunities - identify key risks, opportunities, and stakeholders (analysis); (E) draft output - write a briefing with recommended actions and next steps (writer, template). Control points: (A) identity and permissions - which systems, data, and roles the agent may access; (B) tool restrictions - which tools, API scopes, and rate limits it may use; (C) verification - grounding checks, validation, tests, consistency rules; (D) approval gates - human confirmation for high-risk actions, write-backs, sends, payments; (E) logging and observability - step logs, inputs and outputs, decisions, metrics, alerts. Agent quality is not just model quality - it depends on planning, tools, state management, and control points. Failure modes: a bad plan (wrong steps or sequence); the wrong tool or scope; stale state (acting on outdated or incomplete information); no verification (errors go undetected); action without consent (acting without required approval); an infinite loop (looping or retrying without progress). KEY TAKEAWAY: Agents wrap models in a control loop - planning, tool use, memory, verification, and approvals. ## Card 12 - Permissions and Data Boundaries Subtitle: Same prompt. Different answer. Different identity. Access, roles, and policies define what the model can see - and therefore what it can safely say. Consider one prompt, the same for everyone: "Summarize the customer escalation for ACME Co." Notes: The model does not decide what you can see - identity, role, and policy do. Same prompt, different context, different safe answer. Effective context may be limited by access, classification, residency, legal hold, and role. Redaction and refusal should happen before sensitive content is exposed, not after. Good permissions plus good design preserve trust, privacy, and auditability. Five identities, the same prompt, different effective context: Alex (Sales Rep) sees the public customer profile, open opportunities, the product catalog, and a case summary with no PII. Riley (Support Lead) sees full ticket history, internal notes, attachments, and customer emails. Jordan (Legal Counsel) sees contracts and NDAs, legal holds, compliance notes, and redacted concerns. Morgan (Finance Analyst) sees billing and invoices, credit status, payment history, and cost impacts. Sam (External Partner) has partner-portal access and shared docs only - no internal notes, no billing data, no legal holds. Resulting model responses (examples): Alex gets a renewal-risk framing about product reliability and delivery timing; Riley gets a root-cause framing tied to a firmware update with a fix in progress; Jordan gets a potential-SLA-breach and data-handling framing; Morgan gets a past-due invoice and cash-flow-forecast framing; Sam gets a redaction - "Cannot share - outside your permitted scope," with an offer to confirm an open escalation and share partner-approved updates. Failure modes: (A) over-permissioned roles see more than they need; (B) stale group membership leaves old access grants in place; (C) copy-paste leakage moves a safe answer into an unsafe place; (D) RBAC misconfiguration exposes the wrong column; (E) shadow-IT bypass uses unofficial connectors that skip controls; (F) redaction-too-late filters sensitive content only after the exposure risk; (G) audit-log gaps let actions happen without a reliable trace. Quantitative ladder (illustrative operational scale): at 1,000 requests/day, roughly 1,000 permission checks, about 20 redacted outputs, about 1 audit exception; at 10,000/day, about 180 redactions and about 6 exceptions; at 100,000/day, about 1,400 redactions and about 25 exceptions; at 1,000,000/day, about 14,000 redactions and about 160 exceptions. Exact rates vary by use case, policy strictness, and user mix. Why this matters: least privilege (users see only what they need to do their job); risk reduction (limits accidental exposure and leakage); policy enforcement (applies classification, residency, and legal holds); auditability (every answer is traceable to the context allowed). KEY TAKEAWAY: Answer quality is only as good - and only as safe - as the data you allow in, the policies you enforce, and the identity behind the request. ## Card 13 - Routing and Model Selection Subtitle: The right request, to the right system, for the right reason. A router evaluates the request and selects the best path before any model runs. It reads routing signals - intent, complexity, data sensitivity, modality, latency need, cost sensitivity, safety/risk, user and role, the task needed, and policy/region - then makes a routing decision (select the reasoning path, enable compute tools as needed, retrieve relevant data via RAG or connectors, apply policy and safety filters, return the final answer with sources and trace) and dispatches to a selected system: a small/fast model (low cost), a standard model (balanced), an advanced reasoning model (deep analysis), a code/compute tool, a retrieval/connector path, or human review (high-risk approval). Notes: The router sits below model execution. One request can take many different paths under different constraints. Routing considers task, risk, cost, latency, modality, and permissions. Model choice is a system decision, not a user habit. What is the router? A rule engine (explicit if/then logic and thresholds), a classifier model (predicts the best path from request features), or an LLM-as-judge (the model reasons about the request and picks). Many real systems combine all three. Same query, three routes: for "Create a quarterly forecast for ACME for next year," a cost-optimized route parses and classifies, checks, and runs a small model; a latency-optimized route does shallow retrieval on a fast path with a standard model; a security/risk-restricted route checks sensitivity, masks and filters, adds a policy step, and dispatches to an advanced model plus human review. Quantitative ladder (illustrative): a Fast tier costs about $0.001 per query, under 500 ms, about 200 tokens per response; a Standard tier about $0.04, roughly 500-2,500 ms, about 700 tokens; an Advanced reasoning tier about $0.30, roughly 2,500 ms-7 s+, about 2,000 tokens. Actual values vary by model, run mix, and prompt shape. Failure modes: (A) a trivial query routed to an expensive system wastes cost and adds latency; (B) a latency-sensitive query routed to a slow path misses response-time objectives; (C) region-restricted data sent off-region violates residency/compliance rules; (D) routing loops consume resources and stall completion; (E) fallback failure means no safe degradation and the user sees an error; (F) cost drift from default routing lets spend creep up over time. Examples of system paths: fast QA (small model), deep analysis (advanced reasoning model), image/OCR (vision path), code/compute (compute path), semantic search (retrieval path), external tool (tool/API path), multi-step (agent workflow), and human review (approval path). KEY TAKEAWAY: Modern systems choose the best model, tool, or agent for each request automatically - instead of using one model for everything. Model choice becomes a job, not a habit. ## Card 14 - Evaluation: From Vibes to Evidence Subtitle: Good AI is not a demo. It is measured behavior at scale. Evaluation is a continuous loop to test, measure, learn, and improve. Its six stages: (1) define what good looks like - accuracy, helpfulness, safety, groundedness, privacy, latency, cost; (2) build evaluation sets - golden sets (curated), edge cases (hard and rare), red-team sets (adversarial); (3) run and judge - automated judges (exact match/rules, factual consistency, policy compliance, PII leakage) plus human judges (spot-checks and problem cases that rate, annotate, and give feedback); (4) human review; (5) score and analyze (metric, score, trend); (6) decide and act - ship, stop, roll back, update, and refresh regularly. Notes: Measure behavior, not a demo - what you test is what you ship. Both instrument and human judgment matter. Eval sets drift at the edges; add tests and keep coverage; refresh regularly. One metric never tells the full story - use a balanced scorecard. Feed results back into the loop that updates models, data, prompts, tools, and policies. Scorecard example (what good looks like): accuracy ~92% (answers match ground truth); groundedness ~87% (answers supported by sources); citation quality (useful, relevant citations); safety ~99.4% (no harmful or unsafe content); PII leakage ~0.3% (how well sensitive data is contained); latency ~1.2 s (speed of response); cost ~$0.012 per 1K tokens (cost efficiency). Failure modes: Goodhart drift (optimizing the metric, not the behavior - good on paper, underperforms in the real world); train-on-test contamination (false confidence); judge-model bias (the judge is wrong too - inflated scores); missing the long tail (happy-path only - systematic errors on edge/rare cases); gaming the score (prompts engineered to pass eval, not to serve users); missing regressions (a new release breaks an old behavior you do not catch). Quantitative ladder (typical ranges, tuned to your domain): a prototype/early stage uses about 50 golden prompts at roughly $0.001-$0.01 per run; pre-production uses about 500 prompts at roughly $0.01-$0.05 per run; a production gate uses 2,000+ prompts at roughly $0.02-$0.30 per run, with rising coverage thresholds (for example, >=70% overall early, >=85% pre-production, >=95% on policy-critical cases at the gate). Eval-type taxonomy: factual (is it true and grounded? - groundedness, citation quality, hallucination rate; methods: exact-match, source checks, retrieval audits, judge model); policy and safety (is it safe and compliant? - PII leakage, harmfulness, refusal correctness; methods: red team, policy tests, adversarial prompts, manual review); user experience (is it helpful and pleasant? - helpfulness, tone, latency, satisfaction; methods: human ratings, A/B tests, behavior signals); business outcome (did it work? - outcome tracking, experimentation, conversion and business KPIs). Evaluation principles: test what matters (outcomes that affect the user); use representative data (the happy path, the hard path, and the weird path); combine automated and human judgment (each has blind spots); track over time (trends catch slow drift); make it actionable (evaluation should drive changes, not just reports); earn trust with evidence. A continuous feedback loop runs from user feedback and logs/traces through error analysis and regression checks to re-running evaluations and better outcomes. KEY TAKEAWAY: Evaluation is an investment. It pays for itself by preventing bad releases, reducing risk, and improving outcomes. Measure the right things, measure them often, and act on what you learn. ## Card 15 - The Enterprise AI Control Plane Subtitle: The layer between people, models, and company data. Governed access. Safe actions. Measurable outcomes. The control plane sits between three things: users and surfaces (where requests originate - people such as employees, developers, and customers; applications such as chat apps, productivity suites, and custom internal apps; and agent workflows); the control plane itself (which enforces policy, orchestrates capability, and provides guardrails); and the models, tools, and systems where work actually happens (foundation models; retrieval systems and RAG connectors; connectors and tools; and enterprise data systems such as HR, ticketing, CRM, file storage, and internal APIs). The control plane's functions, in order: (1) identity and authentication - who is calling; (2) permissions and role-based access - what they may do; (3) input moderation - what comes in; (4) prompt templates and system instructions - how to shape the request; (5) skills registry - packaged units of capability; (6) model zoo - which model handles it; (7) tool registry - which capabilities exist; (8) data connectors - which systems may be reached; (9) policy and safety filters - what is allowed; (10) human approval - when needed; (11) evaluation gates - is the output acceptable; (12) observability and logging - every request tracked; (13) cost controls - budget guardrails per request and per gate. Notes: The model is not the product; the skills are the product. The control plane is the only layer that knows who is calling, what they are doing, and which skill is doing it. Mature enterprises govern skills the way they manage code. A skill outlives every model it runs on. What is the control plane? An LLM gateway (a central control point for all AI traffic); a tool gateway (governs tool and connector access; enforces scopes, classification, and audit); and an agent/skill plane (orchestrates the skills, instructions, and tools available to an agent - a skill is what an agent can do, packaged, governed, and reusable). The model is interchangeable, the tools are extendable, the skills are where institutional knowledge lives, and real enterprise stacks need all three. Same operation, three enforcement paths (example: update employee compensation in the HR system): a read-only path runs request -> identity -> permission -> retrieve -> tool -> result; an approved write path runs request -> identity -> permission -> policy -> approval -> tool -> result; a restricted path runs request -> identity -> permission -> policy -> denied. Anatomy of a skill: a description (what triggers it); instructions (how to do the work, step by step); scope (which users, roles, and regions); tools (the tools and connectors it may use); permissions (what data it can touch); governance metadata (owner, data class, approval route, last reviewed); and telemetry hooks (what gets logged and measured). Failure modes: prompt injection (hidden instructions in content -> unintended actions -> data exfiltration, unsafe writes); scope creep (a skill does more than approved -> permissions broaden silently -> compliance gaps); stale governance (no owner, no review -> the skill drifts from intent -> untracked risk); cascading concurrency (one skill triggers another -> hard-to-trace chains -> runaway cost); single point of failure (gateway down -> all AI traffic stops); missing telemetry (no logs, no traces -> blind spots, no accountability). Why this matters: trust (every action is auditable and on-rails); risk reduction (agents act within restrictions); agility (features are governed, not eliminated); portability (skills travel across models and tools, with audit and observability); composability (governance no model release can break). KEY TAKEAWAY: Models are interchangeable. Tools are extendable. Skills are where institutional knowledge lives. The control plane is where all three come together so your enterprise can move fast and stay governed. --- ## The Argument This Guide Defends The conversation about AI in 2026 keeps treating the model as the strategic unit. It is not. The model is the smallest decision an organization will make about AI this decade. The model choice will turn over every six to twelve months. The system around the model - the request runtime, the assembly line that turns a question into an answer, the training corpus, the retrieval layer, the physical infrastructure, the per-prompt footprint, the agent loops, the identity boundary, the routing layer, the evaluation gates, the control plane - determines whether the AI investment pays back, falls over, or ends up in a regulatory disclosure. The bottleneck has moved. The model is no longer the rate-limiting step. The system around it is. Models are interchangeable. Tools are extendable. Skills are where institutional knowledge lives. The control plane is where all three become a system you can trust. These cards are the marks. They will not save anyone from a bad procurement decision on their own. But for the people in the room who have to decide, they are the vocabulary required to argue. The bird is no longer the bird. It is a system you can name, in fifteen pieces, with the field guide on the bench. --- ## Receipts and Further Reading The four-essay series this guide came from: - How AI Actually Works: A Field Guide for People Who Make Decisions. Beyond Reason, June 9, 2026. The manifesto. https://promptedbyeric.substack.com/p/how-ai-actually-works-a-field-guide - What Happens When You Hit Send. Beyond Reason, June 16, 2026. Part 1 - Cards 01-05. https://promptedbyeric.substack.com/p/what-happens-when-you-hit-send - Where the Answers Come From. Beyond Reason, June 23, 2026. Part 2 - Cards 06-10. https://promptedbyeric.substack.com/p/where-the-answers-come-from - Why You Can Trust Some AI Systems and Not Others. Beyond Reason, June 30, 2026. Part 3 - Cards 11-15. https://promptedbyeric.substack.com/p/why-you-can-trust-some-ai-systems All four are at https://promptedbyeric.substack.com. Named receipts cited across the series: - Anthropic - Constitutional AI: Harmlessness from AI Feedback (2022, refined through 2026). Trust-by-construction in foundation models. https://arxiv.org/abs/2212.08073 - Anthropic - Agent Skills specification (October 2025). The packaging unit this series builds on. https://docs.claude.com/en/docs/agents-and-tools/agent-skills/overview - OpenAI and Google - disclosed per-query energy and water estimates, 2025-2026. The basis for Card 10. - US Department of Energy - Data Centers and Servers. Utility-grade data on US data-center power and water consumption. https://www.energy.gov/eere/buildings/data-centers-and-servers - Model Context Protocol (MCP) - open standard for tool, resource, and connector access in agent systems. https://modelcontextprotocol.io - Agent-to-Agent (A2A) Protocol - open standard for inter-agent communication. - Gartner - Market Guide for Guardian Agents (2026). The arrival signal for the control-plane conversation in the enterprise. - Replit, July 2025 - agent database deletion incident. The canonical 2025 receipt for an agent acting beyond its allowed operations. https://futurism.com/the-byte/replit-ceo-ai-coding-database - Cursor, April 2025 - support-bot hallucination. The canonical 2025 receipt for an evaluation gate failing. https://news.ycombinator.com/item?id=43683010 - SHL0MS, May 12, 2026 - Monet prank on X. The cultural lede for Part 2. https://futurism.com/artificial-intelligence/real-monet-ai-chaos - Common Crawl - the public web archive that supplies a meaningful fraction of the training corpus for every major foundation model. https://commoncrawl.org - The New York Times v. OpenAI - December 2023 lawsuit defining the contested terrain of training-data use, ongoing through 2026. https://www.nytimes.com/2023/12/27/business/media/new-york-times-open-ai-microsoft-lawsuit.html - Edward Tufte - The Visual Display of Quantitative Information (Graphics Press, 2001). The visual grammar this guide borrows from. https://www.edwardtufte.com/tufte/books_vdqi Other Beyond Reason pieces threaded through the series: - Skills Are the New Software (March 10, 2026). https://promptedbyeric.substack.com/p/skills-are-the-new-software - Knowledge Work Is Code (April 15, 2026). https://promptedbyeric.substack.com/p/knowledge-work-is-code-how-to-build - AI Truth Serum (August 26, 2025). https://promptedbyeric.substack.com/p/ai-truth-serum - AI Not a Bubble (September 25, 2025). https://promptedbyeric.substack.com/p/ai-not-a-bubble --- ## About the Author Eric Porres is Chief AI Officer at Logitech, where he leads the company's AI strategy and platform. He is the author of Beyond Reason, a Substack about AI and the economy for practitioners. Before Logitech he was a four-time CMO across $40M-$400M B2B businesses, including a company he helped take public. He holds a philosophy degree from Duke, a fifth-degree black belt in ninjutsu, and an unusually strong opinion about how to triage email at 6 AM. He lives in the New York area with his partner and their children. The dog is named Coco. Contact: eric@porres.com - https://promptedbyeric.substack.com - https://porres.com --- ## Colophon The AI Field Guide. Beyond Reason, Volume One. Edition 1.0 - published July 10, 2026. Card design by Eric Porres. Composition adapted from Edward Tufte, particularly The Visual Display of Quantitative Information (Graphics Press, 2001) and Envisioning Information (1990). The four-essay series this guide came from is at https://promptedbyeric.substack.com. Licensed CC BY 4.0. Share, print, modify, attribute. Wrapping pages set in Times Roman and Helvetica. Card display lettering hand-drawn for the series. Made with restraint. --- ## Get the guide - Web home: https://porres.com/aifieldguide/ - Full PDF (22 pages, 8.5 x 14 in, CC BY 4.0): https://porres.com/aifieldguide/assets/ai-field-guide-2026-beyond-reason-eric-porres.pdf - This text file: https://porres.com/aifieldguide/llms-full.txt - Index for LLMs: https://porres.com/aifieldguide/llms.txt (c) 2026 Eric Porres - porres.com - Beyond Reason - Licensed CC BY 4.0.