An advisor does not need to read a transformer architecture paper to use AI well. An advisor does need to understand six mechanical concepts — tokens, prompts, context window, training data, temperature, and the stochastic nature of next-token prediction — because each one shows up in the daily workflow as the precise reason an AI tool produced the answer it produced. The advisor who understands the mechanics chooses better vendors, writes better prompts, catches more errors, and writes WSPs that actually survive a 2026 FINRA exam. The advisor who treats the model as a magic box gets surprised when the magic produces a confident, plausible, and wrong recommendation that the firm now owns under Reg BI Care Obligation §240.15l-1(a)(2)(ii).

A 60-Page eMoney Plan, Translated Through Each Mechanic

Open a representative review-meeting prep workflow. The advisor wants a one-page summary of the Sandersons' 60-page eMoney plan. The plan contains a base-case Monte Carlo (88% success), an asset allocation reflecting a 60/40 IPS, a tax-projection assuming Social Security at full retirement age, a college-funding section showing the 529 on track for the first grandchild and behind for the second, an estate section showing the revocable trust funded at 70% of net worth, and a beneficiary review section flagging two outdated 401(k) designations from prior employers. The advisor types: "Summarize this plan in one page and surface the three highest-leverage planning conversations to raise at the 9:30 meeting."

Eleven seconds later an answer appears. The answer mentions the IRMAA cliff the IPS doesn't address, recommends delaying Social Security on the higher earner, flags the two outdated 401(k) designations, and suggests revisiting the second grandchild's 529 funding pace. The answer looks confident. It is — at the level of the workflow — useful. It is also entirely the product of six mechanical operations the advisor did not see, did not configure, and did not supervise. The rest of this lesson walks each operation in the order it actually runs inside the model, with the advisor's prep workflow as the lens.

Tokens: The Atomic Unit AI Actually Reads

The first mechanical fact to internalize: language models do not read words. They read tokens, which are roughly word-fragments. The English word "advisor" tokenizes to a single token in most modern tokenizers. The phrase "Sandersons" tokenizes to two: "Sand" + "ersons". The phrase "401(k)" tokenizes to three or four tokens depending on the vendor's tokenizer ("401", "(", "k", ")") or fewer if the tokenizer was trained on enough wealth-domain text to treat it as a single common pattern. A typical 60-page eMoney plan is roughly 20,000–30,000 tokens; a long-form Zocks transcript of a 60-minute meeting can run 8,000–14,000 tokens; a complete 1040 PDF after OCR is in the 1,500–4,000-token range; an LLM's typical response is 200–1,500 tokens.

The first practical consequence for an advisor: every token costs money on the vendor's bill (whether passed through as per-token pricing or absorbed into a flat seat fee) and every token competes for the model's context window. The second practical consequence: tokenization can break technical strings. "§240.15l-1(a)(2)(ii)" tokenizes into a sequence the model has seen rarely or never in training; expect lower fidelity on confidently reciting the exact subsection number than on paraphrasing the duty it imposes. The third practical consequence: counting tokens is not counting words. A long uploaded estate plan can blow past a vendor's per-call limit even when the page count looks modest, especially when the document contains heavy tabular content, scanned image text after OCR, or footnotes in a non-standard font.

The analog for an advisor: think of tokens like the bid-ask spread on a thinly-traded preferred — they're the unit you actually transact in, even though you naturally talk in dollars. You don't have to compute tokens by hand. You do have to understand that they exist, that they shape the model's economics and limits, and that they explain why the long uploaded plan was truncated silently at a certain point in the response generation.

The Prompt and the System Prompt: Two Layers You're Always Sending

The advisor types a prompt: "Summarize this plan and surface three conversations." What the model actually receives is two layers stacked together: a hidden system prompt the vendor wrote, plus the advisor's user prompt. The system prompt sets the model's behavior — tone, refusal patterns, response format defaults, the list of allowed tool calls, the prohibition on producing direct legal advice, and any wealth-vertical hardening (e.g., "do not produce a specific recommendation; produce a draft for advisor review"). The user prompt is the question the advisor typed.

For a wealth-vertical wrapper like Jump or Zocks, the system prompt is doing significant work: instructing the model to format output in the advisor's house style, to flag NPI before responding, to refuse certain categories of content, to add the firm's disclosure language at the end of certain outputs, and to constrain its tool calls to a vetted list. For a generic enterprise LLM (Microsoft Copilot, OpenAI Enterprise, Google Gemini Enterprise), the system prompt is more permissive and the burden of constraint shifts to the user prompt — which is why a firm using a generic LLM in advisor work needs its own house system prompt locked into every session, as developed in L2 Ch8.1.

The practical implication for the advisor is twofold. First, two firms using the same underlying model can get materially different outputs because of different system prompts; "we use GPT-X" is a meaningless statement about behavior. Second, the firm's prompt library — the locked system prompts for the junior advisor persona, the senior advisor persona, the compliance reviewer persona, and the CCO persona (L3 Ch9.1) — is the practical surface where the firm encodes Marketing Rule discipline, Reg BI verification posture, citation requirements, disclosure boilerplate, and the "draft, do not recommend" framing into every interaction. That library is a Rule 4511 record, a Rule 3110 supervisory artifact, and a Marketing Rule 206(4)-1 substantiation file all at once.

The Context Window: The Whiteboard Has an Edge

The context window is the total amount of token-content the model can hold in mind at once — the system prompt, the user prompt, any uploaded documents, prior turns of conversation, and the response the model is generating. As of mid-2026, mainstream advisor-vertical tools sit on models with context windows ranging from roughly 128,000 tokens at the low end (still ample for a typical advisor session) to 1–2 million tokens at the high end (enough to load the entire eMoney plan, the 1040, the trust binder, the IPS, and the last three meeting transcripts in one call). The vendor's wrapper, however, may impose its own ceiling well below the model's theoretical limit for cost-control reasons; never assume the model's headline number is the number you actually have.

When the input plus the response would exceed the window, something has to give. Most vendors handle this silently by truncating the input — either dropping older conversation turns ("rolling context") or cutting off uploaded documents at the limit and never telling the advisor. The result, for an advisor uploading a 90-page combined plan-plus-trust binder, is that the model may answer based on the first 60 pages and confidently summarize as though it read the whole document. The advisor's verification reflex applies here exactly: every AI-touched summary needs a check that the input was fully consumed. Most modern enterprise tools surface a "tokens used" indicator; learn where yours lives.

The advisor analog: think of the context window like the whiteboard in your conference room. You can write on it as much as you want until you run out of space, and then your next sentence either pushes the earlier sentence off the top edge or you just stop writing. Some tools warn you. Some don't. Most do not, and assume you'll notice.

Training Data and the Cutoff Date: Why the Model Has Yesterday's News

An LLM's knowledge comes from its training corpus — a snapshot of internet text, books, code, and other content collected up to a specific cutoff date. After the cutoff, the model knows nothing without external help. As of May 2026, mainstream models from the major vendors have cutoffs ranging across late 2024 through early 2026, depending on vendor, model variant, and how recently the model was refreshed. The wealth-specific consequence is severe: a model with a January 2025 cutoff does not know the January 2026 SEC staff FAQs on third-party ratings, the FINRA 2026 Annual Regulatory Oversight Report sections on agentic AI, the May 2026 Reg S-P amendment effective dates for smaller advisers, the OBBBA-era dual regime for IRC §1202 QSBS, the 2026 contribution limits, the 2026 Social Security maximum taxable wage base, or the most recent FINRA AWC dockets.

The fix is not to hope the model knows. The fix is one of three patterns. First: ask the model what it knows and trust it on stable content (the structure of Reg BI, the mechanics of a 72(t) SEPP, the general shape of the Marketing Rule) — these don't change year to year. Second: provide the up-to-date content in the prompt itself (paste the relevant SEC staff FAQ, the latest IRS publication, the firm's updated WSP) — this is the simplest version of retrieval-augmented workflow. Third: use a tool with explicit retrieval or web-search integration (more enterprise tools added this in 2025) and verify the cited source.

The practical workflow consequence is that for any factual claim that depends on post-cutoff information — a 2026 contribution limit, a recent enforcement matter, a current IRMAA threshold, the latest FINRA AWC — the advisor verifies against an authoritative current source before the artifact leaves the screen. This is the Cardinal Rule's source-system check (L1 Ch2.3) applied to the date dimension specifically.

Temperature, Stochasticity, and Why the Same Prompt Twice Gives Different Answers

Here is the property most advisors discover by accident and many never fully internalize: an LLM is stochastic by default. Run the same prompt twice and you may get two different answers. The control that governs how much variation you get is called temperature, and it is — almost always — set by the vendor in the system prompt, not exposed to the advisor.

Temperature is a number between 0 and 2 (most vendors clamp to 0–1). At temperature 0, the model picks the highest-probability next token at every step, producing the most deterministic and most repetitive output. At temperature 1, the model samples from the probability distribution at every step, producing more varied and more creative output. Most advisor-vertical tools default to a temperature in the 0.3–0.7 range — high enough to feel natural, low enough that the same prompt produces similar but not identical answers.

The Reg BI consequence is the part advisors most often miss. Stochastic output means two materially identical client situations can receive two materially different AI-drafted recommendations on Tuesday and Wednesday, simply because the model sampled different tokens. The fiduciary problem is not that the model gave a different answer — different answers can both be defensible. The fiduciary problem is that the advisor who relied on either answer without verifying the underlying analysis cannot rebuild the reasoning that produced it. The Care Obligation under §240.15l-1(a)(2)(ii) requires the broker-dealer or associated person to exercise reasonable diligence, care, and skill to understand the potential risks, rewards, and costs of the recommendation. "The AI said so" is not understanding. The verification protocol (Cardinal Rule, L1 Ch2.3) and the workflow design pattern (L3 Ch1.2 Human-AI Handoff) both exist specifically to convert stochastic drafts into Reg BI-supportable recommendations.

The practical operational consequence: for tasks where consistency matters more than creativity (Reg BI rollover memos, FAQ answers, compliance disclosures, standard concept memos), the firm's locked system prompt should request a low-temperature posture and the firm's WSPs should require human verification of the underlying analysis. For tasks where varied creative drafts are useful (marketing commentary, social posts for L4 Ch7), higher temperature is appropriate and the principal-review queue under Rule 2210 (L4 Ch3.2) catches the Marketing Rule trip.

How Next-Token Prediction Actually Runs, In One Paragraph

Here is the mechanic, stripped to its core: at every step in generating its response, the model takes the entire context (system prompt + user prompt + uploaded documents + the response generated so far) and computes a probability distribution over the next token. It samples one token from that distribution (with the variation governed by temperature), appends it to the response, and repeats. The "intelligence" is in the probability distribution — which was learned from the training corpus during the model's training. The "creativity" is in the sampling. The "hallucination" is what happens when the highest-probability next-token chain produces a plausible-sounding sequence the model never actually saw in training but that fits the local pattern — like an LLM "remembering" an IRC section number by interpolating from the surrounding context of the prompt, producing a citation that reads correctly but does not match any actual statute.

The advisor analog: the model is like an extraordinarily well-read junior associate who finishes your sentences. The associate has read more than any human ever could, including most of the FINRA Rulebook, the Investment Advisers Act, most of the Internal Revenue Code, and the last decade of Kitces commentary. The associate also has zero professional experience, has never met a client, has never taken Series 7 or 65, will confidently produce a recommendation memo if asked, and will — when pressed for a specific citation it doesn't actually have — make one up that sounds right. Your job, as the registered, licensed, fiduciary human, is to take what the associate produced, verify it, modify it, and own it.

Why This Matters for Reg BI Documentation, Specifically

Reg BI's Care Obligation under §240.15l-1(a)(2)(ii) requires that a recommendation be in the retail customer's best interest at the time the recommendation is made, after exercising reasonable diligence, care, and skill to understand the potential risks, rewards, and costs and to consider reasonably available alternatives. Every word in that obligation is now relevant to an AI-touched recommendation.

"Exercised reasonable diligence" — the AI did not exercise diligence; the registered person who reviewed the AI's draft did, and the file must show what was checked. "Care and skill to understand" — the AI did not understand; the registered person did, and the documentation must reflect the reasoning. "Risks, rewards, and costs" — the AI's draft may have surfaced these or may have omitted them; the registered person owns the completeness check. "Reasonably available alternatives" — the AI's draft may have listed two of the four rollover alternatives; the registered person must document the consideration of all four, as the 2025-2026 FINRA AWC pattern made explicit. "At the time the recommendation is made" — the AI's draft may be the start of the analysis but the recommendation date and the file must reflect human decisioning, not tool output.

The stochastic nature of the model is the structural reason none of this can be skipped. Even if the model produces a defensible draft 99 times out of 100, the one time it produces a flawed draft is the time the registered person needs to catch. Without the verification protocol, the firm is relying on probability — which is not a defensible Reg BI posture. With the verification protocol (source-system verification + regulatory citation check + client-fit check, as the Cardinal Rule frames), the firm is using the AI to compress prep time while keeping the Care Obligation owned by the registered human. That is the entire operational point.

The Single Vendor-Decision Screen This Lesson Equips You For

Walk into any wealth-vertical AI vendor demo with these six mechanics in hand and you can ask six precise questions that will separate marketing from substance in under five minutes:

1. Which underlying model are you using and what is its training cutoff? Vendors who can't answer specifically are repackaging someone else's model and probably not paying enough attention to know.
2. What is your context window in tokens, and how is overflow handled — silent truncation, rolling context, hard error? The vendor's answer determines whether a 90-page document is actually being read.
3. What temperature setting is locked in the system prompt, and is it configurable per use case? A vendor who treats temperature as a black box is a vendor whose output your CCO cannot supervise consistently.
4. Show me the system prompt or the equivalent house behavior specification. Vendors who refuse usually have either nothing to show or something they don't want you to see. Either answer is informative.
5. How do you handle retrieval for post-cutoff content — SEC FAQs, FINRA notices, current tax limits? The honest answer is one of: "we don't" (which means you do, in your prompt), "we use web search with citation" (verify the citation behavior), or "we have a vetted regulatory corpus updated quarterly" (great, ask how often and from where).
6. What is your hallucination rate for citation tasks in your domain testing, and what does your benchmark look like? Vendors who can answer with a number and a methodology are vendors who take the problem seriously.

If a vendor's product can't answer four of those six, the product is not enterprise-ready for an advisor practice handling client NPI under the Reg S-P / GLBA / NY DFS Part 500 / Reg BI / Marketing Rule stack. L4 Ch2 develops the full vendor scorecard with eight dimensions and a forty-question due-diligence template; this lesson installs the technical literacy that makes the scorecard answerable.

Key Takeaways

• Tokens are the atomic unit AI reads. Roughly word-fragments; 60-page plans are 20-30k tokens; technical strings like §240.15l-1(a)(2)(ii) are reconstructed from context, which is why exact citations need verification.
• Prompts are two layers: the vendor's system prompt plus the advisor's user prompt. The firm's locked system prompts (junior advisor, senior advisor, compliance reviewer, CCO) are the operational surface where Marketing Rule discipline, Reg BI verification posture, and disclosure boilerplate get encoded into every interaction.
• Context window is the whiteboard with an edge. Most vendors silently truncate. Always verify that long uploaded documents were fully consumed.
• Training cutoff means yesterday's news. Post-cutoff facts (2026 limits, January 2026 SEC FAQs, FINRA 2026 Oversight Report, OBBBA dual-regime §1202) require retrieval, paste-in context, or verification — never assumption.
• Temperature governs stochasticity. Same prompt + different temperature = different answers. Reg BI Care Obligation under §240.15l-1(a)(2)(ii) cannot rest on "the AI said so" because the AI may say something different tomorrow.
• Next-token prediction is the whole mechanic. The model samples one token at a time from a learned probability distribution. Hallucinations are the local pattern producing a plausible string the model never actually saw. Verification is non-negotiable.
• Six vendor-decision questions — model and cutoff, context window and overflow, locked temperature, system prompt visibility, post-cutoff retrieval, hallucination rate — separate marketing from substance in five minutes. L4 Ch2 builds the full scorecard.