How AI Chatbots Are Built: A Practical 5-Stage Tutorial (2026)

# Core idea

# Why that matters Because every request includes the whole history, longer chats cost more and eventually hit model input limits. Cost grows faster than you might expect: each new user message is sent along with everything that came before, so budgets planned per-message are misleading. What looks like model memory is actually the app re-supplying earlier user data in a later request.

# Minimal working chatbot (stage one) The tutorial shows a practical twenty-line Python chatbot using requests and a KodeKey API key. The key points in that minimal example:

• messages is a list of dicts with three possible roles: system, user, assistant.

• Use raise_for_status to convert HTTP failures into clear exceptions.

# System prompt as the personality (stage two) The system message is just the first message in the list sent every call. It sets behaviour (style, tone, constraints) by being part of the conversation rather than a hidden controller. The tutorial gives an example system prompt for a Kubernetes support assistant and explains how practical constraints (answer length, spelling variant, when to refuse) are encoded there.

# Memory strategies and pruning Because history is resubmitted each turn, a production system must decide what to drop when the chat grows too long. The article frames memory strategies around the single question: what do you throw away when the chat no longer fits? The app can summarize, archive, or selectively remove earlier messages so later requests stay within token limits and cost targets.

# Streaming and user experience Streaming the model response changes responsiveness, not the model output. Streaming lets the app present partial output earlier, improving perceived speed. The underlying mechanism—resending the message list every turn—remains the same.

• Use a virtualenv and keep the API key in an environment variable to avoid accidental commits.
• Always add raise_for_status or equivalent error handling for request failures.
• Choose temperature based on the task: low for reproducible answers, higher for creative responses.
• Plan and implement a message-pruning or summarization strategy before chat length becomes a cost or token-limit problem.

# Bottom line clarifies many common chatbot behaviors: occasional forgetting, rising costs, and the need for explicit memory management. Building a simple chatbot quickly reveals the trade-offs behind every design choice.