4. GenAI & Technical Fluency

Tokens are the units (roughly word-pieces) a model reads and generates — cost and limits are measured in tokens, not words. The context window is the maximum amount of text a model can consider at once. Both numbers show up constantly in cost and architecture conversations later in this curriculum.

Embeddings are numerical representations of meaning, used for search and retrieval — the foundation of RAG (Section 5). Multimodal models handle text, images, and audio together; reasoning models are optimized to "think" through steps before answering, trading speed for accuracy.

Models can produce confident, fluent, incorrect answers — hallucination. They have no persistent memory between separate calls unless a system explicitly provides it. These aren't bugs to be patched; they're properties to design around, which is why Sections 5 and 6 exist.

When an engineer says "we're hitting context limits" or "the embedding search isn't finding the right chunk," this vocabulary is what lets you follow — and contribute to — that conversation instead of nodding along.

Higher-capability models generally cost more and respond slower. A fast, cheap model may be entirely correct for simple classification; a slower reasoning model is correct for complex multi-step analysis. Using the top-tier model everywhere is expensive and unnecessary for simple tasks — and the cost compounds fast at production volume (Section 6 covers this directly).

Capability benchmarks, context window size, modality support, and pricing per token are the standard fields — but benchmark scores rarely reflect your specific use case. A model that scores well generally can still underperform on your specific task shape.

A customer wanting "the best model" for every task in their pipeline is a moment to reframe the question — not which model is best in the abstract, but which is best for each specific task shape, at the volume they'll actually run.

How a system identifies and authorizes a caller — API keys, OAuth tokens, session-based auth. Getting this wrong produces access errors that look like bugs but are actually configuration issues.

A webhook notifies another system of an event as it happens, rather than that system repeatedly asking "did anything change yet." Webhooks are more efficient but require the receiving system to be reliably reachable — a real constraint in enterprise networks with firewalls.

The cap on how many calls can be made in a period. Hitting this looks like random, intermittent failures if you don't know to check for it — a classic false trail in debugging.

Synchronous request/response works when the caller can wait for an answer. Async queued processing is appropriate when a task takes longer than a reasonable wait time — getting this pattern wrong produces either frustrating latency or unreliable "did it actually happen" uncertainty.

(Side-by-side split)

A customer reports an integration "randomly" fails during high-traffic periods but works fine otherwise. Checking rate limits first — before assuming a deeper bug — is the fast, correct diagnostic instinct this lesson builds.

A tool is defined by a schema — what arguments it accepts, in what format. The model fills in those arguments based on the conversation. A mismatch between what the model provides and what the tool expects is a common, fixable failure point.

A tool call can be well-formed and still fail because the caller lacks access. This is a different failure class than a schema mismatch, and needs different diagnosis — checking auth and scope, not argument formatting.

The most dangerous failure mode: a tool call fails without returning a clear error, and the model — with no signal that anything went wrong — fabricates a plausible-sounding result instead of reporting the failure.

When a model's output is confidently wrong right after a tool call, the first suspicion should be a silently failed tool, not a reasoning failure in the model itself.

The client is the AI application (e.g. a chat interface or agent). The server exposes capabilities — tools, data resources, reusable prompts — in a standard shape the client already knows how to consume, without custom integration code for each new server.

Before a shared protocol, every tool integration was bespoke — connecting a model to Salesforce, then separately to Slack, then to an internal database, each with different auth and data-shape conventions. A standard protocol means an integration can be built once and reused across different AI applications, not rebuilt per client.

(Sequence / arrow flow)

When an engineer proposes "let's just build a custom connector" for something MCP already standardizes, that's worth a second look — reinventing a solved integration pattern usually costs more in the long run than adopting the standard.

Multiple applications reusing the same integration, or a need for consistent permissions across many tool connections, both justify the protocol overhead. A single chatbot talking to one internal tool, with no reuse planned, often doesn't.

Authentication (how the server verifies the client), permissions (what the client can actually do once connected), enterprise deployment constraints (can the server run inside a VPC or air-gapped environment), and failure handling (what happens when a tool call inside the server fails) — all need explicit answers before build, not discovery mid-integration.

A customer wanting a single simple integration built "the standard way" is worth a scoping conversation — matching protocol overhead to actual reuse need protects timeline without sacrificing the cases where MCP genuinely pays off.

Look at a table schema and understand what data exists and how it relates to other tables. Run a SQL query to verify a claim rather than taking it on faith. Follow a conversation about batch vs. real-time processing without needing it explained from scratch each time.

This role isn't accountable for building the pipeline — that's an engineering function. It's accountable for making credible product decisions that depend on understanding what the data can and can't support, which is a fundamentally different (and lower) bar than implementation skill.

When a customer stakeholder claims "the data supports this," being able to run a quick query yourself — rather than trusting the claim or waiting for an engineer — is often the fastest way to move a stalled conversation forward.

Redaction removes sensitive fields before they reach a model. Retention governs how long data is kept and where. Both need to be designed in from the start — retrofitting redaction after a model has already processed unredacted data doesn't undo the exposure.

Data ownership determines who can authorize its use. Residency and sovereignty determine which country's laws govern where data physically lives — a constraint that can block an otherwise-approved architecture outright if the compute doesn't sit in the right jurisdiction.

Asking about residency and retention requirements during discovery — not after a prototype is built — is what prevents a costly, late-stage architecture reversal.

SSO integration, network architecture (VPC, on-prem, or air-gapped environments), compliance certifications like SOC 2, penetration testing requirements, vendor security questionnaires, and formal architecture review boards.

Asking about SSO, VPC requirements, and air-gap needs during discovery — not after a prototype is built — avoids a costly architecture redesign. Security requirements are usually knowable in advance if someone asks; they're rarely a genuine surprise, only an unasked question.

When a prototype is nearly ready and security review surfaces a VPC requirement that changes the entire deployment model, that's almost always a discovery gap, not an unpredictable event — the fix is asking earlier next time, not blaming the review process.

SaaS, VPC, or on-prem — the right choice depends on the security and residency constraints established in the previous two lessons, not on engineering preference alone.

(Decision tree)

Batch processing suits workloads that don't need an immediate answer; real-time suits interactive ones. Choosing the wrong pattern produces either unacceptable latency or unnecessary infrastructure cost.

Scaling under load, acceptable latency at volume, availability targets, and a safe rollback path when something breaks — none of these show up in a single demo run, only under sustained real usage.

This lesson closes with a real deliverable: an honest evaluation of whether the customer's infrastructure and requirements can actually support the proposed architecture in production, not just in a demo.

Produce a feasibility assessment covering deployment model fit, processing pattern, and the four operational qualities above — grounded in what was learned about the customer's security and residency constraints, not a generic architecture template.