PrometeoBackbone de IA del grupo
Backbone de IA: Me lo entregaron un miércoles. El jueves en la noche ya estaba desplegado en producción.
El servicio central de IA del grupo: las plataformas le envían los mensajes de sus usuarios y responde con Claude, usando habilidades que consultan los sistemas de cada empresa.
No lo construí yo: lo creó otro desarrollador. Yo lo recibí, lo audité, lo endurecí y lo desplegué en 48 horas, en el mismo servidor de la producción de AHDO. Está desplegado, pero las plataformas todavía no lo consumen.
.NET 10 
Blazor - Microsoft Agent Framework
Claude 
PostgreSQL - IIS
Las 48 horas, a escala
Antes, hasta el martes 20 Otro desarrollador crea el proyecto. Git registra sus tres commits ese martes, entre las 10:15 y las 11:11.
48 h de recibirlo a producción. Fuente: documentación de despliegue, oct 2026.
Hasta el martes 20 de octubre
Obra de otro desarrollador
Lo crea otro desarrollador
Es el servicio central de inteligencia artificial del grupo. Está hecho para que las plataformas de las empresas, AHDO y Ocupasalud 2.0, le reenvíen desde sus servidores los mensajes de chat de sus usuarios, y para que el backbone responda con Claude.
Para responder puede usar skills: instrucciones y herramientas que consultan los sistemas de cada empresa. La persona que escribe nunca habla directo con él: la llamada sale siempre del servidor de su plataforma, con una llave propia. Las personas que lo administran usan un panel web con el uso y el costo, los usuarios y las llaves, las skills y un área para probar el chat.
Un agente, todas tus skills, bajo control.
Powered by Claude · Microsoft Agent Framework
git log, martes 20 de octubre
- 10:1581 archivos
- 10:5150 archivos
- 11:112 archivos
- Arquitectura por capas
- Dominio, aplicación, infraestructura y web separados, con cada función en su propia rebanada.
- La API del agente
- Un punto de entrada para chatear, con respuesta completa o en streaming, protegido por llave.
- El panel
- Uso y costo, usuarios y llaves, skills, configuración y un área para probar el chat. Hecho en Blazor.
- Aprendizaje supervisado
- El agente propone qué recordar y una persona lo aprueba antes de que cuente.
- 60 pruebas E2E
- Ocho suites con Playwright, que recorren el panel y la API como lo haría una persona.
Cómo responde
Diseño del otro desarrollador, con cambios míos marcados
La vida de una pregunta
Sigue una pregunta desde que sale de una plataforma hasta que vuelve con su respuesta. Baja con el scroll: la escena avanza contigo.
¿Qué cursos de seguridad vial hay abiertos este mes?
Lo que recibe la plataforma, en orden
- skillcatalogo-cursos
- deltaHay tres abiertos: manejo defensivo, primeros auxilios en la vía y normas de tránsito. ¿Te paso el enlace de alguno?
- done1.840 tokens de entrada y 96 de salida
- Modelo
- Claude Haiku 4.5
- Entrada
- 1.840 tokens
- Salida
- 96 tokens
- Costo
- con la tarifa de Claude Haiku 4.5
Una plataforma pregunta
Así está diseñado: alguien escribe en el chat de AHDO o de Ocupasalud 2.0. El servidor de esa plataforma reenvía el mensaje al backbone con su propia llave. La llamada nunca sale del navegador de la persona.
La puerta de la llave
Una petición sin llave válida rebota con un 401 y no llega al agente. Cada plataforma tiene la suya, y se administra desde el panel.
El cupo de cada llave
Un limitador reparte fichas por llave y las repone cada pocos segundos. Si una plataforma gasta las suyas, recibe un 429 y espera, sin frenar a la otra.
El agente y sus skills
Con un cambio míoEl agente responde con Claude. Ve cada skill como una tarjeta con nombre y descripción, y cuando la pregunta coincide con una, la carga y sigue sus instrucciones. Cada plataforma ve solo las skills que se le asignan: desde mi cambio, nacen sin ninguna.
Una skill consulta un sistema
Con un cambio míoSi la skill trae herramientas HTTP, el agente llama al sistema de la empresa para traer el dato. Antes de abrir la conexión se revisa a dónde va de verdad: la red de metadatos de la nube queda por fuera, y el intento vuelve al agente como un error de texto.
La respuesta vuelve letra por letra
Con un cambio míoEl backbone contesta en streaming: eventos con el texto a medida que sale, un aviso cuando carga una skill y uno final con los tokens usados. Si el streaming falla a mitad de camino, ahora el error queda registrado.
El recibo
Con un cambio míoCada respuesta queda registrada con su modelo y sus tokens. El panel calcula el costo con la tarifa del modelo que respondió y no con una sola tarifa para todos.
Es una simulación del recorrido. La conversación, la skill y los tokens son ficticios y no salen de ningún sistema real; hoy ninguna plataforma lo consume todavía.
Miércoles 21
Mi parte
Lo recibo y lo audito
Me lo entregaron para producción y el piloto era la semana siguiente. Antes de tocar nada, lo audité y lo probé en local. El código venía pensado para desarrollo. Esto es lo que encontré y cómo quedó.
- Acceso
Lo que encontré: Venía pensado para desarrollo: sembraba usuarios de prueba con claves débiles y los volvía a crear en cada arranque si se les cambiaba el correo o se borraban.
Cómo quedó: La siembra depende del entorno. En producción solo nace un administrador inicial con clave fuerte.
- Acceso
Lo que encontré: El inicio de sesión del panel aceptaba intentos sin límite.
Cómo quedó: Diez intentos cada cinco minutos, con aviso en pantalla.
- Aislamiento
Lo que encontré: Cada sistema conectado nacía viendo todas las skills: AHDO habría podido usar las de Ocupasalud, que consultan los sistemas de otra empresa.
Cómo quedó: Las plataformas y los usuarios nuevos nacen sin skills. Cada skill se asigna a mano.
- Red
Lo que encontré: Las herramientas de las skills podían llamar a cualquier dirección, incluida la red de metadatos de la nube, y esa dirección la decide en parte el modelo.
Cómo quedó: La conexión rechaza la red de metadatos al abrir el socket.
- Costo
Lo que encontré: El tablero calculaba todo con la tarifa de un solo modelo.
Cómo quedó: Cada respuesta se cobra con la tarifa de su modelo.
- Registro
Lo que encontré: El chat en streaming no dejaba rastro cuando fallaba y aceptaba mensajes de más de 20.000 caracteres, que el chat sin streaming sí rechazaba.
Cómo quedó: Registra sus errores y rechaza los mensajes demasiado largos, igual que el otro.
- Publicación
Lo que encontré: La configuración de desarrollo viajaba dentro de la aplicación publicada.
Cómo quedó: Ya no se publica.
- Panel
Lo que encontré: El chat de prueba se quedaba bloqueado al enviar con Enter, botones e interruptores no anunciaban su estado a los lectores de pantalla y la lista de usuarios se desbordaba en el celular.
Cómo quedó: Los tres quedaron corregidos.
Jueves 22, 10:45
Mi parte
Un commit para producción
2030eccPrepara Prometeo para producción: acceso seguro y arreglos del panel
16 archivos+218−63
De desarrollo a producción
El backbone siembra sus datos solo, cada vez que arranca. Separé esa siembra por entorno. En desarrollo siguen los usuarios de prueba, porque las 60 pruebas E2E del otro desarrollador los necesitan. En producción nace un solo administrador, y las plataformas nacen sin skills.
Acciona la palanca: arrástrala, toca la escena, usa el interruptor o, en el celular, gíralo. Después intenta entrar al panel en los dos modos.
Como venía, el backbone sembraba usuarios de prueba con claves débiles y cada plataforma nueva veía todas las skills. En producción queda un solo administrador con clave fuerte y las plataformas nacen sin skills. El inicio de sesión del panel, que no tenía límite, ahora admite diez intentos cada cinco minutos.
El modelo no puede pedir las credenciales del servidor
Las skills pueden llamar a otros sistemas, y la dirección de esa llamada la decide en parte el modelo. En la nube hay una red de metadatos que entrega datos sensibles del propio servidor a quien la consulte. Revisar el texto de la dirección no alcanza: una redirección o un dominio con otro nombre pueden terminar ahí.
Por eso la revisión ocurre al abrir la conexión, cuando ya se sabe a dónde va de verdad. Elige a dónde llama la skill:
La llamada al sistema de la empresa pasa. La que apunta a la red de metadatos, la que llega por una redirección y la que se disfraza con otro nombre se estrellan al abrir la conexión.
Un costo que mentía a la mitad
El tablero calculaba el costo de todo con la tarifa de un solo modelo. Era un fallo silencioso: nada se rompía y los números parecían razonables. Ahora cada respuesta se cobra con la tarifa del modelo que la contestó.
Con Claude Haiku 4.5 el tablero cuadraba. Con Claude Sonnet 5.5 mostraba más o menos la mitad del costo real. Además, con Sonnet 5.5 el razonamiento del modelo se comía el tope de tokens y la respuesta salía cortada sin aviso: la configuración ahora advierte que hay que subirlo.
En el mismo commit también quedaron otros arreglos. El chat en streaming registra sus errores y rechaza los mensajes demasiado largos, como ya lo hacía el chat sin streaming. El chat de prueba ya no se traba al enviar con Enter. Botones e interruptores anuncian su estado a los lectores de pantalla. La lista de usuarios ya no se desborda en el celular. Y la configuración de desarrollo dejó de viajar dentro de la aplicación publicada.
Jueves 22, en la noche
Mi parte
Despliegue y prueba desde afuera
El backbone se desplegó en el mismo servidor donde corre la producción de AHDO. Equivocarse ahí dejaba sin servicio a una plataforma en producción.
.NET 10 junto al .NET 8 de AHDO
El paquete de hosting se instaló en horario bajo: reiniciar IIS deja a AHDO sin servicio unos segundos.
WebSockets en IIS
El panel está hecho en Blazor y vive de una conexión abierta con el servidor.
Casa propia dentro del servidor
Sitio, grupo de aplicaciones y base de datos propios, para que un fallo del backbone no toque a AHDO.
La causa de la caída
En local arrancaba y en el servidor no. La causa era un valor inválido en la configuración de registros.
HTTPS
El panel y la API quedaron publicados con HTTPS.
La prueba desde afuera
- Chequeo de saludokla aplicación está viva
- Abrir el panelcargaBlazor responde
- WebSocket del panel101la conexión abierta sube de protocolo
- API sin llave401la puerta está cerrada
Es una reproducción de la validación que quedó registrada en la documentación del despliegue: no se conecta al servidor. Va sin direcciones porque es un panel de administración y su dirección no se publica.
Según git, al 22 de octubre
Quién hizo qué
Otro desarrollador: lo creó3 commits y unas 9.950 líneas añadidas, el martes 20
Yo: lo recibí, lo audité, lo endurecí y lo desplegué1 commit, 218 líneas añadidas y 63 quitadas en 16 archivos, el jueves 22
Lo creó otro desarrollador y me lo entregó para producción. Lo audité, lo endurecí con usuarios iniciales seguros, límite de intentos de acceso, bloqueo de la red de metadatos de la nube y costos por modelo, y lo desplegué en 48 horas.
1 commit mío. La arquitectura, el panel y las pruebas son de otro desarrollador. El aprendizaje supervisado y las skills también son suyos.
Las correcciones las hice con asistencia de IA, bajo mi dirección y con mi revisión; git las registra a mi nombre.
Grupo Empresarial Prometeo. Oct 2026.
Al 27 de octubre
Lo que todavía falta
- PanelDesplegado
- API del agenteDesplegada y cerrada sin llave
- AHDOSin conectar
- Ocupasalud 2.0Sin conectar
Está desplegado, pero las plataformas todavía no lo consumen.
Al desplegarlo faltaba emitir las llaves de cada plataforma y conectar sus servidores. En AHDO todavía no hay código que lo llame. Por eso aquí no hay cifras de uso.