Obsidian 1.12 introduced an official CLI that talks to the running app. With wrapper-for-obsidian-cli we get a thin Python bridge around that CLI: no API key, no community plugin and no async. Every CLI command becomes one method on a client object, and every method returns the command's raw output as a string. Let us see how far this gets us when we script a vault.
When we design a group of related classes, we often want to guarantee that every member provides the same set of methods. We could write that expectation into the documentation and hope for the best, or we could let Python enforce it for us with the abc module and its abstract base classes.
Last week we made our first steps with Deep Agents of LangChain . In this post we build on top of this knowledge and see how we can combine Frontmatter with our agent and create a tool that uses an LLM to find good tags for a blog post.
With Deep Agents we get a relatively new component from LangChain/LangGraph that allows us to build high-level agents. Let us see how they fit into the big picture and how we can use them in our own applications.
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…
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…
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…
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.
Last week we created a basic LangGraph example for the human-in-the-loop pattern . We ended up with a solution that run our tools but only after we approved the run. While this works, it gets cumbersome in no time. Especially when we have many tools and most of them are safe to use. In this post we use a policy-based approach that allows us to create a list of safe tools for that we do not need a…
Last week we learned how to build our own tools to use in LangGraph. Sometimes those tools could be dangerous, and we want to approve their usage before they run. For that we can use the Human-in-the-Loop (HITL) pattern.
LangGraph gets interesting as soon as we start to integrate it with our tasks. For that we need custom tools so that the LLM can interact with our data. Let us see how we can create our own tools and use them in LangGraph.
The more complex our control flow in our LangGraph application, the harder it is to understand what is going on. Luckily for us, we have multiple ways to visualise our graphs. Let us find out how we can do that.
Last week, we created a simple LangGraph application as our starting point. In this post, we will look at different ways to manage control flow and how nodes can interact with each other. While this sounds even more boring than our last post, here is where things start to get interesting.
Agents in LangChain allow us to use the LLM as a reasoning engine and take actions based on their abilities. We used them successfully with our CSV files or when we queried a database . However, while we get a lot of flexibility, we often wish for a middle ground that gives us not only flexibility, but a bit more control on what is going on. We can use LangGraph for this purpose. This low-level…