If we dive into Python scripting or need to share a small utility with a colleague, we quickly run into a familiar problem: Incompatible or missing package versions. We can solve that problem with virtual environments, but that brings us right to the next one. Managing multiple environments for small, standalone scripts is tedious and breaks the workflow.
Frontmatter is the metadata format for Markdown and YAML that we can use in MkDocs and many other tools. While we could parse the metadata on our own, tools like Python Frontmatter are a much simpler way to do it. Let us see how this works.
A multi-agent system is an architecture style where we split a larger task across several specialised agents instead of relying on one LLM call to do everything. Each agent can have its own role, such as planning, researching, validating, or writing the final answer. That way we can build workflows that are easier to control and to extend.
In LangGraph we can build this kind of applications with nodes that represent the agents and let the workflow guide the communication between them. This approach let us reuse most of what we already know about LangGraph while the multi-agents are in control of their subject.
Last week we saw how FastMCP can help us to create a MCP server. In this post we see how we can connect our LangGraph application to an MCP server.
An MCP (Model Context Protocol) server is an open-standard integration that acts as a bridge between Large Language Models and external data sources or tools. That way we can get more specific answers about our data or let the LLM act on our behalf.
We can build our own MCP server with various tools. One of the simplest one for Python is FastMCP, that feels a lot like FastAPI. Let us see what we need to do to run our own tools through a MCP server.
A common way to test the "quality" of an AI solution is to ask for how many r’s are in the word raspberry. LLMs are notoriously bad in such questions, but that does not mean we have to accept defeat with our AI application. Let us figure out how we can handle these types of tests.
The more complex our applications get, the harder it is to follow along our graph. Luckily for us, there is the concept of subgraphs that let us split our graph into parts that we can reuse.
For this post we create a minimalistic text writing pipeline that puts the quality checks into a subgraph. Let us see how we can do that.
When we switch from our hand-written long-term memory solution in last week's post to a pre-build SqliteSaver, we not only need less code, but we gain new options. One of the benefits of saving the whole state to a database is that we can inspect the current workflow and rerun them after we fixed a problem. Let us see how that works.
Last week we added short-term memory to our LangGraph application. That works great as long as we stay in the same session. But when we want to keep the memory around between sessions, we need a different approach.
In this post we create our hand-written approach for a long-term memory solution. Do this only to understand what is going on and not to use it in production. For that purpose, we can use pre-build solutions that we explore next week.
A while back we added a chat history to our LLM client so that we did not need to constantly repeat ourselves. This problem is now back in our LangGraph workflows. Luckily for us, LangGraph has a simple way to add memory to our workflows. Let us see how we can do that.