Context
Nexo IA began as the final project of a course on AI agents and MCP. The team first planned a vehicle-procedure assistant, then expanded the concept into a reusable infrastructure layer for multiple institutions and domains.
Its maturity is part of the story: this is experimental architecture with an active roadmap. It is not presented as a mature institutional product.
The institutional problem
Government information and services are fragmented across agencies, infrastructure and departments. Citizens often need to know where to look before they can even begin a process.
A general chatbot does not solve the trust, versioning, permission or audit questions involved in institutional action.
Actors and channels
The proposed channels include a citizen web portal, an administrative console, voice and WhatsApp. Behind them, specialized agents, verified sources and permission-aware tools separate information retrieval from authorized action.
Vision
Nexo IA is designed as a universal directory that adapts to existing systems instead of requiring every institution to migrate. An institution could connect documentation, APIs, legacy systems, catalogs, processes and metrics.
The platform would map sources, retrieve verifiable information, expose authorized tools, request confirmation, execute an action, record an audit trail and generate safe administrative interfaces with A2UI.
Product flow
- Receive a request through web, voice or messaging.
- Classify the domain and retrieve versioned sources.
- Compose an answer with traceable evidence.
- If an action is requested, identify an authorized MCP tool.
- Apply permissions and deterministic validation.
- Ask for confirmation before execution.
- Record events and results for auditability.
Architecture
The frontend combines Next.js with an A2UI renderer. A FastAPI backend handles authentication, conversations, runs, SSE, actions, webhooks and administration. Shared Pydantic, OpenAPI and JSON Schema contracts connect the layers.
LangGraph orchestrates workflows and checkpoints. Specialized agents work with hybrid RAG, a permission-aware MCP tool catalog and safe A2UI builders. PostgreSQL stores tenants, conversations, actions and audit records; observability and evaluations remain first-class layers.
Key technical decisions
- Separate retrieval, verification and action instead of giving one agent unrestricted responsibility.
- Use versioned, domain-specific sources and preserve their traceability.
- Require deterministic checks and explicit confirmation around consequential tools.
- Share contracts across services through typed schemas and versioned events.
- Treat observability, audit records and evaluation datasets as product infrastructure.
My contribution
I designed the architecture and delegated development tasks. I focused on the agent layer, RAG, MCP, infrastructure, shared contracts and observability.
This was team work completed under an aggressive course deadline. The current breadth is a roadmap and architectural exploration, not evidence that every adapter is production-ready.
Main challenge
The hardest challenge was defining how agents and MCP tools should interact: what context they receive, how permissions apply, when deterministic validation is required and how every action becomes traceable.
Outcome and current state
Nexo IA is an early experimental platform. Its first stage established an architecture and a working direction; mocks and incomplete boundaries remain on the active roadmap.
The system is designed to preserve source, validity and traceability. It does not claim that generated information is always correct.
What I learned
I learned MCP and agent-oriented architecture from zero and applied both to a specific institutional workflow instead of treating them as isolated demos.
What I would change
I would define capability boundaries, runtime ownership and contracts before expanding the number of agents and domains.
Roadmap
The roadmap includes a stronger MCP mapper, clearer capability boundaries, real adapters, durable workers, systematic evaluations, tool-level security, better observability, dynamic A2UI forms, load testing and corpus governance.
Interface gallery
The final gallery requires the citizen chat, sources, voice, administrative view, tool flow, A2UI and an architecture diagram captured from the real prototype.
Written demo
The planned demo labels the prototype clearly, follows an informational question to its sources, requests an authorized action, shows confirmation and traceable events, then closes with the administrative interface and roadmap.
Source
The repository is public and available through the verified source link provided in this case study.