Caso 5 del Atlas de Arquitecturas Agénticas. El agente con semáforo explica la arquitectura Single Agent + Tools + Router: Este patrón combina un agente con herramientas y una capa de decisión condicional para enviar cada caso al flujo correcto.
Serie: Atlas de Arquitecturas Agénticas · Estudio Naranja · Lectura aproximada: 10 minutos.
La idea en una frase
Representación visual de la arquitectura del Agente con Semáforo (Routing Logic).
Un semáforo no maneja el carro, pero decide cuándo cada flujo puede avanzar. En sistemas agénticos, el router cumple una función parecida: clasifica, separa caminos y evita que todo termine en la misma respuesta.
Este patrón combina un agente con herramientas y una capa de decisión condicional para enviar cada caso al flujo correcto.
Estudio Naranja
Qué problema resuelve esta arquitectura
No todas las solicitudes deben tratarse igual. Un lead caliente, una queja, una solicitud técnica y una pregunta frecuente pueden llegar por el mismo canal, pero requieren rutas distintas. El router evita que el agente responda de manera plana.
La clave no es preguntar si esta arquitectura es “mejor” en abstracto. La pregunta correcta es más concreta: ¿qué tipo de trabajo debe sostener?, ¿qué riesgo introduce?, ¿qué nivel de autonomía se puede permitir y qué tanta trazabilidad necesita la organización?
Componentes principales
| Componente | Función dentro del sistema |
|---|---|
| Entrada | Webhook, chat, formulario, correo o API. |
| Agente | Interpreta el mensaje y puede consultar herramientas. |
| Clasificador | Determina intención, urgencia, categoría o riesgo. |
| Router/IF | Dirige hacia distintas salidas según reglas. |
| Herramientas | CRM, calendario, Notion, GitLab, email, bases de datos. |
| Salidas múltiples | Responder al usuario, crear ticket, escalar a humano, activar automatización. |
Cómo fluye el trabajo
Aunque cada implementación cambia según las herramientas disponibles, el flujo conceptual puede leerse así:
Esquema condicional: Clasificación del mensaje y enrutamiento dinámico al flujo correcto.
- Entra un mensaje.
- El agente interpreta y puede enriquecer con datos.
- Se calcula una categoría o condición.
- El router elige camino.
- Cada camino usa herramientas o respuestas distintas.
- Se registra cuál ruta se tomó y por qué.
Cuándo tiene sentido usarla
- Clasificación de tickets.
- Lead scoring y enrutamiento comercial.
- Soporte de primer nivel con escalamiento.
- Automatizaciones donde hay reglas claras de negocio.
- Priorización de alertas internas.
Cuándo no conviene usarla
- Problemas abiertos donde no hay categorías estables.
- Procesos que requieren razonamiento colaborativo complejo.
- Casos donde una clasificación errónea puede causar daño grave sin revisión.
- Organizaciones sin reglas mínimas de decisión.
Riesgos y cuidados de diseño
| Riesgo | Cómo entenderlo |
|---|---|
| Reglas opacas | Si nadie entiende por qué tomó una ruta, el sistema se vuelve difícil de corregir. |
| Clasificación incorrecta | Un mal router puede mandar un caso urgente al camino equivocado. |
| Crecimiento desordenado | Cada nueva excepción puede agregar ramas hasta volver inmanejable el flujo. |
| Falsa sensación de control | Tener IFs no significa que el sistema esté gobernado si las condiciones son vagas. |
Caso empresarial imaginado
Un formulario de contacto de una consultora recibe mensajes diversos. El agente analiza el texto: si detecta oportunidad comercial, crea lead en CRM; si detecta soporte, abre ticket; si detecta alianza, envía a dirección; si detecta spam, no responde. El valor está en que una sola puerta de entrada puede alimentar varios procesos.
Este ejemplo no pretende vender una receta universal. Sirve para mostrar cómo el patrón se traduce en decisiones concretas: permisos, herramientas, puntos de control, memoria, trazabilidad y nivel de intervención humana.
Cómo lo diseñaría Estudio Naranja
En una consultoría real, no empezaríamos por dibujar agentes. Empezaríamos por mapear el trabajo actual: entradas, decisiones, datos, excepciones, riesgos y responsables. Después elegiríamos la arquitectura mínima que pueda resolver el problema sin sobrediseñar.
- Primero: delimitar el proceso y sus salidas verificables.
- Segundo: decidir qué herramientas son necesarias y cuáles serían peligrosas al comienzo.
- Tercero: definir memoria, permisos y bitácora de acciones.
- Cuarto: probar con casos reales pequeños antes de abrir autonomía.
- Quinto: medir precisión, tiempo ahorrado, errores y necesidad de intervención humana.
Preguntas antes de construir
- ¿Qué categorías existen realmente?
- ¿Cuáles rutas requieren humano?
- ¿Qué evidencia usa el agente para clasificar?
- ¿Qué pasa con casos ambiguos?
- ¿Cómo se mide error de enrutamiento?
Indicadores para saber si va funcionando
Una arquitectura agéntica no debería evaluarse por lo sofisticada que parece en el diagrama, sino por su comportamiento en operación. Antes de ampliar autonomía conviene medir señales pequeñas pero constantes: tiempo de respuesta, porcentaje de tareas completadas sin retrabajo, número de intervenciones humanas, errores por categoría y calidad percibida por el equipo que usa el sistema.
También es importante observar los falsos positivos y los falsos negativos. Un falso positivo ocurre cuando el agente actúa con demasiada confianza en un caso que no correspondía. Un falso negativo aparece cuando el sistema se queda corto, no usa una herramienta disponible o escala a humano algo que ya podía resolver. Ambos errores enseñan dónde ajustar instrucciones, permisos, memoria o rutas.
Nivel mínimo viable para empezar
La implementación inicial debería ser deliberadamente pequeña. Un buen prototipo no intenta cubrir toda la empresa: toma un flujo real, diez o veinte ejemplos históricos, define criterios de éxito y prueba el patrón en un entorno controlado. Si el sistema no puede explicar qué hizo, con qué información y por qué tomó una decisión, todavía no está listo para ampliar alcance.
La madurez llega por capas: primero lectura y recomendación; después borradores y acciones reversibles; luego automatización parcial; finalmente autonomía en tareas de bajo riesgo. Ese avance gradual permite que la organización gane confianza sin confundir velocidad con gobierno.
La lección del caso
El agente con semáforo no es una moda ni una plantilla para copiar sin pensar. Es un patrón de arquitectura. Su valor aparece cuando ayuda a ordenar una capacidad concreta: qué entra, quién decide, qué herramienta se toca, qué se recuerda, qué se registra y qué se devuelve.
En sistemas agénticos, el rigor no está en usar más agentes. Está en saber por qué cada pieza existe. A veces un solo agente con una herramienta bien gobernada vale más que una red completa de agentes mal coordinados.
Próxima entrega
En la próxima entrega seguiremos con El copiloto que pide aprobación, donde veremos la arquitectura Single Agent + Human in the Loop + Tools y cómo cambia el diseño cuando el trabajo requiere otro tipo de coordinación.
