Welcome.
In this video, we're going to have a look at a concept called time travel.
A time travel is a way for you to be able to replay certain events that have happened inside of your
line graph.
This is a great way for you to easily roll back certain scenarios.
So let's dive in.
Firstly, we're going to import a couple of packages, and we're going to need to set up the OpenAI
API key and the Tahvili API key.
You can also if you want, set up a Langsamt API key as well.
Now just a bit more on time travel.
You know, in a typical chatbot workflow, you know your users respond to certain messages and won the
conversation, or the chat history ends, then that's kind of finish.
And we can obviously look to how you can add memory to that chat history, and also how you can add
a human in the loop node.
But this kind of takes a bit further in terms of what happens if your user wants to start from a previous
response, or if the user wants to be able to rewind part of the graph execution, but to maybe correct
certain types of mistakes.
And so you can use line graphs built in time travel functionality.
And we'll be looking at a method that's called the Getstate history.
And the Getstate history method basically has all of the graph snapshots for the entire duration of
that land graph execution.
So we've got a couple of imports that we that we have here.
And we've got the line graph state, which is just the messages.
And we've got an annotated reducer function telling it to add in the extra message.
This flag, we've seen it before the off screen.
And we've also got our request assistance tool.
And we set up our tools are basically being tavileh.
And we also bind to the LM both the tools and the request assistance tool.
Now, this chatbot node here will basically determine whether the ask human should be set to true,
and also invokes the response as well.
But we have the graph that we start building.
We add the chatbot node the tools node which contains the tool node.
Combining combining our research results tool, we have the create response which will return a tool
message, and the human node which typically won't actually be used in terms of the actual graph, will
just be updating.
Just before we and interrupting before we actually hit that node.
Now we also have a select node function and you'll see if the state is ask human.
Then we go to the human node.
Else we return this tools condition.
And the tools condition will just basically route to the tools node.
So the tools condition like if there's a tool then what it will do is it will go into this tool node.
Here we've got the conditional edges that are set up.
And we are um, going to be using a SQLite saver from a connection string of memory and putting that
in as a check pointer.
And notice here how it interrupting before the human node.
Now now that this is run, let's have a look and see what our graph looks like after it's been compiled.
You can see we're starting in in here and going into the chatbot mode.
And then we're either going into the human in the loop node or we're we're doing tools.
And then after that we're then ending.
So let's let's get our graph doing a couple of steps.
So I'm going to ask it to say you know I'm learning line graph.
Can you do some research.
And you can see it's decided to make a tool call to table search engine results.
And here's the information it's provided back I can say you know, that's helpful.
They want to build an autonomous agent with that.
And then, you know, it sounds like a fascinating project.
Just let us know if you've got any need for assistance or guidance along the way.
Now this is where it gets quite interesting where we can use this graph dot get state history function.
So this get state history function is a generator object.
And if we look at what is inside here we'll just do a have a look at the first one.
You'll see we get a stationery shop which has a values key.
And the values on this has all of the messages.
It also has things like, you know the boolean states of the graph.
Ask human.
There's other things that you could look at as well on here.
But so for example let's scroll along.
You can obviously get other things like when this when this was created at what the what the parent
config is.
And also notice we get a thread timestamp.
And we also have some metadata as well at usage metadata.
So a couple of different things that can be useful to know about I would generally say that yeah, the
most important things are going to be this thread timestamp.
And as well as that you know also getting the values out for specific different bits of the state history.
In our scenario, we're going to loop over the get state history function.
And we pass in the config for the graph.
So we pass in the runnable config.
And the reason why we pass in the config here is if you remember earlier, the config actually contains
the thread id.
And so this tells the graph exactly where to get the state history from for this specific thread.
Now we can then say okay, well let's print all the messages and the length of those and what bits of
the state will be coming next.
And you'll see that if we're looking from the bottom up, because when you do checkpointing, you're
actually working in reverse.
You can see that, you know, the last piece of state we had, we sort of had no next state to go to.
This one we had the chatbot states go to and then this one here we started again.
And so maybe we want to roll back to a previous state.
So in this scenario I've said let's go back to a lake for three.
So let's have a look at that as well.
So I'm going to just run that code.
And now you can see that we have the next node in our in our graph execute is now the chatbot node.
Additionally if you have a look at this when we do when we get the runnable config from that, that
state snapshot config gets us the runnable config on that specific snapshot.
And what's interesting about this is it adds on this thread RTS, which is the timestamp of when that
specific checkpoint happened.
And that's useful because then we can basically go inside our graph stream.
We can say, well, we're not going to add any new input for now, but we just want to replay from here
onwards.
And what you'll see is we're able to replay this new thing here, which is the message straight off,
which is the AI message.
So that's a really great way for us to be able to easily roll back the graph implementation to a specific
point and then rerun the graph.
It's also worth noting that you could as well also have added input into this.
So there's no reason why.
You know, if you wanted, you could also revert the graph back to that implementation, but then also
add on additional inputs.
And so time travel gives you the ability as the developer to decide to the user.
Can they revert back to a previous state inside of the graph execution.
What kind of corrections can they do?
All of these things are really, really useful for building these kind of state machine hierarchical
workflows.
That means that users are going to be able to interact with your app more effectively.