Building a Scalable AI Backend System

How it started

In March 2026, I enrolled in an advanced AI orchestration training, where they assigned us to build a multi-agent orchestration using LangGraph. Now, I was familiar with the basics of backend development and generative AI, and knew the basics of how these systems worked. But I was yet to build a more complex system than the ones I had built before. So, I built a basic version of a multi-agent system that has a supervisor agent and two sub-agents (a knowledge base agent and a booking agent). Both of these sub-agents have tools for them to access their platforms.

Taking it to production

I was done with a basic implementation in just a few weeks. After some time, the training ended, and I was left with my system, which obviously wasn’t production ready. I decided to take this one thing to production. So, I started building heavy around May-June. I was using Supabase for managing the bookings in a database table, so I decided to develop the rest of the data tables in Supabase too. I designed the database schema in a tool called Excalidraw. I designed the whole application architecture too using the same tool.

I implemented authentication in Supabase, created database tables, set up triggers and created trigger functions, and this taught me how to use PostgreSQL.

Multi-tenancy

I implemented a multi-tenant architecture for designing this agentic application, and it taught me how to give the agent access to the data reliably so it can access only that data which it is authorized to access.

The naive answer is to put the user’s ID in the prompt. I rejected that early: an LLM can drop it, hallucinate it, or echo it back to the customer, and infrastructure concerns have no business being in a prompt. I also rejected putting it in the graph state, which felt like adding a whole dimension to the state for one small thing. What I landed on was LangChain’s RunnableConfig. It’s already threaded from the graph nodes through the agent down into the tools, so user_id and a per-request Supabase client ride along in configurable and never touch the model.

Confirming a booking

The agent shouldn’t be able to confirm a reservation it hasn’t actually secured. My first instinct was a LangGraph interrupt to pause and wait for confirmation, and I rejected it: one business has one thread, so several customers booking at the same time would collide, and checkpoint memory isn’t meant to hold a pending decision for that long. What I did instead is insert the slot as pending, email the occupier a link carrying a verification ID, and let a database function flip the row to confirmed when they click it.

The frontend

I also built a frontend for the application using Claude Code, and chose to call the app “Receptix”, which is an AI front desk application for businesses which helps them answer customers’ FAQs directly from their sources and helps book appointments automatically.

What it taught me

This taught me how backend engineering is done around AI systems, and I can honestly say that only 30-40% of the work was designing AI stuff. The rest was typical backend engineering involving APIs and database stuff. I’m almost done with version 1, and here’s the repo: Ai-Workspace-Operations-Copilot.

The video

I also made a YouTube video some days back, so make sure you watch that too.