If you want to leverage the power of LLMs in your Python apps, you would be wise to consider an Identic framework. Identic empowers the LLMs to use tools and take further actions based on what it's learned at that point. And frameworks provide all the necessary building blocks to weave these into your apps with features like long-term memory and durable resumability. I'm excited to have Sydney Runkle back on the podcast to dive into building Python apps with LangChain and LangGraph.
This is Talk Python To Me, episode 507, recorded Tuesday, May 6th, 2025.
Are
you ready for your host, please?
You're listening to Michael Kennedy on Talk Python To Me.
Live from Portland, Oregon, and this segment was made with Python.
Welcome to Talk Python To Me, a weekly podcast on Python.
This is your host, Michael Kennedy.
Follow me on Mastodon, where I'm @mkennedy, and follow the podcast using @talkpython, both accounts over at Fostadon.org and keep up with the show and listen to over nine years of episodes at talkpython.fm.
If you want to be part of our live episodes, you can find the live streams over on YouTube.
Subscribe to our YouTube channel over at talkpython.fm/youtube and get notified about upcoming shows.
This episode is sponsored by Posit Connect from the makers of Shiny.
Publish, share, and deploy all of your data projects that you're creating using Python.
Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quarto, Reports, Dashboards, and APIs.
Posit Connect supports all of them. Try Posit Connect for free by going to talkpython.fm/posit, B-O-S-I-T. And it's brought to you by Auth0. Auth0 is an easy to implement adaptable authentication and authorization platform. Think easy user logins, social sign-on, multi-factor authentication and robust role-based access control. With over 30 SDKs and quick starts, Auth0 scales with your product at every stage. Get 25,000 monthly active users for free at talkpython.fm/auth0. Hey all, over at Talk Python we have an exciting new course, Polars for Power Users. If you're into data science or you're just looking for a better way to automate your world than tools like Excel and Google Sheets, this course is for you.
And if you already do data science using older tools like Pandas and NumPy, maybe it's time to add Polars to your toolkit.
Whether you're wrangling CSVs, taming messy Excel files, or joining multi-gigabyte datasets, Polars for Power Users shows you exactly how to translate everyday data tasks into clean Pythonic code that runs 10 to 100 times faster than traditional approaches.
Through a pragmatic mix, short lectures, live REPL sessions, and a capstone case study, You'll master Polars fluent syntax, lazy evaluation engine, and productivity-boosting features such as pivot tables, joins, and Excel-style data accessors.
This excellent and very entertaining course was created by Christopher Trudeau.
His deep experience and connections in the Python world are evident right from the start.
Plus, this course doesn't waste your time.
You'll be up and running with Polars in under three hours.
It's currently available for just $29 or less.
Visit talkpython.fm and click Courses in the nav bar or just click the link in your podcast player's show notes.
Thanks to everyone who's taken one of our courses. It really helps support the show.
Now, let's get on to that interview.
Sydney, welcome back to Talk Python To Me. Fantastic to have you here.
Thanks. Super excited to be back.
I'm excited to have you back.
We always get to talk about cool things.
And for a long time, that's been Pydantic.
And the last time you were on, we talked about Pydantic performance tips.
and now it's the topic du jour really.
Building with LLMs, which I think is really, really different than saying I use an LLM to build my code or I use LLMs to answer questions or kind of an alternative search, but actually using it as a library style in your code, right?
Yeah, definitely.
I think you can kind of turn things inside out, right?
And like thinking about all the things that you can build with LLMs, specifically with LangRaph, And just what we're going to chat about today is really exciting.
Yeah,
it is also tricky because as everyone knows who's played with them, LLMs are weirdly not deterministic.
And so programs typically like determinism.
They like, if I call this function, it's going to do a thing.
If I don't call the function, it's not going to do the thing or whatever, right?
So that's a big challenge.
And I think that's part of what your old toolchain is meant to do.
Now, just because you've been on the show a couple of times, there's probably still people out there who don't know who you are, and your role has changed a little bit.
How about a quick introduction into yourself again and what you're doing these days?
I know you made a career transition recently.
My
name is Sydney. Nice to meet folks.
I am a passionate open source developer.
And so on previous episodes, I was on talking about Pydantic and doing kind of open source maintenance there.
So Pydantic is both an open source tool, and now there's a company built around that open source tool.
And I recently switched over to LangChain, excited to be working with an open source team in person in Boston.
So that's quite exciting. And I'm mostly working on maintaining LangGraph now.
So
many folks
are probably familiar with LangChain, the open source package.
We'll probably get into that a little bit more soon.
But LangGraph is kind of our newer agent orchestration framework.
Other than that, yeah, I love just engaging with folks in the open source community, getting excited about building cooler AI applications now. And I don't know, in my free time, I'm quite the podcast addict. So it's always nice to listen to your other podcasts.
Oh, thank you. Well, I know you worked on some cool projects and this certainly is another one of them. I didn't realize they were based in Boston. That's cool.
The
main office is actually in San Francisco, but the company's growing pretty fast. So we now have the Boston office as of last week. So got my nice little call booth background here and then a New York office as well.
Is it off that 128 highway there where a lot of the tech companies are? I'm
actually not super familiar with San Francisco geography,
but... No, no, I'm taking Boston up by like Woburn. Oh,
oh, gotcha. Yeah, we're actually in Harvard Square. Okay.
Oh, very cool. Yeah, proper Boston.
Yes.
Not Boston suburbs where a lot of those companies are out there. Yeah, really cool. So let's just start by talking about AI a little bit. I know some people are AI accelerators. People believe that AI should be just pushed as fast as it can be. And I suspect a lot of folks like that can be found on a playing chain. Also, people can be very hesitant to it, right? I know some people are like, I'm not using it. I won't use it. I'm not sending my data to the big cloud companies or whatever to train their models to take my job or however people perceive this. I'm certainly pretty, I see a ton of value in it. I think it's really quite incredible. But you know, first, what are your thoughts on using LLMs in general? And then two, what is an agent?
I definitely fall more on the accelerator side of things, but with guardrails and constraints and rules and boundaries, which is sort of what we're trying to do with LandGraph, I think it can be really helpful to use LLMs as a development tool. So I personally do that when I'm writing code. I also think it's really helpful to brainstorm with the help of LLMs. And yeah, so I think they're increasingly valuable. And as long as we're being careful about usage, then it's great to kind of lean into their strengths.
Yeah. Reuven Lerner, I just had him on the show a couple episodes ago, and he says he uses the reverse Socratic method with LLMs where he writes the code, then he asks it to, he sort of interrogates it like, well, what's wrong with my code?
What could be better?
When would I use it?
And what am I overlooking?
And it's, there's so many uses, it's wild.
Yeah, it's crazy.
I think sometimes I'll talk to my parents and be like, oh, I use ChatGPT to help me come up with a recipe.
And they're like, you did what?
Like, I didn't even know you could do that.
Whereas folks at work are having, interacting with AI on the hour.
So yeah, so I'll talk a little bit more about what are agents? Agents are a little bit hard to define. I think it's kind of an overloaded term, but many people are kind of leading into that as the future of AI from a developer perspective. So I think about agents as tools that can reason and make decisions for you, specifically LLMs that are powered with things like tool calling and memory and context and things like that. So like chat based model for an LLM to how can you use an LLM in an application.
Okay. So it can call tools like you could give it a request and maybe it's going to go and call, do like web searches or read web pages or you can tell it, go read the docs and then do this thing or something along those lines.
LLMs are trained on older data. And so if you're not enabling your LLMs to use kind of real world data and information, then their utility is limited. But agents have the power to use tools, which are basically like API calls, or it can even be more simple than that, like running some code in order to incorporate your like real time relevant data. And it can also kind of make decisions about like, which tools do I want to use and that sort of thing.
So interesting. I guess it's related to deep research a little bit, right? Like a lot of the deep research thing seem to be kind of using tools and using modern web and other stuff that they can find rather than just whatever the model was when it was constructed? Definitely.
I think about like perplexity is kind of gaining in popularity and what's really good at you can ask it a question and then it does real-time research against like looking things up on the internet and then provides you back with citations which is a really exciting feature I think for folks who are like LLMs can just make anything up.
Like, how do I know this is being pulled from reasonable sources?
And that's kind of an exciting jump in that space.
It is.
And I think it also goes a little ways, not that far, but a little ways to fill that gap where people said these search engines, they just take our data and they give us no credit.
Right.
Yeah.
Which I'm sympathetic to.
However, I do think it says, here's the four places I found and here's the video you should watch if you want to go deeper.
I think that's actually super valuable.
I just asked perplexity a historical question.
Like, what is the age of these people who did this thing hundreds of years ago?
And it said in their work, and it wrote Python code, and then it gave me the answer.
I think it was doing pandas type stuff, but it was sitting there thinking, thinking, and it shows you what it's doing.
And it just says, writing Python, and then boom, out comes the answer.
I'm like, okay, that's weird.
Oh, man.
Was it correct?
Yeah, it was correct, I
think.
Wow.
Wild.
But that's kind of the stuff we're talking about a little bit, right, in this agentic sense.
It's not just like, well, I went to my database.
These are answers I have.
But it's like, well, if I can make this web query and I could write some pandas, then I could format it the way you asked for it, right?
Yeah, there's definitely a lot more kind of reasoning and thinking.
It is a bit of a black box right behind, like, what is the LLM doing?
And so you've got a bit of transparency there with the, like, writing Python code clue.
I wish there was a view source.
You know what I mean?
One
of the things that we're trying to do at LinkChain right now with LandGraph development is to kind of bridge the gap between like, what are the parts of your system that you really need to like understand and kind of be guaranteed are reliable and will always run in the same way versus like, where can you afford to introduce non-determinism in favor of like a bit more maybe agency or utility, but also introducing risk like, who knows what your LLM was doing in the research phase.
It's
just so powerful, but it's also so, scary as a developer to think, I can't debug this. I can't prove that it's going to do the right thing all the time. Right. And I guess it really depends, right? Like Siri, for example, on the iPhone, sorry if that made anybody's phones go off. It's so bad. It's just so weirdly not capable of doing stuff. And you know that if that were backed by an LLM instead, sure, it might make mistakes periodically, but as a net, it would be so much better that it's probably worth it. You know what I mean, on the other hand, you wouldn't want to say, I'm going to create an agentic workflow to determine if you get a mortgage or things like that would be a little bit too much, I think, right?
It would deny people for weird, random reasons.
Right.
You definitely have to consider the stakes and risk and value of a decision that you're making, right?
And like, I think generally I wouldn't empower LLMs to make like the most important decisions in my life on a day-to-day basis.
Like
you said, I do find myself like laughing at series responses more than actually like valuing the response.
It's incredible.
It's setting timers and telling you what the temperature is.
But boy, you're very off very much.
No, no, it doesn't.
It just doesn't do it.
Okay.
So when would you use, I mean, I talked about examples you wouldn't use.
Give us examples of when you might really embrace these things.
We've
talked about the non-determinism of LLM behavior, right?
But also kind of the power of an agent is in making decisions for you.
And if you can give your large language model the appropriate context and descriptions of tools so that it can do a good job making decisions for you, then that can save you a lot of time.
So one classic example I'll probably touch on a couple times today is you might build an email agent.
And so the value of that email agent, right, is that it can categorize emails for you.
Maybe some things are spam, some things need immediate response, some things can even be automatically responded to, and then said agent could learn from your preferences over time. So maybe before an automatic reply is sent out, you, the user, get to approve that reply, but you didn't have to do all the work of drafting and that sort of thing.
And so I think the greatest value that I see in developing workflows with agents is if you can come up with systems that we call like ambient workflows, basically, instead of responding to some user prompt, like, hey, what's the weather? They're running to in response to external triggers. So in this example, like the email that you received. And so basically, you're trying to create a system that does work and automates work for you.
Yeah, that's cool. It could determine if it's, is this an emergency? Is this something, a tech support type thing? Is it an accounting thing? And then it could just maybe do a little bit of work through your docs, give a response and then forward it to the right person or something like that, right?
I
think we think about like chatbots on like websites that help users as another common example.
And when you're talking with a chatbot, at what point does it decide like, you know what, we need to escalate this and like actually provide them with a phone number to call with a real person or that sort of thing.
I
definitely see this as being one of the more powerful, more common ways that allow them to actually interact with people.
It's kind of weird that it's a chat.
You know what I mean?
It is pretty useful, but it's also just weird that it's like, okay, we're going to have this chat with this thing, whereas it could do so much more.
Yeah. You mean with the chatbot example?
Yeah,
exactly. Or even ChatGPT itself or something like that, right?
Yeah. I think that's kind of why we're so excited about the ambient or background system pattern is a chat is super helpful if I'm like, I have these five ingredients in my fridge. What should I make for dinner?
That's like a very simplistic pattern.
And we think you should kind of build a system that is only as simple as you need.
But then I think the real value comes when you're responding to those external like real-time triggers.
Can one of them be like a cron job?
Like every hour, check this stock price or every hour, evaluate the sentiment of this community and then do something.
Yeah, definitely.
I think as we get more into discussing how you can build workflows with LandGraph, it'll become pretty evident how you can schedule things.
And that's a very predictable pattern, right?
Maybe
as useful for you, I can imagine for the case where you're running something on a schedule.
The end result might be like, okay, you've analyzed sentiment.
Do I need to send an alert to my user or things like that?
This portion of Talk Python To Me is brought to you by the folks at Posit.
Posit has made a huge investment in the Python community lately.
Known originally for RStudio, they've been building out a suite of tools and services for Team Python.
Over the past few years, we've all learned some pretty scary terms.
Hypersquatting, supply chain attack, obfuscated code, and more.
These all orbit around the idea that when you install Python packages, you're effectively running arbitrary code off the internet on your dev machine, and usually even on your servers.
But thought alone makes me shudder.
And this doesn't even touch the reproducibility issues surrounding external packages.
But there are tools to help.
Posit Package Manager can solve both problems for you.
Think of Posit Package Manager as your personal package concierge.
You use it to build your own package repositories within your firewall that keep your project safe.
You can upload your own internal packages to share or import packages directly from PyPI.
Your team members can install from these repos in normal ways using tools like pip, Poetry, and uv.
Posit Package Manager can help you manage updates ensuring you're using the latest, most secure versions of your packages but it also takes point-in-time snapshots of your repos which you can use to rerun your code reproducibly in the future Posit Package Manager reports on packages with known CVEs and other vulnerabilities so you can keep ahead of threats and if you need the highest level of security you can even run Posit Package Manager in air-gapped environments If you work on our data science team where security matters, you owe it to you and your org to check out Posit Package Manager.
Visit talkpython.fm/ppm today and get a three-month free trial to see if it's a good fit.
That's talkpython.fm/ppm.
The link is in your podcast player's show notes.
Thank you to Posit for supporting the show.
Well, let's talk a bit about, I guess, Langchain first.
So there's a lot of things going on here, right?
There's Langchain, the company.
There's LangChain, the open source project.
There's LangGraph.
Tell us about all these things.
Yeah, so happy to give kind of an overview.
So LangChain, the open source tool, is basically a tool for developers to use LLMs and really increase the value of LLMs or kind of augment the power of LLMs with your data.
And so some of the things that we've built in LangChain include abstractions around chat models.
So you can decide you're going to use the 4.1 model and you want to use some different settings, like maybe set the temperature to zero or only send some maximum number of tokens or things like that.
And then specifically, a lot of the value from LinkChain, the open source tool, comes from introducing this model agnostic interface.
So if I want to chain a bunch of model responses together, it's kind of hard to do that if I am separately querying the OpenAI API.
and then the Anthropic API, and then trying to work with Gemini as well.
There are kind of different response formats and features, et cetera.
And so Langchain makes it really easy for developers to use all of those different model providers in a single application.
That's interesting.
So if I wanted, I could bring my own LLM?
Is that possible?
Yes.
Right, like I could use Olama or LM Studio or one of those things rather than the full cloud version?
Definitely,
which is nice just from an extensibility point of view.
And then if you want to use that LLM and then start to use some other more commercially available ones as well, you can combine those.
And so the name Langchain comes together when we think about chains of systems.
One common example that we use is RAG, right?
So you have your vector store, some user asks a question and you fetch the relevant data from the vector store and then you kind of feed that into the LLM.
And so that was a very common pattern like folks, LangChain users would implement.
Yeah, very cool.
And then LangGraph.
LangGraph is more about building workflows out of this, right?
LangGraph is kind of the evolution of LangChain and it has two main things that we focus on.
So it's got a low-level system for building graphs.
So you can think of that, the very like computer science.
Folks will be excited to hear the terms like nodes and edges, right?
You're building this low-level system.
You can control the flow of data or the flow of your application.
You can have conditional branches.
You can run nodes in parallel, all of those kind of exciting graph features.
And then we also have, and you can see here, what we call pre-builds, which help you build agents on top of that graph framework.
So the promise of LaneGraph is that it's extensible because we have those low-level building blocks, but then also very easy to get started with an agent
application.
Yeah, like one of the examples you have, the GitHub page is create React agent from the prebuilt graphs.
Is that React as in JavaScript's React framework or just a reactive thing?
Good question.
So that's React is kind of a common term in the agent building space.
So it's reasoning and action agent.
I see.
So it has nothing to do with JavaScript necessarily.
No,
it does not.
We actually will be probably changing this name soon to just create agent to be a little bit more clear for folks.
Yeah, super cool.
So I guess give us a sense of maybe, well, I want to, let me circle back to some stuff you talked about that I want to talk about.
Why not just call OpenAI or something like that?
It's API directly.
But you mentioned tokens and, oh gosh, what was the other thing?
I think I mentioned temperature.
Temperature,
that was the one.
Yes, thank you.
Temperature.
So LLMs can have a certain amount of creativity is maybe the right word, but not really.
a certain amount of flexibility in, I guess, almost randomness in the amount of the way that it works its way through finding the answers. And the higher the temperature, the more you let it be creative and wonder, whereas the lower the temperature, you're like, no, just give me the closest answer with the least amount of variability. I imagine that that is really an important consideration in building these types of things because it probably significantly influences how deterministic a thing is.
Yeah, I think a great way to think about it is if your temperature is low, let's say we're going on a scale of like zero to one. So if your temperature is like zero to 0.3, it's more deterministic. We can't say like guaranteed to be fully deterministic. But I think when you're building a system that's going to be deployed for users or basically a production ready system, you're certainly going to lean on the side of lower temperature. But, you know, for more creative applications, it's nice to have that setting be pretty configurable just so you can really see what kind of ideas your LLM can help you with.
Right, right.
I want to, you helped me think creatively about doing this thing and what are my options, right?
Like that kind of thing, you probably don't want to set temperature to zero, but when you're building workflows, I imagine it's usually more tending lower.
Definitely.
Sort of a like silly example of maybe when you would set the temperature to higher is I was doing some shopping this weekend and stumbled upon a listing on Facebook Marketplace and the listing had a riddle as the description.
And it was like, if you solve this riddle, you can have this bedside table for free.
And so plugging the riddle into ChatGPT with a higher temperature might be more valuable there.
Obviously more of a like toy example, but kind of shows the utility there.
I've
been doing a bunch of stuff on Facebook Marketplace.
That is in a crazy place.
It's the new Craigslist.
It's really weird.
Indeed.
Yeah, that's a wild, wild example.
And the other one that I think is probably important to define would be just tokens.
because a lot of the models, especially the local models, I don't want to send my data off.
I want to run OLAMA.
I want to run LMStudio.
Those are quite limited, right?
Like 8,000 tokens versus half a million for some of the cloud models, right?
So that can be really a significant consideration as well.
What are they?
They're not exactly words, but they're kind of words, but they're not words.
It's basically just a way to quantify the amount of data that you're sending to your LLM.
And so they also can be used to quantify the amount of data or text that your LLM is sending out as well.
So you'll have like input tokens and output tokens.
Generally, you can kind of equate them to characters.
I think there's a little bit of like nuance there, but I think the simple explanation, that's good enough.
And the value of such a wide, what we call like context window, is that the more context and direction your LLM has, the better it's going to perform.
And so if you have those bigger windows, you can write more verbose instructions and, yeah, just write more clear guidelines for your LLM to follow.
You can also put more relevant context for if your, you know, system is answering questions, maybe you need to, like, yeah, provide just relevant context there.
And we'll talk a little bit more down the line about the value of, like, memory and long-term storage in agentic applications.
And so we'll often like feed back in some of the important things logged in memory.
And so if you have that bigger context window, you can send in more of that data as well.
So that might be like user preferences or previous responses or previous messages, that sort of thing.
Yeah, and if you run out of that space, then it's kind of as if the first part of the conversation, which might include important instructions like we are working on this project, here is our goal, would just kind of either drop off or it would be a runtime error or something.
So yeah, it super matters.
I guess one other important note around tokens is that's often how you're charged for LLM use.
Like if you are using more.
Yes, exactly.
More
tokens on input and more tokens on output is higher cost.
But that higher cost is often worth the significant performance improvement.
Yeah, so that's for the cloud usage-based ones.
Certainly that's what you get charged.
And that's some of the appeal of the local ones.
But the local ones, they can't answer the questions as well.
They don't have as much data.
Are there local models that do agentic stuff?
Or would I do something like lane graph talking to, I don't know, Mistral or something running, like a 7 billion parameter Mistral running locally?
Would I use lane graph to get that agentic behavior and things like that?
One of the main features that we think about when we think about agentic behavior is that like tool calling ability.
And so I think if a model doesn't have support for that, then its utility is more limited.
But that being said, as long as the model can reason and provide guidance, then you can certainly kind of build an agentic application around it with LaneGraph.
Yeah, very neat.
All right, so my other question before we got distracted on this terminology thing, it was, why not just call the LLM directly?
What's wrong with that?
Which I can think of a couple of things, but, you know, lay it out for us.
The most important thing to think about is controllability and reliability.
So one of the main kind of hallmark features of LaneGraph is this human-in-the-loop support.
So you can send a request to your LLM, and then it's going to return a response.
And maybe before you do anything with that response, you probably want to check that maybe the tool call that it made is okay, or whatever expensive or risky operation that is about to be run.
you want to confirm that or maybe edit the parameters or that sort of thing.
And so I think for very simple chat-based applications, just calling the LLM is okay.
You can use LangChain to specify some of those model setting parameters easily or use different LLMs.
But anytime you want to build something with just more reliability, I think you definitely want more of a framework around it that provides those kind of guardrails.
There's also things like persistence and durability, which if you've had a long, drawn-out conversation with these APIs, that can be a big deal, right?
One of the nice things about Lingrath is that we offer kind of short-term and long-term persistence.
So you can have persistence across just a conversation, so like kind of one thread of discussion or one application run, and then also across runs.
So going back
to the assistant
example, you probably want your email assistant to learn from your long-term preferences, rather than just your like single human in the loop edit on one email that came in, for example.
You might say, I know you flagged this to be forward over here, but when it looks like this, I need you to take that into account and it means something different.
You want it to know that forever.
Exactly.
At
the same time, people get freaked out.
I think ChatGPT started identifying your name and addressing you by name without you saying what your name is, and it freaked people out.
It's like, well, you've been giving it your secrets for six months.
I think my equivalent of being a little freaked out by ChatGPT was I was asking it for some like birthday gift ideas for my partner.
And it was like, oh, I think based on your previous commentary about your hobbies and things you like to do with your partner, then like, here's some ideas.
And I was like, wait a minute.
I didn't tell you that today.
Like, I didn't mention that I like to run and go on hikes, but you know that.
It's spionomic.
No, wait, I told it this over and over and over.
But yeah, it's very interesting.
Yeah.
Mostly useful.
Somewhat weird.
All right, let's maybe talk through, to give people a sense how this might work, let's maybe just talk through like a quick start example.
I know talking about code is a bit troublesome on audio formats, but we'll just keep it like high level.
But give us a sense of what is it like to write some code here.
Maybe we could just talk through the quick start for line graph.
Our
quick start is now kind of focused around creating a simple agent.
So you can use that create React agent method that we talked about to create a weather agent.
And so what that looks like is you call the function with your preferred model.
So in this case, we're
using
Cloud 3.7.
And then we give it a get weather tool or kind of, yeah, it just calls a weather API, maybe with like city and state.
And then you can provide it with a system prompt as well.
So we give it some information about you're a helpful assistant that specializes in weather forecasting and you have access to this get weather tool.
And we're just trying to provide it with helpful context to get it started.
How much do you think that matters that you kind of set the stage, like you're a helpful weather assistant or you're an expert in this field before I ask you questions?
For
a really simple application, like just providing one weather tool that has a great description, I think it maybe doesn't matter quite as much.
But I think as you start to build out those like customer facing chat bots or the email agent that we've been discussing, I think the prompt and guidance becomes really important.
And I think updating that with those memory stores like we've talked about helps your system be the most useful that it could be for you.
Yeah, that's true.
Because the long term persistence probably serves a little bit of that role of like setting the context more deeply.
This portion of Talk Python To Me is brought to you by Auth0.
Do you struggle with authentication?
Sure, you can start with usernames and passwords, but what about single sign-on, social auth, integration with AI agents?
It can quickly become a major time sink, and rarely is authentication your core business.
It's just table stakes that you've got to get right before you can move on to building your actual product.
That's why you should consider Auth0.
Auth0 is an easy-to-implement, adaptable authentication and authorization platform.
Think easy user logins, social sign-on, multi-factor authentication, and robust role-based access control.
With over 30 different SDKs and quick starts, Auth0 scales with your product at every stage.
Auth0 lets you implement secure authentication and authorization for your preferred deployment environment.
You can use all of your favorite tools and frameworks, whether it's Flask, Django, FastAPI, or something else, to manage user logins, roles, and permissions.
Leave authentication to Auth0 so that you can start focusing on the features your users will love.
Auth0's latest innovation, Auth4GenAI, which is now available in developer preview.
Secure your agentic apps and integrate with the GenAI ecosystem using features like user authentication for AI agents, token vault, async authorization, and FGA for RAG.
So if you're a Python developer or data scientist looking for an easy and powerful way to secure your applications, get started now with up to 25,000 monthly active users for free at talkpython.fm/auth0.
That's talkpython.fm/auth0.
The link is in your podcast player's show notes.
Thank you to Auth0 for supporting the show.
Just to give kind of an abbreviated example here.
let's say my email assistant drafts me email response, and then I edit that and I make it more concise and maybe a little bit more friendly or something like that. My agent, I can build in logic so that it updates the long-term memory store with that kind of guidance. And then the next time that the agent is called with an email stimulus, the prompt now has like, keep things concise and a bit more friendly. And I didn't necessarily tell it that I wanted it to be shorter and more friendly. I just made that relevant edit and then it summarized that into the prompt. So all that being said, I think my analysis here would be that context and guidance is really, really important. For this toy example, I think it would be okay without.
I
do think one of the things that people, I would like to hear your thoughts on this as well and the guidance that you all give. But one of the things I think people who are new to LLMs I think they just, they kind of assume that it has too much knowledge or too much context.
And you'll see like a one sentence, please analyze this document for me.
Whereas if you gave it a two page write-up of the request you want, you might get dramatically better results.
And I also think that that's where a lot of people say, oh, LLMs make mistakes and they do all these crazy things.
It's like, well, you gave it so little information.
What's it supposed to go on?
And I guess in general, my comment is, I think people give way too short of prompts and background information to these things.
What do you guys think?
That's definitely true.
I'll send a link here to OpenAI.
I just released a GPT 4.1 prompting guide.
And if you look at any of the guide, you'll see these huge context blocks.
And so obviously, these guys really know how these models work and are going to give us the best guidance.
Yeah, let me just give people listening a sense.
It says, a sample prompt for a software engineering benchmark verified.
So here's a prompt you might get.
And it says, you'll be tasked to fix an issue in an open source repository.
And then it just, it doesn't even word wrap, but it still goes on both horizontally and vertically, hundreds of lines.
Another thing that I think is super interesting is the use of markdown when you talk to these things because it can it can convey a little bit of like formatting like oh this is a link or this is bolded so it means something different than if it's not bolded
it's really interesting kind of trying to play the game of how can i optimize my context so that i'm optimizing the behavior of the llm i think we talk a lot in when we're talking about link graph about like the structure of your application but then really all that boils down to is like getting your getting your context right so that your agent can do the right thing.
Yeah, well, thanks for the diversion.
I just, I do think to be successful with this stuff, you've really got to have your, you're talking to LLM's game really strong because that's the atomic units of this, right?
Definitely.
Okay,
back to the quick start.
Give it a prompt.
Maybe a long, good one.
If you go on our docs, there should be like an agent section.
And I think there's, and yeah, so if you go to lane graph and then up at the, let's see, oh yeah, the agents tab on the top.
That do?
like
the top nav if you go to agents.
Yeah.
So we should have a like getting started with agents section that's maybe a little bit more relevant for users.
So what that would look like, you have your create react agent and then you can invoke it with a set of messages.
So maybe I want to say, what's the weather like in San Francisco?
And then it returns a response and then you can invoke it again and say like, what about New York or other questions like that?
And that's kind of the like out of the box.
How do you build just 10 lines of code?
You've got an agent working for you with context and tools, et cetera.
Super neat.
So when is your new Getting Started tutorial walkthrough thing coming out?
We have it coming out, I believe, at the end of the week.
We have our interrupt conference next week.
So we want to have our docs kind of revamped for that.
Interrupt.
Okay.
Is that like, because that's the call for human in the loop callback effectively, right?
Is that the origin of that name?
Yeah, it is.
I think we're like really emphasizing kind of the value of that.
I just sent you the link as well for that.
It should be viewable publicly.
It's kind of our
old agent's guide.
Happy
to talk more about human in the loop, if that's helpful.
Yeah, yeah, let's talk about that because that sounds pretty interesting, right?
We've got chat, which is obviously human in the loop, although when you press deep research, less in the loop.
Then you've got these Python programs, which maybe just completely run by themselves.
But yeah, what is this human in the loop and how does that work?
The human in the loop, we are trying to basically add human approval or edits for cases that are basically sensitive decisions that are being made.
So very simple example, let's say you have a hotel booking agent and you get a request in that's like, I'd like to book a stay at whatever Hilton in Boston.
You might want a user to just kind of approve that sensitive financial, like significant financial burden before the booking actually goes through. And so we make it really easy with this interrupt function anywhere in a tool or node to say interrupt. I want to get human input here that can review tool calls, validate outputs from an LLM, or like augment existing data or context so that you can make sure your LLM is doing the right thing.
I see. And it's like, well, we found these things, what would you like me to focus on? Or is it okay to make this call to this API? Maybe it's a paid API, like we're accessing this expensive stock data. But I think if I knew this, I could answer your question. You're like, yeah, spend the dollar. Let's see. That kind of thing. Exactly.
Or like with the hotel booking agent, let's say I'm like, I'd like to book the Hilton in Boston. And then it comes up with a proposal for booking not the right hotel.
I can say like actually can you clarify with the user which hotel they'd like to book like maybe provide an address or something and then that like cycles back through and then maybe it gets the proper tool called the second time.
They didn't mind driving so we put them on the opposite end with the maximum traffic. It only looks like at 10 miles but it actually turns out to be two hours to get from here to there when they need to be there. They don't want that right? We
one kind of exciting other open source project we have is called Agent Inbox and so if you have a lot of interrupts going in your application the agent inbox you can hook up to that application and it basically provides you almost looking like this email inbox of all the interrupts for you to
address so
maybe if you had like a social media agent or something that was helping you with your posts and it interrupted right before the final post you can go through and like accept all those tool calls or edit posts right before they get sent out just making it easier to kind of deal with multiple runs, things like that.
Yeah, I guess that makes a lot of sense because otherwise we're going to just have a bunch of programs that are executing but just stuck there waiting for people until they go and just start typing back to it.
And
how human in the loop ties into this persistence layer is sort of twofold.
One, an application can be suspended for any indefinite amount of time.
So the guarantee with our persistence is that you can just restart back where the interrupt was, whether that's a minute later, five minutes later, 10 days later, a year later, whatever that may be.
And so just making sure that like you're guaranteed to get that human input before you resume, but then you have a kind of resumable state.
The second thing is like we've talked about, you want to learn from that human input.
And so you can kind of analyze that in a separate step and then store that in the long-term memory.
Is that a coding thing that you do or is that just the way you set up the workflow?
Yeah, great question.
So we provide kind of support for the fundamentals in LandGraph.
But we think kind of extensibility and customizability is pretty important.
So we have like data structures for those short term and long term stores.
But we also provide interfaces so that you could customize your store.
And we have like in-memory stores or Postgres stores or things like that.
But if you wanted to use some custom location, you could do that as well.
Yeah, super interesting.
So with this ability to suspend these conversations, does that depend upon the LLM keeping that information around?
Like if you make a call to an API, do you get like a session ID sort of thing for that conversation?
Or does it somehow store it, like you say, in Postgres or whatever, and then provide that back to the LLM to keep talking to it?
Yeah, so it's the latter of those.
You're kind of storing the conversation state and message history and any other relevant state to your application.
And then once you get that signal from the user, you can pick all that up.
It's kind of unique to the thread.
We call it like the thread ID or the run ID.
And yeah, start back from there.
And then you would, if you're going to call the LLM again, just speed in that context.
Yeah, because that's kind of what subsequent chats are, right?
It's see everything again, plus the new information.
Now answer that, right?
It's a little weird.
Yeah.
So that's really helpful for things like local LLMs that might run or restart more frequently, unlike some of the cloud ones where they kind of keep that data.
But I don't know how long they keep it for.
Yeah, and a new kind of exciting feature in the persistence space generally is we're going to very soon introduce caching on the kind of node-by-node level.
So you can imagine if you have a node, which is really just a function running some expensive operation, for simplicity, we can just say it's like a pre-processing step, not even involved with an LLM.
you pass certain inputs to that node and you could enable some sort of cache policy there so that if you're starting up with the same inputs, you get to skip that step. And so really just trying to optimize for how can lots of different types of users use this same low-level system for a variety of agentic workflows.
You have these nodes and graphs and then you put it together in this workflow and you've got this cool persistence of memory. Can some of those operations be just pure Python workflow type things rather than always LLM, right? Like can it be call this LLM, use this tool, call this LLM, now just make an entry in our database or just send an email or whatever?
Yeah, definitely. I think that's the kind of value of that low level framework. Other what we call agent frameworks are really just focusing on the operations involved with LLMs.
Right, or orchestrating multiple LLM calls more or less, yeah?
The OpenAI Agents SDK, for example, helps you query OpenAI LLMs and orchestrate many agents together and maybe have guardrails.
But there's no kind of built-in support for just those standard Python operations, functions, processing, et cetera.
And so Node really just can contain any function.
So calling some API or doing any other thing you might possibly want it to do in just pure Python.
So we talked about using different LLMs like Anthropic or OpenAI or a local one that you might download.
Can I mix and match LLMs within a single workflow?
Can I say this part I want to run in a local model and that part I want to run on O3 Pro or whatever?
I don't know if that's even out on the API.
It's certainly not out in chat, but where's O3 Pro?
Come on.
And they have O4 and 4.0 as well.
Oh my gosh, it's even.
Yeah, absolutely.
You can mix and match as your heart desires.
So LingChain, that first open source tool that we have, makes it really easy to pass messages from one OM provider to another in that kind of model agnostic format.
And so if you're using LingChain's model abstractions from one node to the next, it's quite easy to use.
Yeah, that's really cool.
And you could even do things, I imagine, such as I want to call a certain model that's really good at coding, maybe Cloud3.7 or something like that.
But I want to call, now I need to call another one that's better at tool usage and is more creative now that I have the answer, right?
A little bit like my weirdo perplexity thing went and wrote Python code to answer my history question, right?
Totally.
And it's really interesting to think about the pattern of using a model as a router.
So you can imagine like a user asks a question and you give some model the context that's like, I have three model providers that I can use.
Model provider A is really great at research.
Model provider B is really good at solving coding problems, etc.
And so first, the user question gets routed through that router node, and then that can send and basically delegate to one of the other nodes based on that model's reasoning decision.
So that is kind of a cool multi-agent architecture that you could design with Langrass pretty easily.
One other thing that I wanted to note when you were asking about running Python code in nodes, kind of LM or non-agentic patterns, is that we have this main graph API, which is what most folks use.
But we've also introduced an imperative API that allows you to decorate functions with kind of two key things.
One is an entry point decorator that's like kind of indicative of the start node in your graph.
And then another one is a task decorator.
And so if you already have kind of a workflow-like system or functions already written, you can easily turn that into a LNGraph workflow just with a couple of decorators, which is very nice.
I like it.
I like it a lot.
Let's talk about just what if we look inside LNGraph, surely it's written in Rust, right?
That has to be written in Rust.
Still in Python.
The library itself is written in Python.
So it's easy to understand.
Do you all have external contributors and take pull across and stuff like that?
Yeah, we do.
I think we see a bit more engagement on the LangChain side because LangChain itself is more involved with new features released by model providers or things like that.
We see more activity there.
And LangChain is where all of our integrations lie.
So like the LangChain OpenAI package or LangChain Anthropic.
So that's where most of the community engagement is.
But, you know, like in the other good open source project, we've got open issues.
and discussions and a Slack help channel for LandGraph users
as well.
Right, right, a community.
Okay, cool.
Well, I was going to say you had 174 contributors in LandGraph, but I thought that was pretty good in terms of number of people, but you've got 3,600 in LangChain.
So yeah, that's pretty wild.
Used by 237,000 projects.
Yeah, it is really impressive kind of the scope of usage there.
I think it's the biggest like developer community in the AI space.
So it's really nice to have so many eager contributors and get to use that as kind of the foundation for the more model driven operations in LandGraph.
I always like to use the Python web frameworks as measuring sticks or whatever for these things.
So for example, if you look at search for Flask on GitHub, right?
It's, where are you Flask?
Come here.
It's got 70,000 stars, which is pretty awesome.
You guys have 107, like just to give people a sense of like how popular this is.
And I also bring this up because there are people out there go, oh, I can't believe you're doing an AI topic.
I'm so tired of AI.
I can't take any more AI, which I get on one hand.
Like on the other, this is how significant it is.
It's like literally revolutionizing tech and non-tech before our eyes.
It's like history in the making.
It's like the invention of the web a little bit, I think.
What are your thoughts?
I
understand kind of the things are so novel and I understand wanting to push back against such big change.
But I think one of the reasons that I like LaneGraph as a tool so much is that it really lets you balance the AI when you need it and not when you don't.
We talk a lot about kind of finding yourself on this workflow versus agents curve.
The more like pure agent is much less predictable and pure workflow is predictable, but maybe not quite as useful.
And I think it lets you pick like wherever you want to be on that curve.
And so hopefully that's also relevant for listeners who are like, man, I'm not.
super interested in AI applications, but like maybe I have this one
huge workflow
where one step could really use the help of an LLM. And so I think it's a nice like on-ramp into AI usage for developers and just the customizability is very valuable. But yeah, I mean, I understand like the general hesitation. I think it's kind of revolutionizing our industry and it's unpredictable.
I agree. One other thing I'd like to throw out there is I think rightly so a lot of people are concerned about the environmental impacts of heavy AI usage. On the other hand, I think there's a lot of interesting things you can do with local models and the local models really, they really don't make any difference running them, not necessarily training them. Like for example, I was running a 7 billion parameter model for this Git project that I'm doing and this Git tool. And I think I have a little iStats menu thing for my my computer's energy usage right now it's using between 30 says 13 watts but it bumps around like 13 14 watts when the llm was running it jumped all the way up to 20 which is like one led light bulb for four seconds right so if people who are concerned about those things like you can run these models locally and still get a huge amount of benefit even if they you don't get like the full deep research, massive, massive type of stuff you get from the cloud.
It's still really, really impactful, I think.
Yeah, definitely.
I think that like really leans into the idea of like build simple when you can.
Like a lot of these systems can be relatively simple and context windows are widening.
And I think if you can construct a solution that just meets your needs, but doesn't do anything like crazy outside of it, it's both going to be better environmentally and like more reliable of a system.
Yeah, I was talking to Ines Montani about this whole topic, but mostly about the open source, or at least open weights models and things like that.
And one of the things she really focused on was about task-specific models or models that are really focused on solving a certain problem.
And it sounds to me like combining that idea with Lengraph and sort of bringing in multiple models to the model router, I think you called it, could be really cool.
So instead of running huge models, I run five small ones.
But in coordination, they actually become very powerful.
One of the challenges of using LLMs is reliability if tasks are ambiguous.
It's not going to do a good job if you don't tell it what you want it to do.
And so, yeah, if you have these really specialized tools and you only route things to, or I say tools, what I really mean is models, to clarify when tools is also overloaded.
But yeah, if you have very specialized models and you can kind of properly route queries and questions and tasks and demands to them, I think that's the best way to have a reliable system.
Yeah, it's probably faster too.
And lower environmental footprint.
The one bonus, the one good thing I think here is that the negative environmental impact is directly correlated with cost.
So people's incentives are aligned for trending towards less environmental impact.
even if they don't care about it, right?
They just want to save money.
That's still going to get kind of the same output.
I'm
actually really excited.
I won't be able to go to PyCon this year, but I'm excited to watch some of the talks after the fact.
And I helped kind of review the talk submissions this year.
And it seems like there's some really great ones focusing on environmental impacts of your Python code and how to reduce those and, you know, how to think about that on an individual versus like large scale.
And I think it's really great that that's kind of driving more public conversation now.
Yeah, yeah.
Don't tell your LLM things at the end.
Go on.
Yeah.
So let's wrap this up with maybe a bit of a showcase.
Have you got some example apps or things you've seen build or things people are doing that you're like, there's really cool stuff you can do with a link graph and link chain or LLMs in general.
What's some cool stuff you've seen out there people building?
I mentioned the email assistant as a very simple one that I think is satisfying just in that the utility is really high and that's saving folks a lot of time.
I think the social media agent is a cool idea if you're like, I don't want to spend a bunch of time working on social media engagement, but I do want to kind of keep up with the most important updates in my space and then also kind of contribute.
I think hopefully I'll have some better answers in the short term, still kind of onboarding at BlaineChain and trying to better understand customer use cases.
Very cool.
One of the things that I think, just thinking out loud of the examples of things that'd be really amazing is you look at research labs and academia in general, especially the research heavy ones, how much those folks have to read long detailed papers and assess whether they even make any sense.
you could set up some kind of hygienic workflow that just watches for new things being published in your field looks to summarize them, determines the impact and relevance and then brings you like a digest a weekly digest. Well here's what's happened in academia for you and do you have other questions that could be like your interrupt or your inbox sort of thing like well which of these would you like us to dive into right and like maybe really go in and analyze these further and I don't know. It seems like when you're really trying to summarize text or process it or correlate, I don't know. It's just, there's so many possibilities there.
Yeah, definitely. And it's really cool to think about how extensible that is. You could kind of build this like general system for a research agent that's going to provide you with a summary. And then different users can be like, okay, here are the three topics that I'm most interested in, like provide me with the summary for those.
Nice to basically think about like individual users specifying things that they want to narrow in on or like specialties that they want to emphasize.
Super fun.
All right.
How about a last thing here, a roadmap?
Where are things going?
What should people maybe have been asking for that might be showing up they should be on the lookout for?
One thing I mentioned a little bit earlier is that kind of node level cache.
I think that'll just be a nice performance boost for folks, especially folks looking to really scale with their lane graph applications.
The thing that we're focusing on the most now is kind of this happy path for those pre-built. So the like create agent functions or some other frameworks have classes. I think, for example, with human in the loop, I'm working on a feature right now that makes it really easy to use kind of default patterns for human in the loop with those pre-built agents.
So maybe you have like tools A, B, and C, and for all of them, you want default logic such that when the tools run, a human has to accept the tool call before or when the tools are recommended by an LLM before the tool actually runs.
So basically, just emphasizing really making it easier to get started with those like create agent pre-builts, because we think there's going to be increasing demand on the like, how do I in 10 lines of code get started with a really functional agent?
Oh, this is very Pythonic, right? Like it has a lot of, you can put, you can do all the things with it if you want, but then you're down in the details and you're doing advanced programming type stuff, right? But what's the import library? Do the few things have magic happen, right?
I think those like quick start guides are great if they're truly quick. And so I think just kind of shooting for that on our end.
Yeah, that's cool. I would also, this is pure speculation, but maybe informed speculation.
I don't know.
If I were to guess, people coming to do web stuff in Python are pretty CS-like folks, maybe not pure, like they don't necessarily have CS degrees, but they've got that way of thinking.
Like they know what a unit test is, even if they don't do them.
They know about SQL, even if they use an ORM or whatever.
Then we've got the data science folks where before the AI revolution, that was like, well, this is where people who are not really programmers sort of get their first step into Python, and then they kind of get hooked.
But they start by doing these real simple things like the projects you're talking about or the features you're talking about.
And then they realize, oh, well, I can do a little more.
And then they sort of work their way backwards into becoming Python programmers.
I would say that people coming to AI are maybe even less formal than the data science folks, right?
It's a little even further along that spectrum there.
And so really making those people feel welcome until they become a little more programmer-focused is probably really important.
I recall you chatted on your kind of developer trends for 2025 forecast podcast about the value of being able to get started in Python if you've never written a single line of code and it being pretty easy.
And then also folks like the or teams like the folks at Astral developing tools for really advanced users and people who really want to make Python a sophisticated system.
And I think we basically with LangGraph want to provide that same benefit of you can get started with a couple lines of code and then also like you want to deploy tons of parallel instances, running parallel processes and streaming responses with all of these features.
Like you can do that too.
Yeah, that's awesome.
Yeah, you start with one, grow to the other if that's the path you're on, right?
I guess
one other thing that I'll mention roadmap wise is both LangChain and LangGraph integrate with LangSmith, which is our commercial product.
And we didn't talk a ton about observability and more of the prompt engineering or evaluation side of things that is often tied into agentic workflows.
But yeah, so if you're building applications with LangGraph, using LangSmith for observability can be super valuable, especially when you're at scale.
Yeah, monitoring for AI app performance, super cool.
I guess maybe one more is LangChain Studio or LangStudio, the studio for debugging.
So if you're developing your lane graph application, you can just run lane graph dev in your terminal.
And then that pops up with kind of a local studio.
You can like step through your graph.
Yeah, that's a great screenshot there.
Or yes, but that makes it really easy to debug things locally and just kind of understand the flow of your system in real time.
And then we also offer a lane graph platform where you can do this kind of thing as well, but deployed locally.
Awesome.
Well, final call to action.
People are interested in getting started with all these ideas.
What do you tell them?
I would say look forward to our new docs drop this week.
I think it's going to really emphasize helping folks get started with those create agent pre-builds.
Can they just go to linkchain.com and click on docs and go from there?
Okay.
Yeah.
So we have our linkchain docs there, our link graph docs there, and it should be quite easy to get started.
And obviously I mentioned our kind of community forums earlier, but we have a community help slack.
open issues and discussions, et cetera. So feel free to ask questions there.
And then this interrupt conference you talked about, is this going to be live streamed or recorded and videos available?
Yes,
we should have talk recordings and demo recordings available as well. One other resource that I should mention is that we are kind of trying to grow in the education space. And so we also offer a Langrath course, and we'll be releasing a new course next week, kind of focusing on those ambient agents.
And that's a really great way to get started if you're maybe not quite ready to write code, but just kind of want to learn more about the LandGraph features.
Or if you are ready to write code, it has some awesome resources and notebooks as well.
Well, very interesting.
And it's an exciting time to be working in code.
It's changing fast.
It's great to talk about these cool new systems that we get to use and explore.
Yeah, well, looking forward to seeing what you all keep creating.
Thanks for being back on the show, Sydney.
Yeah, thank you so much for having me.
Yeah, bye.
This has been another episode of Talk Python To Me.
Thank you to our sponsors.
Be sure to check out what they're offering.
It really helps support the show.
This episode is sponsored by Posit Connect from the makers of Shiny.
Publish, share, and deploy all of your data projects that you're creating using Python.
Streamlit, Dash, Shiny, Bokeh, FastAPI, Flask, Quarto, Reports, Dashboards, and APIs.
Posit Connect supports all of them.
Try Posit Connect for free by going to talkpython.fm/posit, P-O-S-I-T.
And it's brought to you by Auth0.
Auth0 is an easy-to-implement, adaptable authentication and authorization platform.
Think easy user logins, social sign-on, multi-factor authentication, and robust role-based access control.
With over 30 SDKs and quick starts, Auth0 scales with your product at every stage.
Get 25,000 monthly active users for free at talkpython.fm/auth zero.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show, open your favorite podcast app, and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.