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.

[victordibia]

@ekzhu .. do you see any side effects here?
This type of field seems reasonable

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.87%. Comparing base (5c969d3) to head (a2be45b).
Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5372      +/-   ##
==========================================
+ Coverage   77.85%   77.87%   +0.01%     
==========================================
  Files         158      158              
  Lines        9520     9522       +2     
==========================================
+ Hits         7412     7415       +3     
+ Misses       2108     2107       -1     

Flag	Coverage Δ
unittests	77.87% <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).