Why This Matters
As AI systems evolve from simple chatbots to autonomous agents capable of executing complex workflows, understanding their architectural evolution becomes critical—especially for security practitioners. This project documents my hands-on exploration of agentic AI development, progressing through four distinct architectural patterns, each with unique security, scalability, and operational trade-offs.
Built entirely with open-source tools and local-first LLMs (no API keys, no cloud dependencies), this work demonstrates production-ready patterns for enterprises concerned about data sovereignty, model security, and supply chain risks.
The Four Stages of Evolution
The diagram below illustrates the architectural progression from a monolithic single agent to a fully distributed Agent-to-Agent (A2A) network:
Figure: Architectural evolution across 4 stages—Monolithic → MCP Separation → Supervisor-Worker → Distributed A2A Network
Stage 1: Single Agent (Monolithic)
Architecture: A single agent process containing Memory (SQLite), Tools (Math and File Functions), and LLM (Ollama with llama3.1).
Use Case: Ideal for learning and prototyping. The agent handles all tasks—from natural language understanding to tool execution—within one unified process.
✓ Pros:
- Simple to develop and debug
- No network overhead or inter-process communication
- Direct access to all tools and memory
✗ Cons:
- No separation of concerns—tools run with full agent privileges
- Difficult to scale horizontally
- Single point of failure
Stage 2: Single Agent + MCP Server
Architecture: The agent now communicates with an external Model Context Protocol (MCP) server. Tools (Math and File) run in a separate process, isolated from the main agent.
Use Case: Introduces process isolation for security. The agent sends structured tool calls to the MCP server over a local protocol, preventing direct file system or math operation access.
✓ Pros:
- Security boundary: agent cannot directly execute tools
- Tools can be restarted independently of the agent
- Foundation for multi-agent architectures
✗ Cons:
- Increased complexity with inter-process communication
- Still a single agent—no task specialization
- MCP server is a single point of failure for all tools
Stage 3: Supervisor-Worker (with MCP)
Architecture: A Supervisor Agent orchestrates task routing to specialized Worker Agents (Worker 1, Worker 2). Each worker has its own Memory and LLM instance. A shared MCP server provides centralized tool access (File Tool, Math Tool).
Use Case: Classic hub-and-spoke pattern. The supervisor translates user intent into subtasks, delegates to workers, and aggregates results. Workers are role-restricted—only accessing tools they need.
✓ Pros:
- Task specialization: workers can be fine-tuned for specific domains
- Role-based access control: workers only access permitted tools
- Supervisor validation gates reject unsafe operations
- LangGraph manages complex state transitions across agents
✗ Cons:
- Supervisor becomes a bottleneck for all requests
- Shared MCP server limits tool concurrency
- Supervisor prompt engineering is critical—poor routing degrades performance
Implementation Detail: I used LangGraph for state machine management and SQLite for agent memory persistence, ensuring session continuity across restarts.
Stage 4: A2A Network (Distributed)
Architecture: Fully distributed microservices model. The Main Agent Service (Supervisor Client) communicates with independent agent servers over HTTP/A2A Protocol:
- File Agent Service (Port 8001): Runs its own LLM, Memory, and File Tools
- Math Agent (integrated in Main Service): Handles calculations locally
Use Case: Production-scale agentic systems where agents are deployed as independent services, potentially across different machines or cloud environments.
✓ Pros:
- True horizontal scalability—deploy agents on separate machines
- No shared dependencies (no centralized MCP server)
- Agent-level fault isolation: one agent crash doesn't affect others
- Language-agnostic: agents can be written in Python, Go, Rust, etc.
- Smart request translation prevents LLM hallucination in agent commands
✗ Cons:
- Network latency and reliability concerns
- Requires service discovery and load balancing in production
- More complex debugging (distributed tracing needed)
- Anti-loop logic required to prevent infinite command cycles
Implementation Detail: I implemented loop-breaking logic to detect and prevent repeated commands, and strict JSON-RPC validation to ensure commands conform to agent API schemas.
Security by Design: Automated SAST Integration
A critical component of this project is the integration of automated security scanning directly into the development workflow. I built a Claude Code skill that runs 900+ Semgrep SAST rules against the entire codebase, triages findings against actual source code, and generates HTML vulnerability reports with remediation guidance.
Key Security Features
- Role-based separation: Workers cannot access tools outside their permissions
- Supervisor validation gates: Reject unsafe operations before execution
- Process isolation: MCP runs separately from main application (Stage 2+)
- Smart request translation: Prevent LLM hallucination in agent commands (Stage 4)
- Anti-loop mechanisms: Detect and block repeated commands (Stage 4)
- Local-first LLMs: No data leaves your machine—zero external API calls
- Automated SAST: Semgrep scans on every code change, triaged by AI
Technology Stack
Core Frameworks
- LangGraph (state management)
- Ollama (local LLM inference)
- FastMCP (Model Context Protocol)
- A2A SDK (agent-to-agent protocol)
Infrastructure
- Python 3.11+
- SQLite (agent memory)
- Streamlit (web UI)
- Uvicorn (ASGI server)
Security Tooling
- Semgrep SAST (900+ rules)
- Claude Code integration
- HTML vulnerability reports
Model
- llama3.1 (via Ollama)
- 100% local inference
- No external API dependencies
When to Use Each Architecture
Stage 1 (Monolithic): Prototyping & Learning
Use for MVP development, proof-of-concepts, or educational projects where simplicity is paramount.
Stage 2 (MCP Separation): Security-First Development
Use when process isolation is required but you don't need multiple agents yet. Good for single-user tools with elevated security requirements.
Stage 3 (Supervisor-Worker): Enterprise Orchestration
Use when you need task specialization and role-based access control within a single deployment. Ideal for orchestrating complex workflows with centralized governance.
Stage 4 (A2A Network): Production-Scale Distributed Systems
Use when you need true horizontal scalability, fault isolation, and the ability to deploy agents as independent microservices. Best for multi-tenant SaaS platforms or large-scale automation systems.
Key Learnings
- 1.Security must be architectural, not additive. Process isolation (Stage 2) and role-based permissions (Stage 3) prevent entire classes of vulnerabilities that cannot be patched after deployment.
- 2.Supervisor prompt engineering is critical. In Stage 3, poor routing logic can cause task failures, infinite loops, or privilege escalation. Explicit schemas and validation are non-negotiable.
- 3.Local-first LLMs reduce risk. By using Ollama (llama3.1) instead of cloud APIs, I eliminated data exfiltration risks, API key management, and dependency on third-party uptime.
- 4.Distributed agents need anti-loop logic. Without cycle detection (Stage 4), agents can repeatedly call each other, burning tokens and degrading performance.
- 5.Automated security scanning is essential. Integrating Semgrep into the development loop (via Claude Code) caught vulnerabilities before they reached production.
What's Next?
This project lays the foundation for exploring:
- Multi-modal agents: Incorporating vision (image analysis) and audio (transcription) tools
- Distributed tracing: Implementing OpenTelemetry for observability across A2A networks
- Agent authentication: Adding mutual TLS and JWT-based auth between agents
- Dynamic agent discovery: Service mesh patterns for auto-scaling agent fleets
- Red-teaming agentic systems: Prompt injection, tool-use exploits, and adversarial testing
Try It Yourself
The full implementation is available on GitHub with detailed setup instructions, architectural documentation, and runnable examples for all 4 stages.
View on GitHub