Understanding Generative AI Methods

Welcome to Introduction to Generative AI. If your work involves technical discovery, product demos, POC/POV scoping, RFP and security-questionnaire responses, or solution proposals and architecture visuals, generative AI is already becoming part of your pre-sales workflow. In this first unit, you'll build a plain-language mental model for what generative AI does, how it works, and where it can go wrong.

You'll cover:

• The five major AI capabilities: text generation, image generation, image description, web search, and automation
• Two common model architectures and multimodality as an overlapping capability
• Key limitations like context windows and hallucinations, plus why human verification matters

When people say "AI," they may be talking about five different capabilities, and mixing them up can lead you to use the wrong tool for the job.

The practical move: before you open a tool, name which capability you actually need. "I need a discovery follow-up draft" is text generation. "I need an architecture-overview visual" is image generation. "What's in this architecture diagram the prospect shared?" is image description. Asking the wrong tool the right question is a top reason people decide AI "doesn't work."

Two common model architectures and one cross-cutting capability sit underneath these tools. This is a working map, not three separate lanes: a system can combine model types and can be multimodal at the same time.

Large language models (LLMs) are a common architecture for text generation. Picture an extremely well-read autocomplete: given everything you've typed so far, the model predicts the most likely next word, then the next, then the next, all the way to the end of the response. It learned these patterns from massive amounts of human-written text. It doesn't "understand" in the way you do; it pattern-matches at a scale that feels like understanding. That's what's drafting your discovery follow-up emails and RFP answers.

Diffusion-style image models are a common architecture for image generation. Think of them as starting with a screen of static (random noise) and gradually "uncrumpling" it into a coherent picture that matches your description, one denoising pass at a time. They learned what a "warm, candid office photo" looks like by training on millions of captioned images. That's what's producing your demo-deck hero slides and architecture-overview visuals.

Multimodality is not a third, mutually exclusive architecture. It describes a model or system's ability to work across more than one data type, such as text and images. A multimodal LLM can read a prospect's architecture diagram and answer questions about it, while a diffusion system can also be part of a multimodal workflow. Think "what inputs and outputs can this system work with?" rather than "a separate kind of model."

Because LLMs predict the next likely word, they can produce a confident, well-formed sentence even when the underlying claim is false. That's called a hallucination: wording that sounds factual but is unsupported, inaccurate, or invented. Retrieved sources can help ground a response, but they do not make the model's generated wording inherently verified.

A hallucination might be a fake statistic, a made-up citation, a compliance certification the product never earned, or a confident answer to something the model was never given enough information to know. The model is not "lying" on purpose; it is generating a plausible pattern. That's why hallucinations are not a bug you can fully prompt your way out of; they're a property of how the model works.

Another term worth noting is a context window: everything the model can "see" in your current conversation, including your prompt, any pasted text, and its own prior responses. Past that window, it has no memory. And because the model is optimizing for plausible-sounding output, the most dangerous hallucinations are the polished ones: certifications, throughput numbers, and integration claims that look exactly right — especially when they end up in an RFP answer or a security questionnaire a prospect is about to read.

Here's what that looks like in a normal pre-sales task. Jake used an AI tool to draft a short capability blurb for an integration from a few bullet points, but the draft included a specific compliance certification he didn't recognize. He asks Nova, a teammate with more experience reviewing AI output, what to do with it.

• Jake: I asked it for a capability blurb and it gave me this clean line about a SOC 2 Type II certification. Looked totally real.
• Nova: Did the bullet points you fed it mention any certification?
• Jake: No, I just gave it the integration name and a couple of facts.
• Nova: Then the model filled the gap with whatever sounded plausible. That's a hallucination, not a fact.
• Jake: So I need to verify anything it added that I didn't give it?
• Nova: Exactly. If you didn't put it in, treat it as a claim, not a quote.

Notice the move: Nova didn't argue with the output, she traced it back to what was in the prompt versus what the model invented.

The single most important takeaway from this lesson: generative AI does not inherently verify truth; it generates plausible patterns. Even when a tool retrieves sources, verify the generated claims against those sources before they reach a prospect.

Everything above is theory until you have to explain it to someone else in plain English. Your next step is a live roleplay where a curious fellow SE asks you how this stuff actually works: your job is to make the models and multimodal systems stick using everyday analogies, no jargon allowed.