Messages, Roles and Conversation State
Understand system, user and assistant messages and store conversations correctly in your own app.
A taste of a lesson
My chatbot forgets the user's name after one message. How do I make it remember?
The model never remembers anything between calls; each request is read fresh. To keep the name, your app must store the conversation and send it again every time: the system prompt, then the earlier user and assistant messages, then the new message. If the user said their name two turns ago, that message has to be in the list you send now. Check your code: are you sending only the latest user message, or the whole stored history?
Written by the teacher as an example. In your lesson the tutor answers your own questions, and like any AI it can be wrong.
What you will be able to do
- Explain the system, user, assistant and tool roles
- Send conversation history correctly with each stateless request
- Design storage that keeps every user's conversations separate
- Trim or summarise history when it nears the context limit
- Recognise why user messages cannot be trusted as instructions
Lesson plan
- 1 The four kinds of message Describe what each role means and what the model does with it. Start
- 2 Stateless by design Understand why the app, not the model, holds the conversation. Start
- 3 Storing conversations Design simple tables for conversations and messages. Start
- 4 Sending history each turn Assemble the right message list for each new request. Start
- 5 When conversations get long Keep long chats within the context window without losing what matters. Start
- 6 User text is not an instruction Handle user content that tries to override the system prompt. Start
Try asking
About this tutor
For beginners who have made a first API call and now want a real multi turn conversation in their app. You learn what each role means, how providers differ in where system instructions go, why the API is stateless and what that implies for storage, cost and privacy. You design a simple conversation table, load and send history per request, keep different users' conversations separate, and trim history when it grows near the context limit. The tutor also covers what happens when user content tries to act like instructions, and why message order matters for some APIs.
Reviews
4.5
2 ratingsSample
- Patrick O.Sample
The storage design with user filtering was exactly what I needed. Would have liked more on summarising long chats, but the trade offs were explained honestly.
- Lina A.Sample
Drawing the message list as a table before coding helped a lot. I had been sending only the newest message and wondering why my bot was so forgetful.
About the teacher
Teaches developers and product teams to make their first LLM API calls and design simple apps around them
9 tutors 337 lessons taught Sample
I help people go from having used a chatbot to having an app that calls a model. I built web products for a long time and moved into LLM features when they started appearing in every roadmap, so my lessons focus on the decisions that matter in a first build: how a request is shaped, how a conversation is stored,...
See Gabriela's profile and tutorsMore like this
Other tutors on the same or nearby topics.