Add metadata field to basemessage

[husseinmozannar]

Add metadata field to BaseMessage.

Why?

• additional metadata field can track 1) timestamp if needed, 2) flags about the message. For instance, a use case is a metadata field {"internal":"yes"} that would hide messages from being displayed in an application or studio.

As long as an extra field is added to basemessage that is not consumed by existing agents, I am happy.

Notes:

• We can also only add it to BaseChatMessage, that would be fine
• I don't care what the extra field is called as long as there is an extra field somewhere
• I don't have preference for the type, a str could work, but a dict would be more useful.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 75.66%. Comparing base (c302b54) to head (e676bb5).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5372      +/-   ##
==========================================
- Coverage   75.67%   75.66%   -0.01%     
==========================================
  Files         171      171              
  Lines       10576    10578       +2     
==========================================
+ Hits         8003     8004       +1     
- Misses       2573     2574       +1     

Flag	Coverage Δ
unittests	75.66% <100.00%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jackgerrits]

This kind of generic property bag is somewhat of a dangerous pattern. What is the use case?

[husseinmozannar]

This kind of generic property bag is somewhat of a dangerous pattern. What is the use case?

Please read the PR message again. Another use case is extra content to send alongside the message beyond content. Down the line messages should also support attachments like files/videos/... otherwise agentchat will not be very useful.

[jackgerrits]

Yeah true true. I can see it being useful, but I think the important thing is that agentchat itself should not depend on any properties here. It should be an external concern where this is just the place to funnel that info.

[husseinmozannar]

another use cases is a hack for passing structured messages through metadata, the agent receiving these messages should have specific logic tuned to accept that in an application. If you have another solution for structured messages, I am happy to use that. Currently, the way to pass structured messages is through json.load and json.dump in content which is ugly

[jackgerrits]

I am wondering here if the desired behavior can be achieved via inheriting message types to add the fields you need? Changing the base message type is a big change we would like to avoid if possible.

The way this would work is you inherit from the relevant type and add the fields and when you wnat to read the values you do a type check for the inherited type and cast to get it

[husseinmozannar]

I already do this in my application. This PR is so I avoid having the redundant types when merging possibly into agentchat. If you don't this to be merged, that's fine.

[jackgerrits]

I this, for now, those custom types are the right way to go about this. It might change over time but if it's working thats perfect

[gagb]

I agree with all use case that @husseinmozannar mentioned but I also agree with @jackgerrits that interface in agentchat should remain minimal. If an application wants more fields, it should inherit and extend. This is already pretty easy to do for an application. I do not think we should merge this change (at least not right now).

[gagb]

Lets continue talking in #5385 and make sure Hussein has what he needs to make progress @jackgerrits

[jackgerrits]

Thought more about this - I definitely see the utility in this field. And thinking through the alternatives, I do think this makes the most sense. I am a little nervous about misuse, so we as a team should ensure we don't misuse. There are other related features like file/content attachments and structured messages that we need to build to better support scenarios too. I also just want to just get @ekzhu's take before we go ahead too

[ekzhu]

Comment on #5385

[husseinmozannar]

@ekzhu what would you like to merge this in?