#HitoFusion — IA operativa con Buzz y Cerebro

Implementación de un espacio colaborativo donde personas coordinan con agentes, consultan información operativa, preparan planes, analizan tickets y delegan tareas a especialistas digitales bajo reglas de seguridad, trazabilidad y aprobación humana.

1. Resumen ejecutivo

Resultado central. HitoFusion pasó de experimentar con IA como herramienta aislada a diseñar un sistema operativo interno de agentes conectado con procesos reales de soporte, proyectos y gestión diaria.

2. Desafío

La empresa debía integrar inteligencia artificial en flujos de soporte, tickets, tareas de proyecto, comunicación interna y decisiones técnicas sin alterar la fuente de verdad ni habilitar automatizaciones riesgosas. El diseño debía aportar contexto real, registrar evidencia, preservar el control personal y evitar que el conocimiento quedara disperso en conversaciones sueltas.

• Mantener Odoo como fuente de verdad.
• Evitar escrituras y acciones automáticas durante el piloto.
• Dar a los agentes únicamente el contexto y las herramientas autorizadas.
• Persistir planes, especificaciones, delegaciones, decisiones y aprobaciones.
• Escalar el conocimiento mediante una arquitectura repetible y gobernable.

3. Arquitectura implementada

3.1 Buzz como espacio de trabajo

Buzz funciona como interfaz colaborativa. Las personas interactúan con agentes mediante canales, mensajes y menciones; el hilo conserva el contexto conversacional y permite que decisiones y resultados sean visibles para el equipo.

3.2 Cerebro como coordinador

Cerebro recibe solicitudes, interpreta el objetivo y activa los flujos de análisis. Es un punto de entrada único: la persona no necesita conocer qué especialista debe intervenir ni cómo distribuir internamente el trabajo.

@Cerebro analizá el ticket 2026/03929
@Cerebro [SWARM START] procesá el ticket 2026/03929

3.3 Odoo como fuente de verdad

La conexión mediante un gateway controlado permite consultar evidencia autorizada en modo de solo lectura. El piloto no modifica tickets ni otros registros de Odoo.

3.4 Artefactos y trazabilidad

El runtime persiste planes diarios, especificaciones, delegaciones, aprobaciones y correcciones. Esta evidencia permite reconstruir qué se pidió, qué fuentes se consultaron, qué propuso el sistema y qué decisión tomó una persona.

4. Swarm especializado de soporte

El swarm opera en modo SHADOW: analiza y recomienda, pero no modifica Odoo, responde clientes, cambia tickets ni despliega código. La decisión y la acción final continúan bajo control humano.

5. Agentes personales

Los agentes personales representan a colaboradores dentro de los procesos internos. El piloto inicial incluye agentes para Ezequiel e Ignacio, orientados a:

• Preparar planes diarios desde tareas y tickets.
• Priorizar trabajo y generar especificaciones.
• Preparar delegaciones a Cerebro o a especialistas.
• Registrar aprobaciones, correcciones y trazas.
• Mantener control humano antes de cualquier acción sensible.

6. Flujo operativo de ejemplo

1. Una persona menciona a Cerebro y solicita analizar un ticket.
2. El sistema identifica el caso y normaliza el pedido.
3. El agente de evidencia consulta únicamente fuentes autorizadas.
4. El especialista de resolución propone diagnóstico y próximos pasos.
5. El agente de comunicación prepara un borrador.
6. El agente de revisión controla la calidad.
7. El análisis y sus fuentes quedan registrados.
8. Una persona revisa y decide cómo continuar.

7. Diferenciadores del enfoque

• Contexto real: los agentes trabajan sobre tickets, tareas, mensajes y evidencia operativa.
• Límites claros: el piloto bloquea escrituras automáticas y acciones riesgosas.
• Trazabilidad: planes, delegaciones y decisiones humanas se conservan como artefactos.
• Supervisión humana: cada persona puede aprobar, corregir, rechazar o reordenar.
• Arquitectura integrada: Buzz, Cerebro, Odoo y los especialistas forman un sistema, no un chatbot aislado.

8. Impacto esperado y validación

El piloto busca reducir el tiempo necesario para comprender tickets y tareas, mejorar la priorización, transferir conocimiento, disminuir trabajo repetitivo de análisis y producir respuestas internas más consistentes. Estos beneficios se presentan como resultados esperados: para considerarlos resultados demostrados deben medirse contra una línea de base.

9. Estado del piloto

• Workspace Buzz publicado y operativo.
• Cerebro activo como coordinador.
• Swarm de soporte configurado en modo SHADOW.
• Agentes personales iniciales desplegados.
• Conexión de solo lectura con Odoo mediante gateway controlado.
• Persistencia de artefactos de runtime.
• Pruebas de planes diarios, especificaciones, aprobaciones y delegaciones controladas.

10. Evolución prevista

1. Incorporar más personas al espacio de trabajo.
2. Validar casos reales de soporte y gestión diaria.
3. Medir tiempos de análisis y calidad de recomendaciones.
4. Ampliar los agentes personales por rol o área.
5. Definir políticas para automatizaciones de bajo riesgo.
6. Mantener revisión humana para acciones sensibles.

11. Evidencia y alcance documentado

El Gist aportado documenta la arquitectura, los componentes, el estado del piloto, sus restricciones y los beneficios esperados. No publica resultados de pruebas, series de métricas, fechas de observación ni comparación cuantitativa. Por eso esta ficha diferencia el estado funcional de los impactos que todavía deben validarse.