Connecting knowledge

First, three things to settle up front. This chat-window path IS the certified path, not a downgrade — the discipline, not the tooling, is what's graded, so a support lead working entirely in a chat window earns the same credential as someone with a full pipeline. You'll design this layer, not build it. You will NOT build the authenticated account layer in this course — you'll simulate it (the Module 2 lab uses a pasted 'system record'); real account lookups are an engineering task, and your job is to specify the rule and verify the behavior. And a definition, since this course doesn't require Building RAG: retrieval just means the system searches your documents for the passages relevant to a question and pastes them into the prompt. In this course you do that by hand — you paste the right doc yourself; a retrieval pipeline (from Building RAG) only automates that same step.

The model's pretraining knows nothing reliable about Harbor Lane's return window, and whatever it thinks it knows is a lawsuit generator. Customer-facing agents run on the RAG rule absolute: the model answers from retrieved context or it doesn't answer. If you took Building RAG, this module is your HarborDocs engine meeting production stakes; if not, the takeaways stand alone:

• Two knowledge layers, kept distinct. Policy knowledge (returns, shipping, product docs — the HarborDocs corpus) comes via retrieval and changes weekly. Customer-specific facts (this order's status, this subscription's renewal date) come via system lookups — authenticated API calls, never retrieval, never guessed. Conflating the layers is how agents tell customer A about customer B's order.
• Retrieval is scoped by the scope contract. In-scope topics map to designated collections; a question with no decent retrieval hit doesn't trigger creativity — it triggers the honest-miss beat ('I don't have that in front of me') or handoff. The retrieval score threshold is a product decision you'll tune with eval data, not a default.
• Freshness is a support-specific killer. The #1 customer-agent incident in the wild isn't hallucination — it's confidently citing the old policy: last season's return window, the discontinued product, the price from March. Your ingestion pipeline needs the boring machinery: single-source-of-truth docs, re-index on publish, a valid_from/superseded convention, and a canary eval question pinned to every policy that changes ('What's the return window?' must flip the day the policy does). In a chat window the same discipline is manual: freshness = paste only the current doc and delete superseded versions from your working folder; valid_from/superseded is a habit you keep, not a database feature you build. (The infra description above is what a RAG pipeline automates; the no-code version is the same rule enforced by hand.)

Authentication changes everything it touches

The moment the agent can look up this customer's order, there's an authenticated surface, and the security posture jumps. You won't build this layer in this course — you'll specify it; frame each of the following as what you require of engineering, not what you code: verify identity before revealing anything account-specific (the session's auth, not 'what's your email' — emails are public knowledge), scope lookups to the authenticated customer only (the agent's credentials must be structurally unable to fetch someone else's order — this gets enforced in the API layer, never in the prompt), and log every lookup like the audit trail it is. If you took Securing AI Systems: this is your least-privilege module wearing a headset. If not, the one-sentence version is right here: the prompt is not a security boundary; the API layer is.