Update Get Thread History​ API to return a list of {values, messages} instead of a list of checkpoint

[MadaraUchiha-314]

1. Checkpoint is associated with a graph
2. Graph is associated with an agent
3. Agent is associated with a run
4. Run is associated with a thread

The concept of checkpoint doesn't make any sense to be stored in the context of a Thread. Instead it should be stored within a Run.

I propose to update the Get Thread History​ API to return a list of {values, messages}(s) instead of a list of checkpoints

[hinthornw]

How would you prefer to access checkpoints/snapshots within a workflow? Say you have a 2-agent system and you want to roll back to the point where agent B called the model the second time

[MadaraUchiha-314]

How would you prefer to access checkpoints/snapshots within a workflow? Say you have a 2-agent system and you want to roll back to the point where agent B called the model the second time

1. Identify the run associated with agent-B
2. Identify the checkpoint associated before agent-B called the model the 2nd time
3. Identify how to resume run or create a new run from that particular checkpoint
4. Patch the thread with the new value

[MadaraUchiha-314]

A thread has no underlying entity like a graph to have a checkpoint. The only attributes a thread has is values and messages

So the Get Thread History​ API should return a list of those attributes instead of checkpoints.

[MadaraUchiha-314]

Nuno Campos (@nfcampos) Any thoughts on this ?

[nfcampos]

Thread history already returns a list of objects with messages and values properties, checkpoint is just the name we give to a history entry. A checkpoint is created by a run, but it logically belongs to a thread.