atom-agent-ia

Problem

Building and maintaining AI agents by hand for every use case doesn't scale: each integration ends up reinventing the same cycle of registering the agent, exposing it through an API, wiring up external tools, controlling token spend, and measuring what's actually happening in production.

Solution

atom-agent-ia is an AaaS (Agent as a Service) platform built with FastAPI and LangChain / LangGraph: it exposes AI agents as a consumable REST API, with token-based auth, usage quotas, three agent types (DAG, ReAct, and Deep) sharing the same agent registration, a no-code tool system (custom HTTP tools, MCP servers, structured-output tools), and an observability dashboard with per-session cost and latency — designed so integrating an agent into another system is as simple as calling a REST endpoint.

Stack & Architecture

• FastAPI as the API layer, in a layered architecture (router → service → repository → ORM model) with single responsibility per layer.
• LangChain / LangGraph to orchestrate three agent types on top of the same configuration (llm_id, system_prompt, tools): DAG (StateGraph with full graph control), ReAct (prebuilt, for general-purpose use), and Deep (multi-step reasoning via the deepagents library).
• PostgreSQL for persistence (agents, tokens, usage logs), with a connection pool sized to worker concurrency and automatic Alembic migrations on every startup.
• A dynamic tool system with zero code changes required: custom HTTP tools, MCP servers (automatically exposing all of their remote tools), and structured-output tools — all registered through the API.
• Docker / Docker Compose for deployment, with per-component logs (API and agent core) and stdout-based observability in multi-worker containers.
• Bearer-token auth (SHA-256 hashed), per-client token quotas, and per-session locking to serialize concurrent turns.

Challenges

Designing a single API generic enough for three different agent types without making it overly abstract — solved by keeping the same agent_id across routes and letting the invoked chat route (/agents/chat, /prebuilt-agents/chat, /deep-agents/chat) decide which wrapper to build. Another challenge was designing the tool system so third parties could register HTTP integrations or MCP servers without touching the agent's code, and doing it securely: direct database-access tools were removed from the project entirely for security reasons.