Course curriculum — Forward-Deployed Engineer

Bundle 01

FDE Foundations

Solid integration engineering plus the FDE mindset. General SaaS and API work — no AI yet. This is the on-ramp.

For Engineers early in their career or switching in — you can code, but haven't worked enterprise integrations

Depth 6 modules · capstone

01The FDE RoleThe role, the three signals, and where it fits among the jobs around it.6 lessons

1.1A real weekA realistic walk through a week in the field: a discovery call, a broken integration, a demo, a scope conversation.
1.2The three signals — what hiring actually screens forShips fast, customer empathy, owns ambiguity — the signals every interview is quietly testing.
1.3The anti-patterns — how strong candidates get rejectedThe specific failure modes that sink otherwise-strong engineers in the loop.
1.4FDE vs. adjacent rolesHow the FDE differs from a backend engineer, a sales engineer, a CSM, and a consultant — and where the lines blur at small companies.
1.5The first 90 days at a customerWhat the ramp actually looks like once you've got the job.
✓BuildThe FDE Role BriefWrite a one-page brief positioning yourself against the three signals — the raw material for your story in interviews.

02Enterprise APIsAuth, pagination, rate limits, retries — consuming someone else's API in someone else's environment.7 lessons

2.1Auth for real: what you'll actually meet at a customerAPI keys, OAuth2, SSO/OIDC — the auth schemes you'll actually meet, not the toy versions.
2.2Pagination: the data never fits in one responseReading data that doesn't fit in one response, without missing rows or looping forever.
2.3Rate limits: you're a guest on their infrastructureBeing a good API citizen instead of getting your customer's key throttled.
2.4Retries with exponential backoff and jitterFailing gracefully and retrying deliberately instead of hammering a struggling API.
2.5Secrets and config in an environment you don't own.env files, config per environment, and never committing a key to a customer's repo.
2.6Reading vendor docs fast — the FDE superpowerGetting productive against unfamiliar software fast, without hand-holding.
✓Buildrepo-report — a vendor-API integration under rate limitsA real tool against a live API: auth, pagination, rate-limit handling, and clean errors — end to end.

03Webhooks & Sync PatternsHow two systems stay in agreement — signatures, idempotency, polling vs. push.7 lessons

3.1The three sync patternsPolling, webhooks, and sync jobs — when each is right, and why real-time integrations lean on webhooks.
3.2Who decides? Usually the customer's ITThe organizational reality behind which sync pattern you're actually allowed to use.
3.3Anatomy of a webhook deliveryThe shape of an inbound event and how to stand up an endpoint that accepts one.
3.4Signature verification: HMAC, the raw-body trap, and constant timeProving an event really came from the provider — including the raw-body trap that silently breaks verification, and why == on a signature is a real security bug.
3.5Idempotency: retries mean duplicates, guaranteedSurviving duplicate deliveries so a retried event doesn't double-charge or double-create.
3.6When processing fails: retry thinking and the dead-letter ideaWhat to do when a webhook handler itself fails, so a bad event doesn't get silently dropped.
✓BuildA signed, idempotent webhook receiverA receiver that verifies signatures, rejects forgeries, and safely handles the same event twice.

04Enterprise DataMessy exports, ETL, validation, SQL — moving data between systems without losing your mind.7 lessons

4.1What "a CSV export" really meansThe data you actually meet at customers — messier and less consistent than any tutorial dataset.
4.2ETL: extract, transform, load — kept separateThe mental model behind almost every integration you'll build, and why keeping the stages separate saves you.
4.3Validation: skip-and-report, never crash, never silently dropCatching bad rows and reporting them, instead of crashing or silently dropping a customer's data.
4.4Load: safe SQL and idempotent upsertsParameterized queries and upserts — avoiding injection and making re-runs safe.
4.5The bigger picture: warehouses, data teams, and replicasWhere your integration sits inside the customer's larger data world.
4.6Documents at scale: PDF and DOCX, the honest versionHandling documents at scale, honestly — what's easy, what needs real tooling.
✓Buildcsv2db — a validating importer for a hostile exportA validating ETL importer that loads messy CSV into SQLite, reports what it skipped, and is safe to re-run.

05Discovery & ScopingThe half of the job that isn't code.7 lessons

5.1Discovery: dig past the stated solution to the real problemAsking the questions that surface the real problem instead of building what someone thinks they asked for.
5.2Know the room: stakeholdersThe buyer, the technical contact, and the end user — what each cares about and how to speak to them.
5.3Requirements: write it down and send it backWriting down what was agreed so nobody remembers it differently in two weeks.
5.4Scoping: promise what you can deliver, in writingSizing a task and committing to it in a way you can actually deliver.
5.5Demos: make the invisible visibleStory first, their data on screen, and a fallback ready — the difference between a convincing demo and a frozen one.
5.6Expectation management: how trust compoundsUnder-promise and over-deliver, and give bad news early with a plan attached.
✓BuildDiscovery-to-Scope packageRun a mock discovery scenario and produce the written requirements + scope — the field artifact interviewers love to see.

06The POC SprintThe 48-hour proof of concept — the FDE build method.7 lessons

6.1Scope ruthlessly: one workflow, one user, one wow momentCutting an underspecified brief down to something shippable in the time you actually have.
6.2Mock versus real: the honest tradeoff tableDeciding what to fake and what to build for real, and being upfront with the customer about which is which.
6.3Write the demo script before you buildWorking backward from the five minutes that matter, so the build stays aimed at the demo.
6.4The hour-by-hour sprint planA concrete plan for turning 48 hours into a working POC instead of a scramble.
6.5The honesty conversation: POC versus productionBeing straight with the customer about what a POC proves and what it doesn't.
6.6How a POC convertsWhat actually turns a successful POC into a signed deal — and what kills one that looked great in the room.
✓BuildA POC plan for a live briefA demo script and hour-by-hour plan for a realistic customer brief — the method, rehearsed.

Capstone The 48-Hour POC — Meridian Retail A realistic customer brief with the requirements buried in stakeholder quotes, a clock, and one shot at a demo: run mini-discovery, write a one-page POC plan, build the POC inside a 48-hour scope by reassembling your checkpoint projects, and record a five-minute demo. Reuses the receiver, the ETL importer, and the discovery method from earlier modules — the strongest single artifact a junior FDE candidate can put in front of an interviewer.

Bundle 02

The AI FDE

Ship production LLM features on the Claude API: context engineering, RAG, tool-using agents, MCP, evals, and guardrails — plus fluency across the vector-DB and orchestration ecosystem.

For Working engineers pivoting into AI FDE roles

Depth 7 modules · capstone

01LLM Fundamentals for FDEsUnderstand the model well enough to defend it to a customer.8 lessons

1.1Why an FDE needs to understand the modelYou'll be the one in the room answering "why did it say that?" — so you need a real mental model, not vibes.
1.2Tokens — the unit of everythingWhat a token is, why it drives cost and limits, and how to reason in tokens instead of characters.
1.3The context windowWhat fits, what falls out, and why "just paste it all in" eventually fails.
1.4How the model generates — and why it hallucinatesNext-token prediction in plain terms, and where confident-but-wrong answers come from.
1.5Temperature, effort, and the knobs that actually existEffort and adaptive thinking on current models — and which older knobs are gone, so you don't cargo-cult them.
1.6Cost and latency — the tradeoffs you'll defend to a customerThe numbers you'll defend to a customer: what drives spend and speed, and how to pull them down.
1.7Choosing a model — the FDE decision frameworkclaude-opus-4-8 vs. claude-sonnet-5 vs. claude-haiku-4-5 by task, with a repeatable way to justify the pick.
✓Build"Model Advisor" CLIA small tool that counts real tokens, recommends a model + settings for a described task, and estimates its monthly cost.

02Building with the Claude APIThe Anthropic SDK, deeply — from a request to production error handling.9 lessons

2.1The shape of a requestMessages, roles, and reading the response blocks correctly — the foundation everything else sits on.
2.2System prompts — where you define the assistantWhere you define the assistant's behavior, and how to write one that holds up under real inputs.
2.3Multi-turn conversationsManaging history correctly in a stateless API without leaking or losing context.
2.4Streaming — for long outputs and responsive UIsWhy large responses need it to avoid timeouts, and how to build a responsive UI on top of it.
2.5Structured output — getting reliable JSONGetting reliable, validated JSON out of the model with Pydantic instead of parsing prose.
2.6Error handling in productionTyped exceptions, what's retryable, and failing gracefully in front of a customer.
2.7Prompt caching — the FDE's cost superpowerCutting cost on repeated context dramatically, and verifying the cache is actually hitting.
2.8Token counting revisitedMeasuring real token usage with the API before a request — not guessing with the wrong tokenizer.
✓Build"Document Intake" serviceA service that ingests a document and returns structured, validated fields — the workhorse pattern behind most AI features.

03Context Engineering & Model AdaptationContext window management, and the prompt vs. RAG vs. fine-tune decision.5 lessons

3.1Context engineering — the discipline has a nameDeciding what goes into the model's context window, in what order, and at what cost.
3.2Context budgets and stable-prefix designStructuring a prompt so the stable parts cache and the volatile parts don't invalidate the cache.
3.3Long conversations — compaction and the history problemKeeping a long-running conversation inside budget without losing what matters.
3.4Prompting vs. RAG vs. fine-tuning — the adaptation decision frameworkThe decision framework every customer conversation eventually lands on, and how to argue it with evidence.
✓Build"Model adaptation memo" + context-budget worksheetA written recommendation for a real scenario, backed by a worked context budget.

04RAG: Retrieval-Augmented GenerationAnswer questions over the customer's own documents — plus the vector-DB ecosystem.8 lessons

4.1Why RAG existsGrounding answers in the customer's data instead of the model's memory — and what problem that actually solves.
4.2Chunking — the step that quietly decides everythingThe unglamorous step that quietly decides whether retrieval works at all.
4.3Embeddings — turning text into vectorsAn honest look at where embeddings come from, since there's no first-party Anthropic embeddings endpoint.
4.4The vector store — where retrieval happensBuilt simply enough to fully understand before reaching for a heavy dependency.
4.5Generation — grounding the answer and citing sourcesMaking the model answer from retrieved context and cite its sources so answers are checkable.
4.6Evaluating retrieval quality — RAG can fail in two different placesLearning to tell which half failed — retrieval or generation — instead of guessing.
4.7The vector-DB ecosystem — what the customer already runsLocal vs. hosted; Chroma/FAISS vs. Pinecone/Weaviate/Qdrant — fluency in the tools customers actually run.
✓Build"Docs Q&A" over a real corpusA working question-answering system over a document set, with citations and a retrieval score.

05Tools, Agents & MCPLet the model take actions — tool use, the agent loop, and building an MCP server.10 lessons

5.1Why tools?The jump from "answers questions" to "does things" — and what that unlocks at a customer.
5.2Defining a toolSchemas, descriptions, and writing a tool the model actually calls correctly.
5.3The tool runner — let the SDK drive the loopLetting the SDK drive the call → execute → feed-back loop for you.
5.4The manual loop — understand what's under the hoodThe tool-use loop by hand so nothing is magic when it breaks.
5.5A multi-tool agentGiving the model several tools and letting it choose — plus handling the failure modes.
5.6MCP — the standard for connecting AI to customer systemsThe open protocol FDE job descriptions now name as day-to-day work.
5.7Building an MCP serverExposing a real integration as an MCP server instead of locking it inside one app.
5.8Using MCP servers from your appConnecting Claude to the MCP server you just built, and to others already running at a customer.
5.9Agent vs. workflow — the most important judgment call in this moduleWhen an agent is right and when a plain workflow is safer and cheaper.
✓Build"Action-taking support agent, MCP edition"An agent that answers and takes a real action through a tool served over an MCP server, with guardrails on what it's allowed to do.

06Evals and QualityProve the AI works before the customer finds out it doesn't.8 lessons

6.1Why evals are the FDE's most important skill"It looked good in the demo" is how deployments fail. Evals are how you know, and how you defend the system.
6.2Building an eval setTurning real examples into a test set that actually represents the customer's traffic.
6.3Assertion-based evals — cheap, fast, deterministicThe first line of defense: deterministic checks that don't need a model to grade them.
6.4LLM-as-judge — grading quality with a modelGrading open-ended quality with a model, done carefully enough to trust.
6.5Regression testing prompts — the thing that saves deploymentsCatching the prompt change that quietly broke everything.
6.6Measuring RAG quality end to endScoring retrieval and generation together so you know which half to fix.
6.7Iterating with dataUsing eval results to actually improve the system instead of guessing at prompt tweaks.
✓Build"Eval harness" for your assistantA reusable harness that scores your assistant on every change — the thing that turns a demo into something deployable.

07Guardrails, Safety & ProductionEverything between a demo and a system you'd trust at a customer.11 lessons

7.1Why guardrails are an FDE responsibilityYou're the one deploying it into someone else's business — the safety net is your job.
7.2Input validationStopping bad or hostile input before it reaches the model.
7.3Output validationChecking what comes back before it reaches a user or another system.
7.4Prompt injection — the security threat you must understandHow it works and how to reduce the blast radius.
7.5PII and sensitive dataHandling personal data responsibly in the pipeline instead of hoping it's fine.
7.6Handling refusals and every stop_reasonReacting correctly when the model stops — refusals, length limits, and the rest.
7.7Rate limits and retries in productionStaying up under load without hammering the API or dropping requests.
7.8Logging and observabilityCapturing what you need to debug and defend the system after it's live.
7.9Cost controlsBudgets and limits so a runaway loop doesn't become a bill you have to explain.
7.10The pre-production checklistThe concrete list to run before you point a customer at it.
✓Build"Production-harden the assistant"Take the assistant from earlier modules and make it something you'd actually deploy.

Capstone The Customer AI Assistant — Northwind Logistics Ship a customer-style AI assistant that answers questions over a set of documents (RAG) and takes at least one real action via a tool — with the actions served over an MCP server you build — grounded, cited, measured with an eval harness, and hardened with production guardrails. RAG + tools + MCP + evals in one deliverable, built correctly on the Claude API end to end.

Bundle 03 · Full

Advanced — Deploying AI at the Customer

Own an end-to-end deployment: architecture, multi-agent systems, deploying inside the customer's environment, LLMOps, security, voice & multimodal, running the engagement, and the interview. Includes a named-industry simulation pack and everything below it.

For Experienced engineers going for senior / lead FDE roles

Depth 9 modules · sim pack · capstone

01Solution Architecture for AI DeploymentsTurn requirements into a design the customer signs off on.10 lessons

1.1The FDE is the architect on the accountWhy the design decisions land on you, and what that responsibility looks like.
1.2Requirements → architectureTranslating what the customer needs into components and data flow.
1.3Build vs. buy vs. reuseDeciding what to write, what to pull off the shelf, and what to reuse — with a bias toward shipping.
1.4Build vs. buy across the ecosystem, by nameOrchestration frameworks like LangGraph, vector DBs, and observability platforms like LangSmith — named, compared, and placed in a real architecture.
1.5The three-way tradeoff — latency, cost, qualityLatency, cost, and quality pull against each other — how to choose deliberately.
1.6Synchronous vs. asynchronous — the most important boundaryThe most important boundary in an AI system, and how getting it wrong shows up as a bad demo.
1.7Choosing components — a reference architectureA reference architecture you can adapt instead of designing from a blank page every time.
1.8Drawing the diagramCommunicating the design so the customer's team actually understands and trusts it.
1.9Writing the architecture docThe written artifact that gets sign-off and prevents "that's not what we agreed" later.
✓BuildThe architecture docA complete, reviewable architecture document for a realistic AI deployment.

02Multi-Agent & Orchestrated SystemsOrchestrator/worker patterns — and when they help vs. hurt.8 lessons

2.1What a "multi-agent system" actually isCutting through the hype to what the term concretely means.
2.2When multi-agent helps — and when it hurtsThe honest tradeoff: more agents means more cost, latency, and failure surface. When it's worth it.
2.3The orchestrator / worker patternThe workhorse structure: a coordinator delegating to specialized workers.
2.4Building it — code-orchestrated coordinator + workersBuilding it with your own control flow, so you own the behavior.
2.5Building it — workers-as-tools with the tool runnerThe alternate pattern — subagents exposed as tools — and when to prefer it.
2.6Parallel tool use — do it rightFanning out safely without corrupting shared state or blowing your budget.
2.7Handling failures in a multi-agent systemWhat happens when one agent fails partway — and designing so the whole thing doesn't collapse.
✓BuildOrchestrator + specialized subagentsA working coordinator that delegates to specialized subagents and recovers from a failing one.

03Advanced RAG & Data Strategy at ScaleWhy basic RAG breaks at the customer — and how to fix it.9 lessons

3.1Why basic RAG breaks at the customerThe gap between a tutorial RAG and one that survives real, messy, large data.
3.2Hybrid search — dense + sparseCombining dense and sparse retrieval to catch what pure vectors miss.
3.3Reranking — precision on top of recallAdding precision on top of recall so the best chunk is actually at the top.
3.4Metadata filtering — retrieval with a WHERE clauseScoping to the right tenant, doc type, or date, e.g. against pgvector or Pinecone metadata filters.
3.5Chunking strategies at scaleChunking that holds up across many document types and sizes.
3.6Keeping the index fresh — ingestion pipelinesIngestion pipelines so the index reflects the customer's data as it changes.
3.7Evaluating retrieval — the thing nobody doesActually measuring retrieval quality, which is where most RAG problems hide.
3.8Data strategy at the customerWhere the data lives, who owns it, and how it flows — the questions that shape the whole build.
✓BuildProduction RAG upgradeTake a basic RAG and add hybrid search, reranking, filtering, and a retrieval eval.

04Deploying in the Customer's EnvironmentDocker, VPC, SSO, secrets, air-gapped networks, CI/CD — running in someone else's infrastructure.8 lessons

4.1The deployment spectrum — and what each step costs youFrom your laptop to their VPC — what changes at each step, and what it costs you in effort and risk.
4.2Containerizing the solutionPackaging the system with Docker so it runs the same in the customer's infrastructure as it did on yours.
4.3SSO integration — what "we use Okta" means for youIntegrating against the customer's identity provider — Okta/OIDC — and what that actually requires of your app.
4.4Secrets in their environmentManaging keys and credentials inside someone else's secrets manager, not yours.
4.5Networking realities — egress, proxies, and the air-gap conversationEgress rules, proxies, and what changes when the deployment is on-prem or air-gapped.
4.6CI/CD into their worldShipping changes into an environment you don't fully control.
4.7The environment-access dance — and working without prod accessGetting work done when you don't have — and won't get — direct access to production.
✓BuildThe deployment packageA containerized, SSO-integrated deployment package ready to hand to a customer's platform team.

05LLMOps in ProductionObservability, prompt versioning, CI for evals, cost control — the ops of LLMs.9 lessons

5.1LLMOps is just Ops, plus the parts that are weird about LLMsWhat carries over from normal ops and what's genuinely different about LLMs.
5.2Observability & tracingLogging request IDs, tokens, and latency, and building a trace you can debug from.
5.3Prompt & version managementTreating prompts as versioned artifacts instead of strings buried in code.
5.4CI for prompts & evalsRunning your evals in CI so a bad change never reaches the customer.
5.5Caching & cost controlPrompt caching and budgets applied systematically across a real workload.
5.6Rate-limit handling & backpressureStaying healthy under load — queuing and shedding instead of falling over.
5.7Batch processingRunning large non-urgent jobs efficiently and cheaply.
5.8Deployment patternsHow AI features actually get shipped and rolled out at a customer.
✓BuildProduction LLMOps harnessTracing, versioned prompts, evals-in-CI, and cost tracking wired around a real service.

06Security & ComplianceBe the counterpart to the customer's security team.10 lessons

6.1The FDE is the customer's security team's counterpartYou'll sit across from the customer's security team — this teaches you to hold that conversation.
6.2Data boundaries — draw the trust boundariesDrawing the trust boundaries: what data crosses where, and why that's the first question they'll ask.
6.3PII & PHIHandling personal and health data within the rules, practically.
6.4Zero data retention & what the vendor keepsWhat actually happens to data sent to a model provider, and how to answer it honestly.
6.5Prompt injection & tool abuseDefending an agent that has real tools from being turned against the customer.
6.6Secrets handlingManaging keys and credentials in someone else's environment without leaving a hole.
6.7Tenancy isolationKeeping one customer's data from ever reaching another's — by design, not by hope.
6.8AuditabilityBeing able to show exactly what the system did, when someone asks.
6.9Working within a customer's compliance posture — SOC 2, GDPR, HIPAAWorking inside a customer's compliance posture without needing to be a lawyer.
✓BuildSecurity & compliance hardeningHarden a deployment against the concerns above and document it for a security review.

07Voice & Multimodal DeploymentsVoice agent pipelines, latency budgets, multilingual, document vision.8 lessons

7.1Why voice is the frontier deployment surfaceCall centers and field operations — where the fastest-growing deployments actually meet users.
7.2The voice agent pipeline — STT → LLM → TTSThe full pipeline from speech to text, through the model, back to speech.
7.3Latency budgets — engineering the pauseAbove all, latency: engineering the pause so a voice agent doesn't feel broken.
7.4Telephony basics — SIP, media streams, and the IVR replacementThe telephony layer underneath a voice deployment, and replacing a legacy IVR.
7.5Multilingual deployments — the Indic realityWhat multilingual actually means for a deployment serving Indic languages.
7.6Document vision — when the input is a PDF, a scan, or a faxThe documents-as-images surface: the PDFs, scans, and faxes that run half the world's back offices.
7.7Evals for voice — measuring a conversationMeasuring a conversation, not just a single turn — the eval problem specific to voice.
✓BuildThe voice-ready turn loopA voice-agent turn loop engineered against a real latency budget.

08Running the EngagementDiscovery → SOW → pilot → adoption & change management → hand-off.10 lessons

8.1An engagement is a project, and you're running itThe shift from "I write code" to "I own the outcome."
8.2Discovery — learn the problem before you build the solutionDeeper than the Foundations-bundle version: discovery at the scale of a full engagement.
8.3Scoping & the SOW — agree on what "done" meansAgreeing on what "done" means, in writing, before you start.
8.4Success criteria — define "worked" before you startDefining "it worked" up front so success isn't argued about at the end.
8.5Pilots & POCs — de-risk before you commitDe-risking with a small proof before committing to the full build.
8.6Stakeholder management — you're deploying inside someone else's orgChampions, blockers, and the people who quietly decide.
8.7Avoiding scope creep — without being rigidHolding the line on scope while still being a good partner.
8.8Hand-off & enablement — make yourself unnecessaryThe mark of a deployment that actually stuck.
8.9Adoption & change management — deployment isn't done when it shipsGetting the customer's team to actually use what you built.
8.10The FDE as trusted advisorEarning the seat where the customer asks you what they should do next.
✓BuildEngagement playbookA reusable playbook for running an engagement from discovery to hand-off.

09The FDE InterviewEvery round, and how to be the candidate they remember.10 lessons

9.1What an FDE interview actually evaluatesThe signals behind the questions — straight from the side that runs the loop.
9.2The rounds you'll faceA map of the whole loop so nothing is a surprise on the day.
9.3The system design round (for AI products)Designing an AI system out loud, the way the interviewer scores it.
9.4Live coding — an integration or an agentLess "invert this tree," more "here's a messy integration — make it work."
9.5The take-homeScoping and shipping a take-home that stands out without over-building.
9.6The customer case-study / role-play roundThe round that trips up pure engineers: a messy situation and "what do you do?"
9.7Behavioral & experience deep-diveTelling your stories against the three signals, with specifics.
9.8The questions you ask themThe questions that signal you already think like an FDE.
9.9Negotiation basicsHandling the offer conversation without leaving value on the table or souring the start.
✓BuildInterview prep packYour stories, a design template, and a practice plan — assembled into something you can drill.

Simulation pack

Four named industry engagements

Each brief hands you stakeholder quotes with the requirements buried inside — including a real contradiction between two stakeholders you have to catch and resolve, not quietly pick a side on. One-week time-box per scenario; write them up as portfolio pieces.

Fintech reconciliation

Brightpay — the Reconciliation Exceptions Workbench

An AI-assisted exceptions workbench for payments reconciliation under maker-checker and audit-trail constraints. The contradiction: auto-write-off requests vs. a hard maker-checker mandate.

Healthcare intake

CarePoint Clinics — Referral Intake from PDFs & Faxes

A document-vision intake pipeline over real-world-degraded faxes and scans, gated by HIPAA and human verification. The contradiction: straight-through processing vs. an absolute human-verification rule.

Support automation

Loomkart — Support Deflection with RAG + an Order-Status Tool

A customer-facing support agent over a weekly-changing help center and an MCP-served order-status tool. The contradiction: a raw deflection target vs. a resolution/CSAT metric.

CRM enrichment

Fieldlink — the CRM Auto-Enrichment Agent

A batch enrichment agent deduping and filling a 180k-record CRM from licensed reference data only. The contradiction: casual "check anywhere" expectations vs. a no-external-sources policy, and merge risk-asymmetry against a blanket dedupe ask.

Capstone Deploy an End-to-End Customer AI Solution — Northwind Health Partners Take a fictional-but-realistic healthcare customer from a discovery brief all the way to a running, observable, secure, handed-off AI system, through five phases: discovery & architecture, build (RAG + multi-tool agent + evals + observability + guardrails), security & compliance (the HIPAA gate), deploy, and hand-off. Integrates every module of this bundle and everything from Bundles 1–2 — the course finale and interview centerpiece.

Every module. Every lesson. Every build.