Feature request: add field support

[DennySORA]

Description

I propose extending the current protocol to better support reasoning and event tracking.
This involves adding new fields to existing message types and introducing a new ThinkingMessage class.

Proposed Changes

1. BaseMessage

   • Add a timestamp field to record message creation time.

2. ThinkingTextMessage Events

   • Applicable to:

     • ThinkingTextMessageStartEvent
     • ThinkingTextMessageContentEvent
     • ThinkingTextMessageEndEvent

   • Add a thinking_id field to associate events with a specific reasoning process.

3. Message Class Extensions

   • Introduce a new ThinkingMessage type within Message.

   class ThinkingMessage(BaseMessage):
       role: Literal["thinking"] = "thinking"
       content: str  # The reasoning content to display

Rationale

• timestamp ensures temporal tracking of messages for better debugging, ordering, and replay scenarios.
• thinking_id allows correlation of multiple reasoning events within the same process.
• ThinkingMessage provides a clear representation of reasoning content, separated from user/system messages, improving protocol clarity and extensibility.

Expected Impact

• More robust event correlation.
• Better support for reasoning transparency.
• Easier debugging and auditing of protocol interactions.

[NathanTarbert]

Hey @DennySORA, thank you for creating the proposal. I've added it to our roadmap under consideration. Is this something you would like to take on?

@mme, would love to get your thoughts here.

[DennySORA]

@NathanTarbert
No problem. I will take ownership of the Python-related components.

We currently run AGUI + ADK in production. The frontend requires additional fields for rendering, so I had to extend the schema. An upstream update to the official models would be very helpful. For now, I have subclassed the existing models and added the required fields.

I am discussing with my company the open-sourcing of adk-agui-middleware. It is production-grade middleware with complete type hints and a design that follows SOLID principles. The plan is to release it under the company’s name, and we will notify you when it is public.

One more note: there is an issue in Python’s encoder.py that is not compliant with the Server-Sent Events (SSE) specification. I have patched this in the middleware. If useful, I can prepare and submit a fix upstream as well.

If our product later needs additional fields or related capabilities, I will propose them for your consideration. I hope this protocol can become an industry benchmark.