Los 19 agentes que mantienen el sistema vivo y mejorando: unos con modelo de lenguaje para reparar y revisar código, el resto deterministas, vigilando procesos, memoria, OOM, backups, demos y métricas. Es la capa que evita que tengas que entrar al servidor.
Lee GitHub Issues con label "bug"/"code-review" y la cola interna improvement_queue. Usa ReAct con LLM para implementar el fix mínimo, ejecuta pytest, commit+push si pasan. Filtro de errores transitorios (P1.1): 429/503/timeout no disparan patch — se silencian 1h porque no son bugs sino síntomas de cuota agotada o caída ajena.
git diff de los últimos 7 días en cada repo activo. El LLM analiza cambios buscando bugs reales (condiciones de carrera, excepciones tragadas, lógica invertida). Abre GitHub Issue con el fix propuesto (máx 2 por repo y ciclo), que BugFixer resuelve en su ronda diaria — un lazo review→fix completamente automático.
Consulta PyPI para cada requirements.txt. Clasifica cambios en PATCH/MINOR/MAJOR. Auto-aplica PATCH y MINOR con rollback. MAJOR de paquetes críticos (torch, sklearn) requiere aprobación por Telegram.
Recorre los proyectos activos: donde hay suite de tests la ejecuta (hoy solo NeuralOps tiene una de verdad) y donde no la hay se conforma con comprobar que el servicio responde. Si algo falla, el modelo analiza la traza y propone el arreglo, se reporta a Telegram y se abre un issue en GitHub.
Recorre todos los repos del portfolio. Si hay cambios sustantivos (filtro de ruido: ignora *.log, __pycache__, *_cache.json), commit + push con mensaje "chore: auto-sync". Detecta repos sin remoto y silencia el aviso 7 días.
Tras cada improvement aplicado por ProjectImprover, refresca dos campos del proyecto en MySQL: descripcion_corta (≤160 chars, forzado por LLM + truncado por palabra) y descripcion_larga (preserva la sección "Sobre el Proyecto" curada, sustituye solo el bloque "Última actualización"). Coalesce de mejoras múltiples del mismo slug en un solo write (P1.2).
Cada 30 min revisa agent_status.json buscando agentes "silenciosos" (sin reporte >2h). Lee los logs de las últimas 30 min, clasifica errores en críticos/no críticos por keywords (OOM, ENOMEM, traceback…), y reinicia el agente si está dead. Sin LLM — heurística determinista.
Cada 5 min escanea state.db en busca de tareas "running" colgadas más allá del umbral. Reinicia el servicio responsable vía systemctl, marca la tarea como recuperada en agent_errors, y limita reintentos para no entrar en bucle de restart.
Cada 15 min mide RAM/swap/disco con psutil. Si RAM ≥90% o swap=100%, pausa automáticamente 7 agentes pesados (improver, builder, bug_fixer, test_runner, competitive, market_review, analytics). Reanudación con histéresis al 80%, o forzosa tras TTL 4h aunque la RAM siga alta (P4.1).
Semanal: despierta cada demo que arranca bajo demanda, le lanza una petición REAL con datos de prueba, comprueba que la respuesta contenga lo que debe, y la vuelve a dormir. Cubre el punto ciego de los health checks: un 200 no dice que la demo funcione. En su primera ejecución localizó generador-imagenes roto (HuggingFace deprecó el modelo, 410) con el servicio activo y el health en verde.
Cada 15 min comprueba a fondo los 20 servicios declarados; de esos, 10 están siempre encendidos y los otros 10 arrancan bajo demanda y quedan exentos. Distingue vivo (2xx/3xx/401/403) de degradado (404 pero su documentación responde) y muerto (5xx o sin respuesta). Si detecta que el sistema lo mató por memoria, amplía su límite un 25% y lo reinicia. A los degradados no los toca: avisa para que se investiguen.
Diario a las 05:00 UTC. Lee la tabla MySQL projects del portfolio y sincroniza con /var/www/neuralops/projects.json. Asigna puertos libres a proyectos nuevos, normaliza keywords y categoría → sector. Sin esto, los agentes de NeuralOps no se enteran de proyectos añadidos vía web.
Cada domingo 23 UTC limpia el state.db: events >30 días, alertas >14 días, llm_cache >7 días. NO toca colas operativas (linkedin_drafts, email_drafts). También prunes llm_metrics >30 días. Sin esto, la tabla memory crece sin freno (~340 events/día).
Cada 60 s captura el snapshot de core.system_telemetry (Groq quota, errores 24h, latencia LLM P95/P99, colas, agentes pausados) y lo escribe atómicamente en /var/www/neuralops/state/telemetry.json. El portfolio Laravel lo sirve como /sistema sin tener que llamar a Python.
Cada 5 min hace una petición al health de cada proyecto activo. No avisa al primer fallo: exige 4 consecutivos (umbral que sale de su propio ADN) para descartar cortes de un segundo, y salta las demos que arrancan bajo demanda. Distingue «servicio caído» de «URL de health mal apuntada»: si el servicio responde en otra ruta avisa del error de configuración con el arreglo exacto, en lugar de dejar una alarma encendida para siempre.
Cada 30 min lanza tests funcionales de verdad contra cada demo: petición POST con un payload real y comprobación de que la respuesta contiene lo que debe, no solo que devuelva 200. Avisa cuando cambia el conjunto de endpoints que falla, no en cada pasada.
Cada 5 min mide el tiempo de respuesta de cada servicio y guarda desde cuándo está caído cada uno. Si alguno acumula demasiado tiempo sin responder, lo reinicia por systemctl sin intervención humana.
Diario a las 05:30 comprueba que el backup de esa noche existe, pesa lo que debe y no es más viejo de lo esperado. Si falta, ejecuta el script de backup en caliente y vuelve a verificar: solo escala a Telegram si la auto-reparación también falla.
Semanal: llama a los endpoints de predicción de los modelos con datos de referencia y compara el resultado con su baseline. Si la desviación pasa del 5% encola un reentrenamiento; por encima del 10%, con prioridad alta.
Otros clusters