El meta-agente que diseña, despliega y corrige arquitecturas de IA

El motor detrás de nuestra promesa de infraestructura propia. Producto propio, en desarrollo activo.

¿Qué es?

Un grafo de estados que diseña, genera, despliega, estresa, diagnostica y corrige arquitecturas de IA generativa — RAG, agentes, microservicios— sobre Docker local, SSH remoto o nube efímera. No es un generador de plantillas: levanta contenedores reales, les inyecta tráfico real, lee logs reales y corrige la arquitectura hasta que sea estable.

Python 3.11+ FastAPI Pydantic v2 Docker SDK asyncssh Terraform

Cómo funciona

Un ciclo de ocho pasos entre diseño, despliegue real y auto-corrección.

1

Preflight

Interroga el destino real antes de diseñar nada: ¿hay Compose v2? ¿runtime NVIDIA? ¿puertos libres? ¿cuánta VRAM queda disponible? El diseño parte de capacidades reales, no de lo que alguien declaró.

2

Arquitecto

Un LLM decide la arquitectura, pero no escribe YAML: emite un blueprint validado (Pydantic, enums cerrados) contra las capacidades reales del destino. El código, no el modelo, traduce eso a manifiestos.

3

Sizing

Un motor de sizing consciente de GQA calcula VRAM, presupuesto de KV-cache, throughput teórico y tamaño del índice vectorial. Es una hipótesis, no un veredicto: solo el paso de pruebas de carga la confirma.

4

Constructor

Código determinista, sin LLM, traduce el blueprint a manifiestos de Docker Compose reproducibles y testeables: el ciclo de corrección gasta iteraciones en errores de arquitectura, no de indentación.

5

Desplegador

El nodo de mayor riesgo es, a propósito, el más aburrido: cero inteligencia, cero decisiones. Ejecuta un plan ya resuelto sobre el destino —local, SSH o nube efímera— a través de drivers intercambiables.

6

Pruebas de carga

Inyecta tráfico real de forma asíncrona y mide TTFT, TPOT, TPS y percentiles de latencia. Es quien certifica si el sizing calculado era correcto, comparando lo teórico contra lo medido.

7

Diagnóstico

Si algo falla, cada hallazgo debe citar una línea real de log. Sin evidencia literal, el hallazgo se descarta antes de llegar al informe: cero especulación sobre causas no observadas.

8

Corrección

El ciclo Crítico → Constructor → Desplegador repite con un límite de intentos y nunca repite una configuración que ya falló: cada corrección mueve al menos un parámetro en dirección monotónica.

Lo que no negociamos

Cuatro reglas duras, aplicadas en código

No son promesas de producto: son validaciones que corren antes de que cualquier comando toque un servidor real.

Nunca reinicia el host

Prohibido reiniciar o apagar el servidor destino, aplicado en tres capas independientes: validador de comandos, validador de artefactos generados y saneador del informe final.

Sin modelos de visión

El catálogo solo admite modelos de texto de pesos abiertos. Un modelo con otra modalidad se rechaza antes de diseñar nada.

Evidencia literal, cero especulación

Todo hallazgo de diagnóstico debe citar una línea real de log, con su archivo y su número de línea. Sin evidencia, se descarta.

Salida en Markdown estructurado

Nunca JSON crudo hacia el frontend: encabezados, tablas y bloques de código legibles, generados desde plantillas.

Estado real, sin maquillaje

Mismo criterio que usamos en el resto del sitio: preferimos decir lo que falta a inflar lo que hay.

H0 a H5 completos, más autenticación de API y perfil de despliegue en CPU: 409 tests en verde, ruff limpio y mypy en modo estricto sin errores en 95 módulos.

El asterisco que importa: toda esa verificación es contra dobles de prueba (fakes), no contra un daemon de Docker real todavía. Los cuatro tests de integración contra Docker ya están escritos, pero nunca se han ejecutado — es el siguiente paso, y el que más información nos va a dar.

Cómo se usa

Una petición describe la carga de trabajo, el hardware disponible y el destino. El meta-agente responde de inmediato y transmite el progreso por streaming.

Ejemplo real de petición al API
curl -X POST localhost:8080/runs -H 'content-type: application/json' -d '{
  "workload": {"name": "rag-corporativo", "kind": "rag",
               "slo": {"concurrent_users": 16, "min_context_tokens": 8192}},
  "hardware": {"nodes": [{"node_id": "srv-b", "role": "server_b", "cpu_cores": 32,
                          "ram_gb": 256, "disk_gb": 2000,
                          "gpus": [{"name": "NVIDIA A100-SXM4-80GB", "vram_gb": 80,
                                    "memory_bandwidth_gb_s": 2039}]}]},
  "targets": [{"target_id": "srv-b", "kind": "ssh", "node_role": "server_b",
               "host": "10.0.0.11", "ssh": {"username": "deploy",
               "private_key": {"provider": "env", "key": "DEPLOY_SSH_KEY"}}}]
}'

Responde 202 de inmediato con un run_id. El progreso llega por streaming (SSE) — cerrar la conexión no interrumpe el despliegue. El informe final llega en Markdown estructurado.

Qué recibes al final

Cada corrida termina en un informe, no en una promesa. Y si quieres que se vuelva real, hay una versión que lo hace.

Incluido en cada corrida

Reporte de viabilidad y alcance

Al final de cada corrida, el meta-agente entrega un informe en Markdown con la arquitectura evaluada, el sizing calculado, lo medido con tráfico real, la desviación entre ambos y qué haría falta para llevarla a producción. Mismo criterio que usamos con nuestros clientes: mostrar lo que hay, no venderlo de más.

Sizing teórico vs. medido Evidencia literal de logs Markdown estructurado

Por qué le importa a tu empresa

Este es el motor que hace posible nuestra promesa de infraestructura propia: en vez de improvisar cuánta VRAM necesita tu RAG o tu agente, el meta-agente la calcula, la despliega y la certifica con tráfico real, sobre tus propios servidores.

¿Quieres ser de los primeros en probarlo?

Está en desarrollo activo. Si quieres acceso temprano o ver el informe técnico completo, escríbenos.