We return to the original support problem and follow the complete journey: discovery, scoping, prototyping, architecture, integration, evaluation, production, adoption, and feedback. Along the way, we explain Forward Deployed Engineering and compare it with software engineering, AI/ML engineering, solutions architecture, and DevRel. The final realization: technology is not the requirement. The problem is the requirement.

Real users have arrived, and so have latency, rate limits, privacy questions, and bills. We explore model choice, caching, fallbacks, logging, and operational ownership before comparing hosted APIs with local and self-hosted models. Sabrina brings the open-weight question; GPUs and quantization get plain-language explanations. The model turns out to be one dependency inside a much larger software system.

The demo worked. Unfortunately, that’s not a test strategy. We try to break Support Assistant with missing policies, conflicting documents, unavailable services, malicious instructions, and unauthorized refund requests. Learn how ordinary tests, AI evaluations, human review, monitoring, and traces work together—and why a convincing answer or impressive average score can hide a serious failure.

When does a chatbot with tools become an agent—and would that actually help? We compare tool assistants, predefined workflows, and systems that let a model choose what happens next. Planning, state, memory, orchestration, and multiple agents all get a turn, but so do budgets, stopping conditions, and the humble if statement. The robot’s lanyard remains under review.

We already have APIs and tool calling. What problem is MCP trying to solve? Parisa, Jules, and Sabrina untangle hosts, clients, servers, tools, resources, and prompts as Support Assistant connects to more systems. The USB-C analogy makes an appearance—with limits—because a shared connection format doesn’t guarantee compatibility, trustworthy integrations, or permission to access everything.

Reading the shipping policy is useful. Checking a real order requires a different capability. We follow a tool call from the model’s proposed arguments through application-controlled validation, authorization, execution, and results. Then someone asks for a refund, and suddenly permissions, human approval, accessible confirmations, and avoiding duplicate transactions become very relevant.

Brenda’s 40,000 documents are back, and this time we’re retrieving the useful ones. We explain retrieval-augmented generation, embeddings, vectors, semantic search, and chunking without turning the episode into a mathematics lecture. Learn how RAG differs from keyword search and fine-tuning—and why retrieving a passage doesn’t automatically make the resulting answer correct.

How does a model become a feature in your own application? Follow a request from the browser through your server to a model provider, with APIs, SDKs, streaming, token costs, and failure handling along the way. There’s a Chef Nervous Robot callback, a firm boundary around secret API keys, and a familiar realization: wait, that’s just JavaScript.

Can we replace elaborate prompt rituals with a useful brief? Sabrina joins Parisa and Jules to discuss instructions, examples, context windows, randomness, and structured output. Brenda proposes pasting all 40,000 company documents into the prompt. We explain why that’s a problem—and why better prompting doesn’t mean training, guaranteed accuracy, or enforceable security.

Is a language model a digital mind or autocomplete wearing an expensive coat? We explore tokens, next-token prediction, transformers, attention, and context to understand what happens when an LLM generates an answer. Support Assistant discovers that sounding like an experienced employee is not the same as knowing the company’s actual refund policy.

If nobody programmed every answer, where did they come from? Parisa and Jules unpack training data, models, weights, neural networks, and the difference between training and inference. Along the way, “let’s train our own AI” turns out to contain several enormous assumptions—and using AI in a web application doesn’t suddenly require writing everything in Python.

Management says, “We should add AI.” Parisa has a follow-up: “To do what?” We untangle AI, machine learning, deep learning, generative AI, and LLMs—and introduce Support Assistant, our fictional company’s attempt to help support staff find information without opening twelve tabs. Before choosing the technology, we need an actual problem.

Our little podcast app probably never needed Kubernetes. From static portfolios to large distributed systems, we compare infrastructure choices against actual requirements, costs, and maintenance responsibilities. The goal isn’t the most impressive diagram—it’s a decision you can explain and sustain.

Someone configured production six months ago. Nobody remembers exactly what they did. We explore how infrastructure as code makes those decisions reviewable and repeatable, why Terraform and OpenTofu keep state, and why Git cannot reverse time for your database.

The asterisk is doing some serious work. We explore cloud services by what they manage: compute, storage, databases, networking, containers, and more. The useful question is how much responsibility you want to keep—and what you’re paying someone else to handle.

Kubernetes has a lot of nouns. Now they have jobs. We connect clusters, nodes, Pods, Deployments, and Services through one simple example: we want three replicas, but only two exist. What happens next—and what can still go wrong?

One container is manageable. Hundreds of containers across machines that occasionally fail create a different problem. Before introducing the vocabulary, we explain why orchestration exists—and why “Docker or Kubernetes?” is usually the wrong question.

Pushing code means the code has traveled. It doesn’t necessarily mean anything is deployed. We trace a change through automated checks, image builds, registries, and production, then ask what happens when the green checkmark turns into a real-world problem.

Our fictional podcast app now has a frontend, an API, and a database. Docker Compose helps describe how they fit together—and Parisa discovers that familiar tools like DDEV and Lando have been doing quite a bit of this work already.

The API works. The database works. Together, they refuse to speak. We follow requests across container boundaries, decode port mappings, and discover why deleting a container can become a very unpleasant lesson about persistent storage.