The content of AIMessage could differ between different providers.

For example:

• OpenAI gpt-5-nano responds with single string
• Gemini gemini-3-* models respond with list of content-blocks. Those are dictionaries that include additional information.

An example of Gemini's content-block could look like this:

{
    "type": "text",
    "text": "test-content-block",
    "extras": {
          # simulate gemini model returning thought signature in extra field of text content block
          "signature": "EjQKMgEMOdbHDmsQ+BTM6duYJ43i5npxkpn28Ir0VjD1p6w4fUqIdYszIcWx+XcqAW1a8E+Q"
      }
}

This content-block contains additional information such as the thought signatures that the Gemini models use.
Additionaly, the Gemini models include the thought signatures in langchain's AIMessage.additional_kwargs when issuing a tool call - this is also addressed here by adding an extras field to the SDK AIMessage.

All those changes should accomodate to the model providers sending additional information along their responses.

NOTE: This change slightly changes the API, since we change the type of AIMessage.content from str to str | list[str | ContentBlock].
It also adds new ContentBlock type to note that the response from LLM is structured (not a string).

Currently, only the TextBlock is supported, since I didn't see any other one returned from the LLMs I had access to. Other "unsupported" content blocks are stored in OpaqueBlocks which are created to persist blocks that are returned by LLM, but not useful for the SDKs. Those would be returned back to the LLM so that the context is preserved. We can add support to other blocks if needed.

The developers should handle possible formats of responses by checking the type or use structured outputs to make sure every model responds with the same format.