Build DiscoveryInterviewAgent using LangGraph with structured question flows and LLM-powered insight extraction — lab audio overview

Host: Welcome back. You're in AI Solution Delivery — a course about taking artificial intelligence projects from a client's vague wish list all the way to a working system in production. This chapter is on discovering AI use cases and checking whether the client's data is ready to support them. And the specific skill you're about to build — running a structured, multi-turn interview with a client, automatically — is one of those things that separates consultants who scale from consultants who don't. Expert: Picture this. You're on a delivery team at a mid-sized consulting firm. Maybe twenty engineers, a handful of architects. A new client — let's say a regional bank — signs up for an AI discovery engagement. Your team's job is to sit down with their business leaders, figure out where AI could actually help, and assess whether their data can support it. Now, if every discovery workshop is done from scratch, with a different consultant asking different questions in a different order, you get inconsistent findings. One team surfaces regulatory risk, another misses it entirely. The engagement that should take two weeks stretches to six. And the client loses confidence. What high-performing teams do instead is build a structured interview process — a guided conversation that always covers the critical ground, adapts to what the client says, and produces a clean summary at the end. That's what you're going to start building in this exercise. Host: So this is the very first exercise in the chapter — the starting point. The chapter introduction laid out the big picture of discovery and data readiness. Now we get concrete. What exactly are we building here? Expert: You're building the backbone of an automated discovery interview — a piece of software that runs a conversation with a client across multiple turns, keeps track of what's been said, and decides what to do next. The tool you'll use for this is called LangGraph. Think of LangGraph as a way to describe a conversation as a map. On that map, each location is a step in the conversation — like greeting the client, asking a question, or summarizing what you heard. And the roads between locations are the rules for moving from one step to the next. Some roads are straight — after the greeting, you always go to questioning. Other roads are forks — after a question, you either ask another one, or, if you've learned enough, move on to the summary. The key idea — and this is the aha moment — is that you're not writing one long script that runs top to bottom. You're designing a small network of steps, and at every step, a little piece of logic looks at the conversation so far and picks the next step. That shape is what makes the interview feel responsive instead of robotic. You'll define what information the interview remembers as it moves along — things like which questions have been asked, what the client said, and whether enough ground has been covered. Then you'll build the individual steps: one that opens the conversation, one that asks the next question, one that wraps up with a summary. And finally you'll wire in the decision logic that routes between them. Host: Alright, before people dive in — what's the part that usually trips engineers up the first time they work with this kind of tool? Expert: The biggest stumble is thinking about the conversation's memory the wrong way. When you're used to writing normal programs, you reach for variables that you update as you go — change a value here, overwrite it there. But in a step-and-map style tool like this, each step should describe what it contributes to the shared memory, and the framework merges those contributions for you. If you try to manipulate the memory like a regular variable, you'll get confusing behavior where updates seem to vanish or overwrite each other. So the tip is: before you write any step, sit down and list exactly what the interview needs to remember — the list of questions asked, the client's answers, a counter for how many turns have passed, and a flag for whether you're done. Write that down first. Then, for each step, ask yourself one question: what does this step add to that shared memory? Keep the steps small and focused. One step, one job. Host: Great. So walk us out — what will someone be able to do after this, and what's coming next? Expert: After this exercise, you'll be able to take a messy, open-ended conversation like a client discovery interview and express it as a clean, structured flow that a machine can run end to end. You'll know how to design the memory that carries the conversation forward, how to break the flow into small focused steps, and how to write the branching logic that decides where the conversation goes next. This is a genuine production building block. Your team can use this same pattern for client intake, requirements gathering, even internal architecture reviews — anywhere you need a consistent, adaptive conversation at scale. In the next exercise, you'll make the interview smarter. You'll plug in a large language model — the kind of AI that understands and generates natural language — so that the questions aren't fixed in advance. The system will read what the client just said and generate a thoughtful follow-up on the fly, then pull structured insights out of the transcript at the end. But all of that sits on top of the skeleton you're building right now. Get the flow right today, and everything after it slots in cleanly. Thanks for listening, and enjoy the exercise.