Building Production-Ready Multi-Agent Systems with FastAPI, Pydantic-AI, and MCP

Building Production-Ready Multi-Agent Systems

This workshop repo addresses a critical gap in AI agent development: most frameworks excel in isolated demos but struggle when you need to coordinate multiple agents into a cohesive application. The PyCon Greece 2025 presentation tackles this head-on by demonstrating practical patterns for production-grade multi-agent orchestration.

The Problem It Solves

When building solo AI businesses, you often need agents that specialize in different tasks, research, analysis, execution, decision-making. Gluing these together without chaos is hard. This repo shows how to:

• Run agents independently in containerized environments
• Define safe communication between agents using MCP (Model Context Protocol) and A2A (Agent-to-Agent) protocols
• Share tools and context across agents via MCP servers (Brave search, GitHub, filesystem access, etc.)
• Route work intelligently without monolithic frameworks

Architecture & Key Patterns

The repo demonstrates a modular stack:

FastAPI as the coordination backbone: Lightweight HTTP APIs handle agent requests and responses. This is crucial for solo builders, you avoid vendor lock-in and can deploy agents independently.

Pydantic-AI for structured agent logic: Type-safe, validated prompts and responses. Reduces hallucinations and makes debugging easier when agents go wrong.

MCP servers as tool ecosystems: Rather than agents calling APIs directly, they request tools from centralized MCP servers. This decoupling means you can swap implementations (e.g., replace Brave search with a custom search backend) without rewriting agent code.

Agent-to-Agent communication: The A2A protocol shown here allows agents to ask other agents for work. Imagine an "analyst" agent asking a "researcher" agent for domain information, which asks a "code-inspector" agent for GitHub details. Hierarchical task decomposition without explicit orchestration frameworks.

Containerization: Each agent runs as a separate service. This is essential for scaling, if one agent crashes, others keep running. For solo builders, this also means you can develop agents independently and merge them later.

Practical Use Case: Tech Trend Analysis

The repo includes a minimal UI for "Tech Trend" analysis, likely a multi-step pipeline:

1. Researcher agent queries GitHub and Brave search for trending repos
2. Analyzer agent examines repository code and metrics
3. Synthesizer agent combines findings into a report

Each agent is isolated but shares context via MCP tools. If analysis takes too long, you can scale the analyzer horizontally. If search patterns change, you update only the researcher.

Why This Matters for Solo Builders

Operational simplicity: No complex DAG schedulers (like Airflow). No proprietary workflow languages. Just HTTP, containers, and standard protocols.

Cost efficiency: Run only what you need. Agents sit idle until work arrives, perfect for pay-per-execution cloud platforms.

Debuggability: Each agent has logs. Each MCP call is traceable. When something breaks, you know which agent failed and why.

Composability: Want to add a new agent? Write it in any language (Go, Python, Rust), wrap it in an MCP server, and wire it up. No framework rewrite needed.

Key Open Questions (From the Author)

The repo raises two critical questions for AI business builders:

Will multi-agent protocols stick? MCP and A2A assume agent-to-agent communication is valuable. But maybe the future is single, very capable LLMs with vast plugin stacks (e.g., OpenAI's model with 100 tools). If that's true, orchestration patterns matter less.

Or single powerful models with plugins? This would simplify operations, one API call, one model, many tools. But it might reduce specialization and increase latency (one model doing research, analysis, and synthesis sequentially).

For solo builders, this matters. If the industry converges on single-model + plugin architecture, your orchestration code becomes simpler but less flexible. If multi-agent wins, you need solid patterns now.

What's NOT Production-Grade

The author is honest: this is a learning repo, not a battle-tested system. Missing pieces likely include:

• Retry logic and circuit breakers for agent failures
• Request rate limiting and queue management
• Observability (tracing, metrics, logging)
• Authentication between agents
• Persistent state management
• Cost tracking per agent

But these are implementation details. The architectural patterns are solid.

Getting Started

Clone the repo, read the demo code, and experiment. The FastAPI + Pydantic-AI + MCP pattern is transferable:

1. Define your agents' responsibilities
2. Expose their capabilities as MCP servers
3. Use FastAPI to coordinate requests
4. Document the A2A protocol for inter-agent calls
5. Containerize and deploy

The author's blog (petrostechchronicles.com) will likely include slides and deeper walkthroughs.

Verdict

This is a high-quality, pragmatic example of multi-agent orchestration. It's not a framework to adopt wholesale, but a reference architecture to learn from and adapt. For solo AI builders considering how to structure complex agent systems, this repo is essential reading.