Multi‑Agent FastAPI Pattern
An engineer shared a practical architecture for running multi‑agent AI systems at scale using FastAPI and Postgres to handle 14 agents, 11 teams, hundreds of tools, RBAC, JWT auth and thousands of concurrent requests. The post frames a simple stack that supports agent teams, multitenancy and tool orchestration for prototypes and early production systems. (X post)
A multi-agent app can look like one web server and one database, not a sprawl of microservices. In an April 16 post, engineer Ashpreet Bedi said he built a FastAPI-plus-Postgres stack that runs 14 agents, 11 agent teams and five workflows in one process. (ashpreetbedi.com) The setup is aimed at software that serves many users at once, not a single chatbot in a notebook. Bedi said it includes multi-user sessions, memory, knowledge storage, role-based access control, JSON Web Token authentication, approvals, evaluations and schedules, with “hundreds of tools” behind the agents. (ashpreetbedi.com) The basic engineering idea is older than the agent boom: keep the application layer thin and let the database enforce boundaries. PostgreSQL supports row-level security policies that can restrict which rows a user can read or modify, a common way to separate tenants inside one database. (postgresql.org) The web layer is built for waiting on slow things without blocking everything else. FastAPI’s async model is designed for network and database work, where one request can pause while other requests keep moving, which is why it is often used for streaming and high-concurrency APIs. (fastapi.tiangolo.com) That matters because agent software spends much of its time calling outside systems. A single answer can trigger database reads, remote application programming interfaces, file access and follow-up model calls, so the bottleneck is usually orchestration and I/O, not raw Python compute. (fastapi.tiangolo.com) The “multi-agent” part is also less exotic than it sounds. In OpenAI’s Agents SDK, one specialist agent can hand work to another, and those handoffs are exposed to the model as tools, which makes a team of agents look like a structured tool graph rather than a swarm. (developers.openai.com, openai.github.io) Tool sprawl is where these systems usually get messy. Pydantic AI’s Model Context Protocol client treats external tool servers as reusable toolsets over standard transports including streamable Hypertext Transfer Protocol, server-sent events and standard input/output, which gives developers a way to plug many tools into one agent runtime. (pydantic.dev) Security is a separate layer from orchestration, and Bedi’s post leans on familiar web patterns there too. FastAPI’s own security guide shows JSON Web Token-based bearer auth and OAuth2 flows as first-class building blocks, which is the same machinery many non-AI software-as-a-service backends already use. (fastapi.tiangolo.com) Bedi framed the design as a practical floor for prototypes and early production systems, not the final word on scale. His post ends by promising a follow-up on what breaks under heavier load, but the first installment makes a narrower claim: one FastAPI process and one Postgres database can carry a lot more agent software than the current hype cycle suggests. (ashpreetbedi.com)
