Concepts
Conversation, Message and Part
A Conversation is one continuous run of Messages between you and one or more NPCs. You can hold as many Conversations with the same NPC as you like; they are separate, and each keeps its own history.
A Message is one turn in a Conversation, written either by you or by one NPC. A Message is not a block of text. It is an ordered list of Parts.
A Part is one piece of a Message: text you read, reasoning the NPC did on the way to it, or a Tool call together with its result.
Why Parts exist
Reasoning and tool use are the two things you most need to see in order to judge an answer, and they are exactly the two things a plain paragraph hides. Splitting a Message into Parts is what makes them visible instead.
A reply that looked up a file, ran a command and then answered arrives as four Parts in the order they happened, not as a paragraph claiming it did those things. A failed Tool call renders as failed rather than disappearing. A call still running renders as in flight.
AgentsVille sends every kind of Part over the same channel, which is why adding new kinds later does not change how a transcript behaves. See ADR 0007.
What you see
Text is the answer. It is the only Part kind that is also stored as flat text, which is what Conversation titles and the copy button use.
Reasoning is what the NPC considered before answering. It is visually distinct from the answer and collapsed by default, and it is never folded into the flat text — a title or a copied reply will not leak it. Reasoning only appears when the NPC has thinking switched on, which is off by default.
Tool calls show the tool's name, the arguments the NPC sent, and what came back. Every Tool an NPC uses appears this way: a Sandbox command, an MCP Server's tool, a Memory write, a Skill being loaded, a handoff to another NPC in a Party. See Reading thinking and tool calls.
A reloaded transcript is the streamed transcript
The same logic assembles Parts on the server and in the browser, so reloading the page gives you exactly what you watched arrive — same Parts, same order, no reordering and no collapsing. A four-hundred-token reply is one text Part, not four hundred fragments.
Stopping a reply
Stopping keeps what had already arrived. It is not instant: the reply unwinds at the next Part rather than the moment you click, so with a fast Provider that is milliseconds and with a silent one it waits for the Provider's own timeout.
Anything produced before it unwinds is kept, including a Part that landed after you left. It was produced, so it was billed, and the stored reply should match what the Provider actually wrote.
Long Conversations
History is trimmed before it is sent, not after the Provider rejects it. The recent turns are kept, and what falls off the front is written into a rolling summary of the Conversation, so "as we agreed earlier" still means something.
Nothing is deleted when this happens — the older Messages stay in the database and stay on screen. Only what the model is handed each turn is bounded. For anything that should survive the Conversation entirely, use Memory.
Next
- Party — more than one NPC in the same Conversation.
- Tools — what produces the tool-call Parts.
- Usage — what a Message costs.
Further reading
- Context Engineering: History, Tool Output, and What to Measure — how a long Conversation's history and its Tool output are kept inside the window, on the Codebrewerz blog.