Discovery Session API — lab audio overview

Host: Welcome back to AI Solution Delivery. This is the course where we turn the messy front end of consulting — the part where you sit with a client and figure out whether their problem is even solvable with AI — into repeatable engineering work. This chapter is about discovery workshops and data readiness. And today we're closing out that thread with the skill every consulting team eventually needs: turning a smart interview flow into something a web application can actually talk to. Expert: Picture this. You're at a consulting firm, maybe fifty people, and your team has built a really clever discovery interview — it asks the right follow-up questions, it extracts insights, it scores use cases. Great. But right now it only runs on your laptop, in a script, start to finish. Now your sales team wants to use it. Your delivery managers want to use it. Eventually the client wants to fill parts of it out themselves between meetings. And the moment you try to share it, everything breaks. Why? Because a real interview isn't one continuous run. The client answers three questions, goes to lunch, comes back two hours later, answers two more, a colleague jumps in and answers the next one from a different browser. Your script can't handle that. It has no memory between sessions, no way to pause, no way for two people to pick up where someone else left off. That gap — between "works on my machine" and "works as a service the whole firm uses" — is exactly what this exercise closes. Host: So this is the third and final exercise in the discovery objective. In the previous one, you built the brains — the piece that takes a raw interview transcript and pulls out structured insights, and generates smart follow-up questions using a large language model. Now we need to make all of that reachable over the internet. So what exactly are we building? Expert: You're building a web service for discovery interviews. A web service, in plain terms, is a piece of software that lives on a server and listens for requests coming in over the internet — one request might be "start a new interview," another might be "here's the client's latest answer, what do you ask next?", another might be "show me everything we've collected so far." The tool you'll use to build this is called FastAPI — it's a popular Python library for creating these kinds of internet-facing services quickly. Now here's the key idea, the conceptual leap. The interview logic you already built has state — meaning it remembers where the conversation is, what's been asked, what's been answered. But the internet itself has no memory. Every request that arrives at your service arrives as if it were the first one. So you have to do the remembering yourself. You give every interview a unique identifier — think of it like a coat check ticket. When someone starts an interview, you hand them a ticket. Every time they come back with an answer, they show the ticket, and you look up their half-finished conversation, add the new turn, and hand the ticket back. That's called a session, and managing it is the heart of this exercise. You'll also wire in the interview brain from the previous exercise — the library orchestrating it is called LangGraph, which is a framework for building multi-step conversations with language models. Host: Okay, that coat check analogy is clicking. Before someone dives in — what's the part that actually trips people up here? Expert: The trap is treating each incoming request as independent. People write code that handles one request beautifully, test it, it works, they move on. Then they try a real multi-turn conversation and everything falls apart because the second request doesn't know anything about the first. So before you start, draw the lifecycle on paper. A session gets created, gets updated many times, eventually gets finished or abandoned. Your storage — which in this exercise is just a simple in-memory lookup table, meaning it lives in the server's memory and disappears when the server restarts — needs to support all four of those moves: create, read, update, and list. Get that lifecycle clear in your head before you write a single line, and the code almost writes itself. Host: Great. So bring it home — what can the listener do after this, and what does it mean for their team? Expert: After this, you'll be able to take any stateful AI workflow — not just discovery interviews, any multi-turn AI process — and expose it as a proper web service that real applications and real users can talk to. That's a huge step up. It means the clever prototype your team built in a notebook can now become something the sales team embeds in their portal, something delivery managers trigger from a dashboard, something that persists across coffee breaks and browser refreshes. This is the final exercise in the discovery objective, so when you finish it, you'll have the complete picture: the interview logic, the language model intelligence layered on top, and now the service wrapper that makes it usable across your organization. That's a production-grade discovery system you can genuinely bring back to your team's architecture discussions. Thanks for listening, and good luck with the build.