El problema
Distintos equipos de la empresa necesitaban asistencia de IA para sus propios flujos de trabajo — soporte, operaciones y herramientas internas, todos querían "un agente que entienda nuestra área". Construir una aplicación separada por equipo no era sostenible: implicaba autenticación duplicada, UI duplicada, y trabajo de integración duplicado cada vez que alguien necesitaba un nuevo agente.
En su lugar construimos una única plataforma: cada agente especializado expone la misma interfaz conversacional simple, donde el usuario solo describe su tarea. Por debajo, un workflow de n8n orquesta la ejecución real, conectándose a los modelos de IA y las herramientas que cada agente necesita.
Rol e impacto
- Proyecto en equipo, full-stack.
- Interfaz conversacional unificada para múltiples agentes especializados bajo una sola plataforma.
- Arquitectura por features que permite agregar nuevos agentes/áreas sin tocar módulos no relacionados.
- Control de acceso basado en roles (RBAC) para que cada equipo solo vea y opere los agentes relevantes para ellos.
Decisiones técnicas y retos
A medida que se agregaban más agentes para distintas áreas del negocio, una estructura convencional por capas (todos los componentes juntos, todos los hooks juntos, etc.) empezó a dificultar identificar qué código pertenecía a qué agente, y facilitaba acoplar por accidente áreas no relacionadas entre sí.
Organizamos el código por feature, donde cada agente/área es dueño de sus propios componentes, hooks y acceso a la API, y agregamos control de acceso basado en roles por encima para que los permisos se apliquen de forma consistente en el límite de cada feature, en lugar de estar dispersos en pantallas individuales. Esto mantuvo a los agentes aislados entre sí y facilitó razonar sobre quién puede acceder a qué.
Cada agente necesita llamar a distintos modelos de IA y distintas herramientas internas/externas según la tarea en la que esté especializado. Construir y mantener esa lógica de orquestación directamente en la aplicación habría implicado redesplegar el frontend cada vez que cambiara un workflow.
Decidimos delegar la orquestación a workflows de n8n, con la plataforma actuando como una capa conversacional delgada que envía la solicitud del usuario al workflow correcto y devuelve el resultado. Esto permitió al equipo iterar sobre la lógica interna de un agente (qué modelo llamar, qué herramientas encadenar) sin tocar el código de la aplicación, a cambio de que la plataforma necesitara un contrato claro y versionado con cada workflow.
Stack detallado
| Capa | Tecnología | Por qué |
|---|---|---|
| Frontend | Next.js, shadcn/ui, React Query | UI conversacional rápida con componentes consistentes y data fetching |
| Validación | Zod | Validación type-safe de requests/responses de agentes en el límite |
| Backend/Auth | Supabase | Autenticación, base de datos y control de acceso basado en roles |
| Orquestación | n8n | Conecta agentes con modelos de IA y herramientas internas sin redeploys |
| Tooling | Biome | Linting/formatting rápido en todo el monorepo |
Galería
Qué haría diferente
Formalizaría el contrato entre la plataforma y cada workflow de n8n antes — versionar la forma esperada de entrada/salida por agente desde el inicio habría evitado algunos cambios rompedores a medida que se agregaban nuevos agentes.