Azimut IA
Escenario ilustrativo. La empresa de esta página no existe: es un perfil habitual del sector, construido para explicar cómo se usaría Azimut. No describe a ningún cliente ni afirma resultados medidos.
La empresa del escenario
- 200 personas: 80 en ingeniería, 20 en producto y diseño, 40 en soporte y éxito de cliente, y el resto en ventas y estructura.
- Código en GitHub, documentación en una wiki, tickets en una herramienta de soporte y conversación en Slack.
- Buena parte de los equipos técnicos usa ya alguna herramienta de IA, cada uno la suya.
- Clientes en España y en otros países, con soporte en varios idiomas.
El problema
En una empresa de software el contexto existe, pero partido: el porqué de una decisión está en un hilo de Slack, el cómo en el repositorio y lo que pide el cliente en los tickets. Soporte escala a ingeniería preguntas que ya están documentadas; producto prioriza sin ver todos los tickets; un ingeniero nuevo tarda semanas en saber a quién preguntar. Y la empresa paga varias suscripciones de IA distintas, persona a persona, sin saber qué se usa ni cuánto cuesta.
Cómo se plantearía con Azimut
Azimut se conectaría al repositorio, a la wiki, a la herramienta de soporte y a la mensajería con los permisos de cada sistema, y sustituiría las suscripciones sueltas por una capa común con el gasto visible. La empresa publicaría cuatro agentes.
| Agente | Qué hace | Quién lo usa | Qué se mide |
|---|---|---|---|
| Soporte de nivel 1 | Responde a los tickets repetidos con la documentación y los tickets ya resueltos, y escala lo nuevo con el contexto reunido. | Soporte | Tickets resueltos sin escalar. |
| Contexto técnico | Responde «¿por qué se hizo así?» y «¿dónde está esto?» con el repositorio, la wiki y los hilos del equipo. | Ingeniería y soporte | Preguntas que dejan de interrumpir a un ingeniero. |
| Síntesis de feedback | Agrupa tickets y conversaciones de cliente en temas priorizados para producto. | Producto | Días desde el feedback hasta la decisión. |
| Notas de versión | Redacta las notas de versión y la documentación de cliente a partir de los cambios en el repositorio. | Producto e ingeniería | Horas por versión. |
Aquí la elección de modelo pesa más que en ningún otro sector: los equipos técnicos tienen preferencias claras y cambian cuando sale un modelo mejor. En Azimut cada persona elige por tarea entre OpenAI, Anthropic, Google y Mistral, y los agentes del equipo no dependen del modelo con el que se crearon.
Por dónde se empieza
Se empezaría por el soporte de nivel 1. Tiene la métrica más clara del escenario —tickets que no llegan a ingeniería— y, para funcionar, obliga a conectar la documentación y la herramienta de soporte, que son la base de los otros tres agentes.
Qué queda fuera
Azimut no es un asistente de programación dentro del editor: no compite con las herramientas que el ingeniero usa para escribir código, sino que reúne el contexto de la empresa alrededor del código. No despliega ni modifica el repositorio. Las integraciones concretas se confirman en el despliegue y solo se activan las que se han probado de extremo a extremo.
Cómo se mediría
Antes de encender ningún agente se fija el punto de partida, con cifras de la propia empresa y no con medias del sector.
Semana 0. Porcentaje de tickets que soporte escala a ingeniería, interrupciones a ingeniería por semana, días de incorporación del último ingeniero y el inventario de suscripciones de IA que paga hoy la empresa: cuántas, de qué proveedor y a qué coste.
Mes 3. Las mismas cifras, junto al panel de consumo de Azimut por usuario, equipo, modelo y herramienta, frente al gasto en suscripciones sueltas de la semana 0.
Preguntas frecuentes
¿Sustituye a nuestro asistente de programación?
No. Ese vive en el editor y escribe código; Azimut reúne el contexto de toda la empresa alrededor del código. Pueden convivir.
¿Podemos seguir usando el modelo que prefiere cada equipo?
Sí. Cada persona elige el modelo por tarea, y si mañana sale uno mejor se cambia por configuración, sin rehacer los agentes.
¿Qué pasa con el código privado?
Los agentes heredan los permisos de GitHub: quien no ve un repositorio no obtiene respuestas con él. Los proveedores de modelos no entrenan con los datos enviados.