保留正文与补采附件。源页面当前未重新核验；具体限制见交付清单。

Revisit consent button We value your privacy We use cookies to enhance your browsing experience, serve personalised ads or content, and analyse our traffic. By clicking "Accept All", you consent to our use of cookies. Customise Reject All Accept All Customise Consent Preferences We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below. The cookies that are categorised as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... Show more NecessaryAlways Active Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.

Functional Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.

Analytics Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.

Performance Performance cookies are used to understand and analyse the key performance indexes of the website which helps in delivering a better user experience for the visitors.

Advertisement Advertisement cookies are used to provide visitors with customised advertisements based on the pages you visited previously and to analyse the effectiveness of the ad campaigns.

Uncategorised Other uncategorised cookies are those that are being analysed and have not been classified into a category as yet. No cookies to display. Reject All Save My Preferences Accept All Toggle SearchToggle Mobile Navigation Publish AI, ML & data-science insights to a global community of data professionals. Sign inSubmit an Article LatestEditor's PicksNewsletterShipAI

Write For TDS LinkedInXToggle Search Agentic AI

Building a Proper Backend for My LangGraph AI Agent

Turning a demo agent into something that can keep real booking data Soner Yıldırım August 22, 20266 min read Photo by Towfiqu barbhuiya on Unsplash Photo by Towfiqu barbhuiya on Unsplash In the first two articles of this series, I built a stateful LangGraph agent that handles a 15-minute booking process and wrapped it up with a Streamlit UI to improve user experience. The agent handles the entire booking process like a real customer service representative. It’s a LangGraph-based agent that orchestrates the following operations:

The next phase is to build a proper backend and we start by implementing a Postgres database instead of keeping everything in memory. We keep Streamlit as the user interface and replace the in-memory adapters with PostgreSQL. This will also allow us to have multiple fronts (e.g. WhatsApp, Streamlit) that share the same backend. So we are turning this into a proper product that will handle a real business. The full source code of this project is available on GitHub at customer-service-agent. Feel free to clone the repo and test it yourself. Learn this step by step with the interactive AI Agents roadmap.

What the database looks like now

It's hard to even call it a database as it's just two Python objects that lived inside the process: The first one is a LangGraph checkpointer, which is a state persistence layer that saves a snapshot of an agent’s graph state at every step of execution. When the graph is compiled, conversation state is stored in memory. python

graph.compile(checkpointer=checkpointer or MemorySaver())

The checkpointer allows the agent resume across turns. If we don't have it, every customer message would be a new conversation. The second object is a Python list behind a lock. Confirmed appointments are stored in an in-memory repository that looks like this: python

class InMemoryBookingRepository:
    def __init__(self) -> None:
        self._lock = threading.RLock()
        self.technicians = {...}  # hardcoded cleaners
        self._bookings: list[Booking] = []

    def list_bookings(self) -> list[Booking]:
        with self._lock:
            return list(self._bookings)

    def create_booking(self, option, details, price) -> Booking:
        # check overlap in Python, then append to self._bookings
        ...

The scheduling engine called list_bookings() to avoid double-booking. Confirmation called create_booking(), which re-checked overlap and appended to the list. This is a very simple structure designed for initial testing and demo purposes. It allows us to test LangGraph routing and logic.

Why we need a proper database

The current "database" relies on in-memory persistence so it fails as soon as we leave a single demo process. When the process restarts, conversation checkpoints and bookings vanish. Since it's in memory, there is no shared availability. Session A cannot see bookings created by Session B, which means every process has its own calendar. Even worse for a booking product is that the agent can offer a slot based on a stale in-memory view, then “confirm” a booking that another session already took. When we use the Streamlit UI, it looked like a product but the storage still behaved like a notebook kernel. Long story short, we need a proper database for our agent to be considered as a product. We will use Postgres, which is a free and open-source relational database system. We need a relational database with bookings and technician information stored in separate (and related) tables. Before Postgres implementation, the agent structure looks like this: And after we complete Postgres implementation, it will look like this: After the Postgres backend, AgentState will still be the working memory of the graph but it will be persisted through a checkpointer and a booking engine. We will learn how these are implemented and they function in the remaining part of the article.

Postgres implementation

We first create a protocol so that the graph and engines can depend on a stable interface, not on Postgres (or memory) specifically. python

from typing import Protocol

class BookingRepository(Protocol):
    """Persistence interface used by scheduling and confirmation."""

    @property
    def technicians(self) -> dict[str, Technician]:
        """Return technicians keyed by id."""

    def list_bookings(self) -> list[Booking]:
        """Return all confirmed bookings."""

    def create_booking(
        self, option: TimeOption, details: BookingDetails, price: float
    ) -> Booking:
        """Persist a booking after re-checking overlap; raise ValueError if taken."""

With this protocol, we just plug PostgresBookingRepository or InMemoryBookingRepository at startup (depending on using Postgres or in-memory). Then, the nodes can call list_bookings and create_booking functions. When we use InMemoryBookingRepository, no database tables are created. Confirmed bookings are kept in a Python list inside the running process, and the same repository methods (list_bookings, create_booking) still work. They just never touch Postgres. The in-memory mode ideal for unit tests and quick local demos. It's important to also mention that, with the in-memory mode, everything disappears when the app restarts. When we use PostgresBookingRepository , there is an actual database. Inside the postgres.py script, you can see the database schema that consists of two tables, which are technicians and bookings . You can also see the definition of the PostgresBookingRepository class. I won't copy it here because it's close to 100 lines of code. We also define the functions list_bookings and create_booking inside this class. At app startup, create_persistence() chooses Postgres vs in-memory. When DATABASE_URL is set, both the booking repository and LangGraph checkpointer use Postgres. Otherwise both stay in memory. So the repository is either a PostgresBookingRepository or InMemoryBookingRepository (both satisfy the BookingRepository protocol), and that instance is passed into the build_graph function: python

def build_graph(
    llm: BaseChatModel,
    *,
    repository: BookingRepository | None = None,
    checkpointer: Any | None = None,
) -> Any:
    """Build a compiled, multi-turn booking graph."""
    repository = repository or InMemoryBookingRepository()
    graph = StateGraph(AgentState)

    # truncated

The repository is then used by the graph nodes to interact with the database. For example, we define the confirm_booking_node function as follows: python

    def confirm_booking_node(state: AgentState) -> dict[str, Any]:
        option = state.get("selected_slot")
        if option is None:
            raise ValueError("A slot must be selected before confirmation.")
        booking = repository.create_booking(
            option, state["booking_details"], float(state["calculated_price"])
        )
        return {
            "booking_id": booking.id,
            "status": "confirmed",
            "messages": [
                AIMessage(
                    content=(
                        f"Confirmed! Booking {booking.id} is scheduled for "
                        f"{option.start_at}. Your total is ${booking.price:.2f}."
                    )
                )
            ],
        }

We can see that it's using the repository to create a booking in the database.

Database interactions

The current agentic workflow is as follows: During a booking session, conversation lives in AgentState, which can be considered as the working memory of the graph. Each node returns a partial update, and LangGraph merges it into that state. The checkpointer persists it across turns with Postgres. Only two nodes talk to the booking repository (either PostgresBookingRepository or InMemoryBookingRepository):

The other nodes only read or update the AgentState. They do not query the bookings table. To propose appointments, we add generate_schedule_options_node to the graph: python

def generate_schedule_options_node(state: AgentState) -> dict[str, Any]:
    options = generate_schedule_options(state["booking_details"], repository)
    lines = ["Great—please choose one of these optimized appointments:"]
    for index, option in enumerate(options, 1):
        lines.append(f"{index}. {option.start_at} ({option.technician_id})")
    return {
        "time_options": options,
        "status": "awaiting_slot_selection",
        "messages": [AIMessage(content="\n".join(lines))],
    }

This node calls the generate_schedule_options() function from engines.py , which:

  1. Calls repository.list_bookings() (a SELECT from bookings when using Postgres)
  2. Uses repository.technicians
  3. Applies deterministic rules (next 7 days, skip Sundays, fixed start times, duration, travel scoring)
  4. Returns the best 3 available time options

LangGraph handles merging this information into AgentState, updating time_options, status, and messages : python

class AgentState(TypedDict):
    messages: Annotated[list[AnyMessage], add_messages]
    booking_details: BookingDetails
    calculated_price: NotRequired[float | None]
    time_options: NotRequired[list[TimeOption]]
    selected_slot: NotRequired[TimeOption | None]
    status: BookingStatus
    booking_id: NotRequired[str | None]

After the customer confirms a slot, select_slot_node only sets selected_slot in AgentState. The write happens in confirm_booking_node: python

def confirm_booking_node(state: AgentState) -> dict[str, Any]:
    option = state.get("selected_slot")
    if option is None:
        raise ValueError("A slot must be selected before confirmation.")
    booking = repository.create_booking(
        option, state["booking_details"], float(state["calculated_price"])
    )
    return {
        "booking_id": booking.id,
        "status": "confirmed",
        "messages": [
            AIMessage(
                content=(
                    f"Confirmed! Booking {booking.id} is scheduled for "
                    f"{option.start_at}. Your total is ${booking.price:.2f}."
                )
            )
        ],
    }

On success, LangGraph merges booking_id, status="confirmed", and the confirmation message into AgentState, and the checkpointer saves that snapshot for the conversation thread_id. We now have a proper Postgres backend for our customer service agent. In the next article, I’ll walk through how to run and verify this setup with Docker, and how to point the same app at a hosted Postgres instance. Thank you for reading.

Register Now to Continue Reading

Unlock Towards Data Science with a Free Account

All articles on Towards Data Science are available to registered users. Create a free account today to access this article and thousands more. Register for freeSign in to your account

Written By

Soner Yıldırım

See all from Soner Yıldırım Agentic AiAI AgentsLanggraphProgrammingStreamlit Share This Article

Towards Data Science is a community publication. Submit your insights to reach our global audience and earn through the TDS Author Payment Program. Write for TDS

Related Articles

Beginners Baseline Model for Machine Learning Project

Artificial Intelligence Learn to standardize your machine learning development Cornellius Wijaya May 5, 20227 min read

How to Build CLI Agents with Python & Ollama

Agentic AI Create a local CLI Agent from scratch completely for free Mauro Di Pietro August 3, 20265 min read

Advanced Python: Metaclasses

Machine Learning A brief introduction to Python class object and how it is created Ilija Lazarevic October 6, 20239 min read

Showcasing Your Work on HuggingFace Spaces

Productivity If you want to highlight your work and applications, this is a strong option. Ivo Bernardo September 5, 20258 min read

Production-Grade Observability for AI Agents: A Minimal-Code, Configuration-First Approach

Agentic AI LLM-as-a-Judge, regression testing, and end-to-end traceability of multi-agent LLM systems Partha Sarkar December 17, 20258 min read

Graph Theory Basics

Programming What you need to know as graph theory adoption continues to take off Miguel Saldana March 22, 20218 min read

Build and Run Your Own AI Agent in the Cloud

Agentic AI Build and deploy an agent on AWS with Strands and AgentCore Thomas Reid July 1, 202623 min read

The Big Con of Agentic AI

Agentic AI What our over-dependence on external consulting teaches us about delegating our minds to machines Chinmay Kakatkar July 10, 202620 min read

How to Use Pandas to Get Your Data in the Format You Need

Programming Learn the difference between long-form and wide-form data, and how to transition between them in Pandas. Murtaza Ali October 13, 20225 min read

Your home for data science and AI. The world's leading publication for data science, data analytics, data engineering, machine learning, and artificial intelligence professionals. Subscribe to Our NewsletterWrite For TDS•About•Advertise•Privacy Policy•Terms of Use © Insight Media Group, LLC 2026•The New Stack•roadmap.sh•Creator Network