system
, user
)SystemMessage
represent an initial set of instructions that primes the
model’s behavior. You can use a system message to set the tone, define the
model’s role, and establish guidelines for responses.
HumanMessage
represents user input and interactions. They can contain text,
images, audio, files, and any other amount of multimodal content.
name
field behavior varies by provider - some use it for user
identification, others ignore it. To check, refer to the model provider’s
reference.AIMessage
represents the output of a model invocation. They can include
multimodal data, tool calls, and provider-specific metadata that you can later
access.
AIMessage
objects are returned by the model when calling it, which contains
all of the associated metadata in the response. However, that doesn’t mean that’s
the only place they can be created/ modified from.
Providers weight/contextualize types of messages differently, which means it is
sometimes helpful to create a new AIMessage
object and insert it into the
message history as if it came from the model.
AIMessageChunk
objects that can be combined:
artifact
field stores supplementary data that won’t be sent to the
model but can be accessed programmatically. This is useful for storing raw
results, debugging information, or data for downstream processing without
cluttering the model’s context.Example: Using artifact for raw data
AIMessage
objects will store the output of the model inside of the content
attribute. If you want to access content in a way that won’t change between providers, you
can access the content_blocks
attribute, which will return a list of content blocks that adhere
to the standard content format.
.content
differently, you can also initialize a message
with a list of content blocks. This will ensure that the message is always in the
standard format, regardless of the provider.
content_blocks
attribute) as a list of typed dictionaries. Each item in the list
must adhere to one of the following block types:
Core
TextContentBlock
Multimodal
PlainTextContentBlock
ImageContentBlock
AudioContentBlock
VideoContentBlock
Tool Calling
ToolCall
ToolCallChunk
Server-Side Tool Execution
WebSearchCall
WebSearchResult
CodeInterpreterCall
content
property, but rather a new property that can be used to access the
content of a message in a standardized format.
.content_blocks
is a computed property that outputs standard blocks based on .content
. Because of this
content blocks will not be included in the output when a message gets stringified/serialized by default.
If you want to serialize a message that uses standard content blocks (e.g.
if you were passing messages to a client), there’s a couple of different options to instruct the model to
output a message using standard content blocks:
.content
as a list of
standard content blocks (the same as if you were accessing .content_blocks
).
Aspect | v0 | v1 (Standard) |
---|---|---|
Default behavior | Yes | Accessible through .content_blocks |
Serialization | content is raw model output | content is a list of ContentBlock objects |
Content format | Provider-specific | Standardized ContentBlock types |
Type safety | Limited | Fully typed |
Multimodal support | Basic | Comprehensive |