Collapse `Message`/`ToolMessage` handling into generic `Component` handling

[AngeloDanducci]

Context

Follow-up to #1542 (allow components to declare their chat role via format_for_llm) and its umbrella #1030 (message serialization). During that work we explored whether the special-cased Message/ToolMessage handling could be collapsed into the generic Component handling - i.e. move message serialization entirely onto the TemplateRepresentation -> Message path so a plain custom Component could express everything a Message can.

The blocker: collapsing Message into Component would regress the #1389 ToolMessage work.

#1389 made tool results round-trip to OpenAI-compatible providers as spec-strict role: "tool" messages with a matching tool_call_id. TemplateRepresentation has since grown role, tool_calls, tool_call_id, and thinking, so a plain Component can already produce a serialization-shaped role: "tool" Message via message_from_template_representation. But ToolMessage still carries live, typed, non-serializable state that TemplateRepresentation cannot express, and that state is consumed by code paths other than the OpenAI serializer.

• mellea/stdlib/components/chat.py lines 261-296 (ToolMessage) - ToolMessage stores _tool (the full ModelToolCall), _tool_output (the raw Python return value of the tool, not a string), arguments, and name. TemplateRepresentation only carries serialization (tool_calls: list[dict], tool_call_id: str) - it has no channel for a live ModelToolCall or a typed tool-output object. A Component -> Message conversion therefore cannot reconstruct a ToolMessage; the typed state is lost.

• mellea/stdlib/functional.py (transform/atransform, ~lines 484, 498-507, 1263, 1277-1286, 1377, 1408) - these paths depend on the live ToolMessage state, not on its serialized form: type(output._tool_output) is type(obj) matches the raw return value by Python type, and chosen_tool._tool.args / chosen_tool._tool.name read the ModelToolCall directly. If tool results were only ever plain Messages reconstructed from a TemplateRepresentation, transform would lose its type-matching and argument-introspection and regress.

• mellea/formatters/chat_formatter.py (case Message(): return c) and mellea/stdlib/components/chat.py (as_chat_history / as_generic_chat_history) - the Message short-circuit returns the object verbatim, so ToolMessage subtype identity (and its _tool.tool_call_id) survives to the backend payload. A collapse that routed every turn through TemplateRepresentation would drop this short-circuit and, with it, the subtype.

What a real collapse would require (for the future design discussion)

1. A way for the intermediate representation to carry live objects, not just serialization - e.g. an optional ModelToolCall / raw tool-output slot on TemplateRepresentation, or a separate live-state channel. This is a departure from the images/audio/role precedent, which are all serialization-shaped
2. A decision on whether a component declaring tool semantics should materialize a ToolMessage (so functional.transform's type-matching keeps working) rather than a plain Message, and how it would supply the raw _tool_output
3. Keeping the functional.py transform/atransform contract (_tool_output type-match, _tool.args/_tool.name introspection) intact through whatever new path replaces the Message short-circuit

Notes

• Open question for the design discussion: is TemplateRepresentation the right home for live/typed state at all, or should Message/ToolMessage remain a deliberately-special "already-materialized" case that bypasses the intermediate representation (the current case Message(): return c short-circuit)? The exploration leans toward the latter being intentional, not accidental
• Related: fix message serialization in Mellea #1030 (umbrella), Support role: "tool" / tool_call_id feedback for tool results #1389 (tool-result role: "tool" / tool_call_id), feat: allow components to declare their chat role via format_for_llm #1542 (component-declared role)

[AngeloDanducci]

CC @jakelorocco , my current understanding captured above

[jakelorocco]

A few thoughts:

• We should probably split our message serialization / intermediate class from the actual Message / ToolMessage class. I think this is something that is continually causing issues for us.
  • I do think TemplateRepresentation may be the spot for this... but it would probably require slightly changing it and hardening its contracts.
• We should break the transform contract if needed. Nobody uses that function, and it was a very early implementation of an idea that has not been borne out / expanded upon in the Mellea code base.

[jakelorocco]

I guess the other thing to consider is that the message format will likely differ between model providers (ie openai / transformers / ollama). I suppose the key insight is that we must be able to:

Actions (Components / MoTs / CBlocks) -> <Intermediate Message Serialization Form> -> <Provider Specific Messages>

This has been mostly implicit / not documented since we handled it arbitrarily between backends, but if we formalize some of the fields with regards to TemplateRepr and add a mandatory step to backends, we could likely handle this along with any edge cases much easier. For instance, we could detect and raise exceptions on fields that can't be handled by a specific backend, etc...

[jakelorocco]

More scattered thoughts from the PR:

On MoT serialization:

If I do:

class C1(Component[C2]):
  ...

class C2(Component)[C3]:
  ...

Then generating from C1, should create a MoT[C2]; ie a ModelOutputThunk that parses as a C2 component.

I don't believe our current generation code does this, but that would potentially mean:

m1 = act(C1, ...)
assert isinstance(m1.parsed_repr, C2)

m2 = act(m1, ...)
assert isinstance(m2.parsed_repr, C3)

• I think the important aspect of this is that the mot should probably still get output exactly as it was returned by the model, but have different generation implications. This is an open question that we should address. Perhaps we should default to serializing a mot exactly as it was given to us as an assistant message but also have the option to pass it back as the parsed_repr with it's output implications. In some cases, the two may also be the same.