← Course index

Messages, roles, and a reply

A chat is an array of messages. Roles tell the model who is speaking. The next assistant message is the response.

Day 2: Your first chat response·~14 min read

On this page

After this topic

You will be able to draw a conversation as a list, name each role, and explain why deleting a line from that list is the same as the model never having said it.

The chat is a list. That is the whole trick.

The 'chat response' is just the next assistant message. The model continues the list you sent. Nothing is stored on their side unless you send it again.

Yesterday the model was next-token prediction. Today that input has a shape. Almost every chat API — OpenAI-shaped, Anthropic, the AI SDK — takes an ordered list of messages. Each message has a role and content.

system is the rulebook: who the assistant is, what it must not do, how short to be. It is usually one message, at the front, and you reuse it. user is the human. assistant is anything the model already wrote in this thread. Some APIs add a tool role for function results; we will meet that in The loop.

The next completion is always: “given this list, write the next assistant message.” There is no hidden session id that remembers the user. If your server drops the array on refresh, the model starts over. If you omit the last assistant turn, the model cannot use the definition it just gave.

A chat is a list. Each message has a role. The model continues that list. If a turn is not in the array, it never happened.
  • systemdurable instructions (optional, but put rules here, not in every user line)
  • userthis turn’s question or instruction
  • assistantprevious model replies, so the thread has a past
  • You own the arraymemory, a database, or the client until reload

A four-message thread, read slowly

Read this top to bottom the way the model does. First it is told it is a tutor. Then a definition of token is requested. Then it (you) stored the answer. Then a follow-up. The follow-up only makes sense because the assistant line is still there.

This is also why “the model contradicted itself” is often “we did not send the earlier turn.” And why dumping the entire support history into every call gets expensive: every line is tokens, every time.

  1. 01

    Last user line is the question now

    Who pays for tokens? The model can use the earlier definition only because that assistant message is still in the array.

  2. 02

    You store this array

    In memory, in Postgres, in the client until refresh. The HTTP API does not keep a session for you.

  3. 03

    Order matters

    Messages are an ordered history, not a bag of facts. Putting the latest user line in the middle, or repeating system twice, changes what the model attends to.

Wait vs stream

generateText (next topic) waits until the full assistant message exists, then gives you a string. That is how you should learn: one value, easy to log, easy to test.

streamText sends tokens as they are produced. Same messages array, different delivery. The UI can render the first sentence while the last is still being chosen. We do that on Day 3, once this picture is solid. If you stream first, you debug a moving string and a protocol at the same time.

Wait versus stream. generateText gives you one string when the model is done. streamText paints tokens as they arrive. Same request, different delivery.

Docs

Official API reference for this chapter.

Common questions

What is “Messages, roles, and a reply”?
A chat is an array of messages. Roles tell the model who is speaking. The next assistant message is the response.
What will I be able to do after this lesson?
You will be able to draw a conversation as a list, name each role, and explain why deleting a line from that list is the same as the model never having said it.
How long does this lesson take?
About 14 minutes of reading. It is a free chapter in the AI SDK Patterns TypeScript course.

Written by Akash Panchal·Updated August 29, 2026