A support assistant that answers from docs and can actually look things up
One concrete feature, to tie fourteen articles of individual pieces into a single system: a customer support assistant. It answers questions from product documentation, can look up a real customer's account and billing status when a question needs it, and hands off to a human when it isn't confident or the request is out of scope.
Nothing about that description is exotic, which is the point. It needs an LLM API call at its core, a system prompt that actually specifies its behavior instead of vaguely asking it to "be helpful," retrieval over a documentation corpus that changes every time a product update ships, and one tool for account lookups. It does not need a five-agent orchestration or a fine-tuned model, and deciding that up front, deliberately, is itself part of the architecture.
The rest of this article walks the request end to end, then works backward through what has to exist before any of it can ship responsibly.
The request path, and everything running alongside it
Follow one message from the user through the system, and almost every article in this series shows up as one step in the path.
The request path
1user message2 -> assemble context (system prompt + retrieved docs + trimmed history) [Context Engineering]3 -> retrieve relevant doc chunks for this question [Embeddings, RAG]4 -> model call, may request the account-lookup tool [Tool Calling]5 -> execute tool if requested, feed result back, model call again [Agents and Tool Use]6 -> output filter checks the response before it's shown [Guardrails]7 -> stream the response to the user [Latency and Streaming]
None of that runs in isolation. A background pipeline keeps the documentation index current every time the docs change, chunking and embedding new content the same way the original corpus was built. Every step in the request path emits a trace, the full request, which tool was called and with what arguments, what got retrieved, so a wrong answer is something you can actually investigate. Every change to the system prompt or the retrieval setup runs against a golden set before it ships, the same discipline this series has applied to every article that touched a prompt.
The account-lookup tool only exists in this session because this feature genuinely needs it, and it exposes nothing beyond read access to the current user's own account, least-privilege scoping applied for exactly the reason the Guardrails article argued for it.
The budget is a product decision, not an afterthought found in a bill
This is a chat interface a person is actively waiting on, which sets the latency target directly: streaming makes a multi-second total response feel immediate, from Latency, Cost, and Streaming earlier in this series, so the target is a fast first token, not a fast total completion.
Cost per conversation gets a real number attached to it too, not left as "whatever it ends up being." Most questions here are routine enough for a cheaper, faster model to handle correctly, and only the fraction that needs deeper reasoning or a longer tool-use chain justifies the more expensive one, the cascade pattern from earlier in this series, evaluated against this product's own golden set rather than assumed to transfer from somewhere else.
Prompt caching applies directly here too: the system prompt and the retrieved documentation are the stable part of every call, structured to sit first so repeated calls against the same context actually benefit from it, instead of paying full price to reprocess the same instructions on every single message in a conversation.
What actually has to be true before this goes live
Not a demo working once in a playground. A specific, checkable list, each item earned by a specific article in this series rather than assumed.
The golden set passes, including the deliberately ugly cases, off-topic questions, empty input, a question the documentation genuinely doesn't answer. The account-lookup tool has no permissions beyond what this feature needs, and a proposed action that looks out of scope gets caught by the output filter before it takes effect. Every request is traced end to end, so "the assistant gave a wrong answer" is something that can actually be investigated instead of shrugged at. And there's a real answer, tested and not just assumed, for what happens when confidence is low: a clear handoff to a human, not a confident guess dressed up as one.
Just as deliberate is the list of what this version doesn't do. No fine-tuning, prompting and retrieval handle this task without it. No multi-agent orchestration, one agent with a small, well-scoped toolset covers everything this feature actually needs to do. Both are real capabilities covered earlier in this series, and both are correctly absent here, because the simpler system was sufficient and reaching for either without a specific reason would have added cost and failure surface for nothing in return.
Every piece across all fifteen articles in this series exists to answer one question honestly, for this specific feature: not whether it's impressive, but whether it works, whether it's checked, and whether someone will actually know when it stops working. That's the whole job.