LTM and caching relationship improvements

[voidKandy]

long term memory needs a way to somehow contain any objects added to the cache (such as Files or Directories). Need to be stored in RAM in some way that would allow LTM to write out their respective database tables..For files or directories something as simple as their paths would suffice because it would be easy to construct full File and Directory structs with just a filepath.

This is also a good starting place for creating a database api that would allow users to use their own Db schemas

[voidKandy]

Memory.cache should be changed from a MessageVector to a new CachedMemory type that has a generic or trait bound Box or something

[voidKandy]

Most recent changes pushed to master flatten structs into an enum which contains the necessary info for reconstructing the flattened struct. One problem with this is fields who cannot be easily recreated, such as File struct's summary field, have no way of being saved through the flattening process.

Now that theres a process of flattening structs, a new issue has emerged: When adding structs to agent memory, when should a struct be added as a message, and when should it be added as a flattened struct. When it's added as a struct, the agent doesn't have access to the struct's info, or even know it is present in memory. Only when structs are added as messages do agents have access to them.. So should structs always be added to messages, or only when a specific function (currently named force_push_cached_structs_to_messages) is called?

[voidKandy]

The most recent push to stable I have put everything behind the MessageVector Api. Roles other than User, Assistant, System or Function are invalid. Any Other role is coerced into 'system' when the vector is finally sent to the model. But for querying, Other is kept as a valid role. I don't know if this is a perfect implementation but it is working for now.

Any struct that implements ToMessage can be added to agent memory.

To avoid context overload, files loaded into memory are loaded as a summary, if one exists, or as the first chunk of it's chunk vector. An option to dynamically load from LTM needs to be implemented as a RecallMode variant.

[voidKandy]

I will be closing this issue because v0 includes what this sought to improve