Qué agentes, grafos y evals tenemos de verdad — en los cuatro proyectos, en los ocho repos de las dos organizaciones, y en la nube. Cada número lleva el comando que lo produjo. Lo que no se pudo medir lo dice con esas palabras.
0medí y está bien1medí y está mal2NO PUDE MEDIR — el instrumento no llegó al objetoLos tres códigos de salida son la convención de la propia plataforma
(flota/cli.py). Un 2 nunca se degrada a 1: un hueco no es un defecto.
La plataforma está bien construida y se puede probar que funciona. El problema no es la calidad: es dónde está apuntada. Los 247 agentes registrados son agentes de trabajo interno. Los que hablan con clientes reales viven fuera del registro, sin examen y sin quien los mire.
Y hay grafos de verdad — pero no son los de la plataforma. Zymplo corre un
LangGraph en producción con 16 archivos de grafo y nodos como
intent_router, plan_gate, human_escalation,
verify_response y reflection. Se desplegó hoy a las 12:15 y salió
exitoso. Alarmas tiene cero. Así que la pregunta «¿tenemos agentes controlados por grafos?»
tiene dos respuestas y hay que decir las dos: sí, Zymplo, en producción, y
no, la plataforma — cuya propia cola nunca tuvo una fila. El hueco no es que falten
grafos: es que el grafo que atiende clientes y el registro que sabe exigir un examen
no se conocen.
vacio, ruidoso, complaciente, referencia. Ningún agente registrado es uno de ellosnucleo.evals correr --organismo alarmas-datos-tableros → «organismo desconocido»El agente que toca clientes no está en el registro
El agente alarmas-prod atiende los canales de WhatsApp de Alarmas. Resuelve
solo el 44,9 % y deriva a una persona el 55,1 %. No tiene ficha
ni eval.
Corrección de las 18:45: escribí «tres nodos LangGraph» y nunca lo medí.
add_node|StateGraph en toda la casa de Alarmas da 0, con el
instrumento probado contra una palabra que sí existe. Los tres nodos serían filas de una tabla
en producción, no llamadas en el código — pero eso es cita de un documento ajeno, no medición
mía, y el repo del cerebro (skn-alarmas/agente-comercial-ia) devuelve 404
con control positivo en core → 200: es falta de acceso, no ausencia.
select count(*) from ficha where nombre like '%asesor%' → 0 · like '%zychat%' → 0 · like '%chatwoot%' → 0
…en las dos instalaciones. Los seis resultados que aparecen con '%prod%' son alarmas-producto-*: falsos positivos.
El eval es un portón de nacimiento, no de despacho
El control que rechaza un agente sin examen vive sólo en nucleo/registro/registro.py,
y corre al registrarse. El despachador nunca lee el piso del eval.
Un agente que se degrada después de registrado sigue despachando igual.
grep -rn 'piso_eval' nucleo/despachador → 0 matches
Los 247 exámenes nunca vieron un modelo real
El eval en vivo corre por cron todos los días. Sus últimas cinco corridas —4, 5, 6, 7 y
8 de septiembre— dicen las tres palabras: NO PUDE MEDIR. La causa está
medida y es una sola: falta el secreto ANTHROPIC_API_KEY en el runner.
tail -5 .github/evals-en-vivo/BITACORA.tsv → 5 de 5 NO_PUDE_MEDIR
gh run view 34207084214 --log → "NO_PUDE_MEDIR · sin ANTHROPIC_API_KEY", exit 2
gh secret list -R skn-alarmas/agentes-hq → sólo LEER_ALARMAS_HQ
Tres cosas que el propio workflow ya dejaba escritas, y que corrigen la lectura fácil:
el gasto ya está autorizado desde el 4 de septiembre con tope de US$20 —un
agente por día con Haiku son ~12 llamadas, centavos—; el rojo diario en GitHub
no es un defecto, es un exit 2 que la interfaz sólo sabe pintar
de dos colores; y la deuda ya estaba anotada con dueño y fecha de revisión, el 15 de septiembre.
La credencial estuvo como secreto del repo desde el 2 de septiembre y hoy no está.
eval-en-vivo.yml líneas 17-32 · "Autorizado por Carlos el 2026-09-04" · "Dueño: Carlos (la credencial) - revisar 2026-09-15"
Diecinueve de los veintisiete vigías no se ven desde la nube — y la razón no es la que parecía
La regla de la casa pide tres cosas: que corra en la nube, que el estado
viva en la nube y que se vea desde la nube. La tercera estaba incumplida sin que se
notara: .gitignore tapa la carpeta donde los vigías escriben su veredicto, así
que el resultado moría con la corrida aunque el vigía anduviera perfecto.
Y hay una asimetría entre las dos casas que vale la pena mirar: Alarmas ya tiene quien vigile a sus vigías —un interruptor de hombre muerto que confirmó latido hoy a las 17:56— y Zymplo no. De los veinte que no se pueden mudar, cinco están atados a guiones que no viven en ningún repositorio: no hay dónde commitear el arreglo ni de dónde revertirlo. Versionarlos es el paso previo, y tiene dueño humano.
27 tareas · 5 en la nube · 2 migrables ya · 20 atadas · 19 sin veredicto visible
77 rutas /Users/cr cableadas, 57 duras · 20 arregladas · 35 esperan que su guión entre a un repo
El vigía que llevaba cuatro corridas en rojo no estaba roto: estaba avisando
Un trinquete declara cuántas cosas no se pueden medir desde la nube y sólo permite que ese número baje. Estaba en dos y pasó a cuatro, así que puso el job en rojo. La tentación es subir el techo; eso habría sido apagar el único instrumento que avisó. Se cerraron las dos causas.
La primera es la más instructiva. Un guarda tenía la ruta de la Mac escrita a mano. En la nube ese árbol no existe, así que no medía nada — pero el daño real estaba del otro lado: probado con un clon de 45 archivos contra el repo de 65, con la ruta fija examinaba 63 y con la ruta derivada 45. En la Mac tampoco medía el árbol sobre el que lo invocaban. Una corrida sobre una rama habría medido la copia de otra. Dato correcto, sujeto equivocado.
La segunda: un guarda que compara dos repositorios y en la nube sólo se clonaba uno. Él mismo decía el arreglo en su salida. Ahora el trabajo de la nube clona los dos al lado.
Y un efecto colateral que valía la pena: al apagar el vigía de la Mac, este candado empezó a gritar «el cron está muerto» — cierto sobre el archivo, engañoso sobre la capacidad, que se había mudado. Ahora tiene dos patas: si la Mac no vigila, le pregunta a la nube, que deja su rastro en el propio repositorio.
hermanos barridos por la forma: 2 de 84, los dos arreglados · el contador probado contra un guion falso con el defecto
guard-corre-igual-en-linux gana su cuarta familia · su arnés pasa de 20 a 23 controles
mutar-alarmas-candados-check (no existía): 4/4 · nube vieja → ROJO · nube fresca → verde · sin rastro → NO PUDE MEDIR
El respaldo de Alarmas se estaba apagando de a poco, y ya vuelve a publicar
No era una caída —eso se habría visto— sino una degradación, que es justo lo que cuesta ver: el 28 de agosto tenía 0 fallos y 43 éxitos; el 5 de septiembre ya iba 28 y 19; el 6 tuvo un día entero sin publicar nada; y hoy llevaba 25 fallos contra 1 éxito. El log se llena de tildes verdes y el aviso se pierde entre ellas.
La causa la escribe el propio log setenta y seis veces —«caused by another repository
pushing to the same ref»— y nadie la leyó: el guion nunca hacía
fetch. La Mac guarda cada media hora y el vigía de la nube guarda
desde su servidor; los dos escriben los mismos archivos de estado sobre la misma rama.
Probado en un clon descartable antes de tocar nada: rebase choca, merge choca en los cuatro,
y la estrategia «unir líneas» arregla dos y rompe el JSON del tercero. No
faltaba una forma de mezclar: faltaba decidir de quién son esos archivos.
Arreglado y verificado. Ahora trae lo de la nube antes de enviar, y en un conflicto gana el remoto sólo en las carpetas que el remoto escribe —la lista va escrita, no implícita. Y cuenta sus éxitos, no sus intentos: a la cuarta corrida fallida seguida el mensaje deja de ser un aviso y pasa a ser un rojo con el número adentro.
arnés mutar-respaldo-de-alarmas.sh → 19/19, dos corridas · saca las funciones del guion con sed: si las borran, se pone rojo solo
punta a punta 20:01:40 y 20:03:53 · ✅ guardados y subidos · sha remoto == sha local por ls-remote, no por el exit del envío
cron de la Mac 27 → 22 · se apagaron los 5 con gemelo VERDE medido a las 19:43 · candados-check NO se tocó (su gemelo está rojo)
Y el número que publiqué primero sobre eso estaba mal
Escribí «118 fallidos, 0 exitosos, 18 días sin publicar». El cero era mi patrón de búsqueda: busqué las palabras que yo imaginaba —push ok, publicado— y ese log no las usa. Los éxitos reales eran 374, y el último anterior a hoy fue ayer a las 23:37, no hace dieciocho días.
Es el quinto instrumento del día que devuelve un cero falso, y éste fue
mío. El arreglo del método: antes de contar, mirar qué formas de línea tiene el archivo
—sed que borre fechas y números, sort | uniq -c— y recién después
escribir el patrón. La causa raíz que sí acerté no cambia; lo que cambia es el tamaño, y el
tamaño es lo que decide si algo se mira.
Todo lo que se arregló hoy vive en un solo disco
La regla de la casa dice que ninguna capacidad puede depender de que una computadora personal esté encendida. El motor tiene seis ramas de arreglo: cuatro están publicadas y dos existen únicamente en esta Mac — y una de esas dos es la de hoy, con los seis commits del guarda de pytest, la tercera casa y el portón de despacho. La rama principal, además, va seis commits atrás del remoto.
Los otros dos repos de la casa tienen un automatismo que commitea y empuja cada media hora; el del motor no. Así que el trabajo mejor medido del día es el que menos protegido está.
git branch -r --contains 279d6fd → vacío · main local vs origin/main → 0 adelante, 6 atrás
medido 19:23 -03
Los 247 evals dan el mismo resultado porque son el mismo resultado
Esto corrige el número principal de esta lámina, que era mío. La tabla de evals tiene nueve columnas y ocho traen un solo valor para los 247 agentes: piso 57,00 · puntaje de paja 41,67 · puntaje obtenido 100,00 · VERDE · 12 casos · cero mentiras peligrosas. Lo único que cambia de fila en fila es el nombre. Eso no son 247 mediciones: es una medición repetida 247 veces.
Y el motivo está a la vista en cuanto se pregunta bien. El eval sabe correr exactamente
cuatro organismos —vacio, ruidoso,
complaciente, referencia— que son las piezas de prueba del propio
arnés. Pedirle que corra un agente real contesta «organismo desconocido».
Lo que sí es cierto, y no es poco: el arnés funciona y puede reprobar.
Lo corrí hoy: el agente complaciente sale ROJO, el vacío sale 2 sin degradarse,
la referencia sale VERDE, y el piso de ruido está publicado en 37,5. La casa tiene un examen
de verdad. Lo que no tiene es un examen tomado.
nucleo.evals tabla --instalacion alarmas --json → 128 filas · 1 valor distinto en piso/medido/obtenido/veredicto/casos/paja/motivo/mentiras · 128 en «agente»
ídem zymplo → 119 filas, mismos valores · nucleo.evals autoprueba → CONTROL POSITIVO OK
medido 19:14 -03, por mí, después de que un cosechador de grafos abandonados lo señalara
GitHub tiene 30 alertas de secretos abiertas hace 29 días, y nadie las cerró
Mientras sacaba una clave del perfil de la Mac apareció esto, que es de otro orden de
magnitud. El escaneo de secretos de GitHub está encendido y funciona: no es un
hueco de detección. Es que nadie lee lo que detecta. Las 21 de
zymplo-hq son todas del 10 de agosto —el mismo día, o sea una
fuga sola— y entre ellas hay una Anthropic Admin API Key, que es la que puede
crear y revocar a las otras.
Y hay una asimetría que importa: skn-alarmas/core tiene el escaneo
deshabilitado. Ahí no hay 0 alertas: hay 0 mediciones. Eso es un
2, no un 0.
zymplo-inc/zymplo-hq → 21 abiertas · 4 OpenAI · 3 Cloudflare · 2 Google · 1 Anthropic Admin · 1 Anthropic · 1 GitHub PAT · 1 Stripe webhook · 1 Twilio · 1 Vercel · 1 Resend · 1 LangSmith · 1 Groq · 1 xAI · 2 Google OAuth
zymplo-inc/zymplo → 9 abiertas · skn-alarmas/core → escaneo DESHABILITADO · skn-alarmas/agentes-hq → 404 para esta cuenta
medido 19:05 -03 · gh api repos/<r>/secret-scanning/alerts · push protection: enabled
Y una contraseña de producción que el escáner no marca, porque no tiene forma de clave
Dos archivos versionados de zymplo-hq llevan adentro la contraseña de Postgres
de producción: un snapshot del crontab del servidor y un script nocturno que la tiene como
valor por defecto de env.get(...). GitHub no la marca porque una
contraseña propia no tiene el prefijo reconocible de un token de proveedor.
Y acá me equivoqué yo: al ir a verificarla, mi propio redactor la dejó
pasar en claro. Buscaba password= y usuario:clave@host; no vio que el
secreto estaba como argumento posicional. El discriminador no contenía la forma contra la que
discriminaba. El redactor nuevo se prueba contra una batería que incluye justo esa forma:
4 de 4.
scripts/conversation-summary-nightly.py:35 · 01-comando-central/s1-crontab-…-2026-07-22-radar-added.txt:114
los dos versionados en zymplo-inc/zymplo-hq (privado) · medido 19:03 -03
Saqué la credencial del perfil… y después descubrí que no era la única: son 61
Una auditoría de costos la deshabilitó el 7 de mayo —«usar Max plan en su lugar»— y dejó
un unset de red de seguridad. La línea quedó comentada, pero
con el valor adentro. La borré: en su lugar quedó el rastro auditable —cuándo
vivió, cuánto medía, con qué prefijo empezaba— y ningún valor. Lo que no puedo hacer yo
es revocarla: cuatro meses en disco significa que esa clave se tira, no se reusa.
Corrección de las 19:16, y es mía. Escribí «es el único archivo, cero en
los repos». Era falso, y el motivo es el de siempre: aquel barrido corrió en segundo plano y
no devolvió una sola línea — yo leí esa nada como un cero. Rehecho con un instrumento
que arranca plantando una clave falsa y comprobando que la caza: 61 archivos
con una clave sk-ant real. El perfil sí quedó limpio (0). Los otros 61 no los
había mirado nunca.
ANTES 18:01 · ~/.zshrc línea 38 con el valor adentro (108 caracteres)
DESPUÉS 18:04 · 0 tokens largos en ~/.zshrc · sha256 del resto IDÉNTICO · zsh -n exit 0
BARRIDO BUENO 19:16 · control positivo ✅ · ~/.claude 22 · ~/Zymplo-HQ 39 · Alarmas-HQ, Agentes-HQ, Carritos-HQ, .ssh, .config, .local → 0
entre los 39 hay un .env de producción y un documento de contexto del repo
FALTA (tuyo) · revocar. Cuatro meses en disco y 61 copias significa que se tiran, no se reusan
La misma forma apareció dos veces hoy, en dos casas distintas
Un «no pude medir» degradado a «medí y está mal». En el guarda que revisa antes de
subir código, porque pytest tiene seis salidas y las sacaba a todas por la puerta
del rojo. Y en el medidor del corpus de Alarmas, que devolvía 1 cuando el fallo
era «no llegué al host» —contra su propia cabecera, que declara 2 para eso— y
cuyo control negativo cantaba verde justo cuando no había conexión, porque un vacío
por «la tabla no existe» y uno por «no hay ssh» escriben el mismo texto.
Los dos están arreglados y los dos tienen ahora un arnés que muerde: 28 de 28 y 8 de 8,
con el defecto reinyectado para probar que el examen puede fallar. Lo que importa no es el
par: es que la casa tiene un alfabeto de tres letras y el 2 se le cae al
1 en los bordes, que es donde nadie mira.
mutar-el-alfabeto-de-pytest.sh → 28 pasaron, 0 fallaron · con el guarda roto: el 5 vuelve a salir 1
mutar-corpus-calidad-check.sh → 8/8, corrido por mí, no por su autor · las dos mutaciones muerden
El grafo que armamos para esta auditoría terminó… y nunca sintetizó
Cincuenta agentes, treinta y nueve minutos, veintitrés bloques encargados. Volvieron
22 con material y uno vacío. Y después, nada: el campo de síntesis quedó en
null y el de refutación en cero. Junta y no concluye — que es justo la fase que le
daba valor a las otras cuarenta y nueve. Esta lámina existe porque la escribí en paralelo en
vez de esperarlo.
wf_8bcdf965 · status completed · agentCount 50 · 39,3 min
result['inventario'] 15 · result['investigacion'] 8 · result['sintesis'] None · result['destructores'] 0
Nadie aprobó nunca nada por el portón
Los seis portones frenan los 22 intentos de evasión y está probado por mutación. Pero el libro donde se anota quién aprobó y cuándo no existe en ningún lado del disco: los portones nunca se usaron en una operación real.
find /Users/cr -name 'porton.jsonl' → (vacío) · nucleo.portones.cli verificar → NO_PUDE_MEDIR
Nada de esto es una promesa: cada una tiene un arnés que puede salir en rojo, y se comprobó que discrimina rompiéndolo a propósito.
| Qué | Resultado | Cómo se probó que el control sirve | Estado |
|---|---|---|---|
| El eval puede reprobar | complaciente ROJO, referencia VERDE | Las 10 pajas salen no-verde; el banco tiene 16 casos y 7 son trampas donde la respuesta correcta es «no se puede medir» | exit 0 |
| Los portones frenan | 22 de 22 evasiones bloqueadas | Un portón inerte de control deja pasar las 22 — el piso publicado al lado; 5 sabotajes dirigidos cuelan al menos 1 cada uno | exit 0 |
| El traductor de grafos | 16 de 16 mutaciones cazadas | Cada mutación la caza su propia prueba; 0 escaparon | exit 0 |
| El aislamiento entre casas | 48 caminos examinados, 0 cruces | El arnés muta el candado: 3 cruces dan exit 1, 3 huecos dan exit 2, 3 legítimos dan exit 0 | exit 0 |
| El bucle de aprendizaje | reproduce las 9 correcciones reales | 47 tests verdes sobre el corpus de Alarmas | exit 0 |
| La suite completa | 1448 pasan, 0 fallan | Los 2 rojos de la primera corrida no se reprodujeron: eran inestables, no un defecto | exit 0 |
Sólo nodos y flechas medidos. Lo punteado es lo que está construido pero nunca se usó.
flowchart TB
subgraph PLAT["PLATAFORMA · Agentes-HQ · 14 modulos · 24.900 lineas"]
direction TB
REG["registro
247 fichas con eval"]
EVL["evals
banco de 16 casos, 7 trampas"]
PORT["portones
6 familias + autoproteccion"]
PLAN["planificador
DAG con 7 reglas"]
DESP["despachador + obrero"]
APR["aprendizaje
9 correcciones"]
COLA[("cola
0 filas")]
REG -->|"al dar de alta"| EVL
PLAN -.->|"nunca sembro"| COLA
COLA -.->|"nunca tomo"| DESP
DESP --> PORT
APR --> EVL
end
subgraph ZY["CASA ZYMPLO"]
ZR["registro zymplo
119 agentes · 17 dir / 17 sup / 85 trab"]
ZM["app movil
172 rutas, 3 tiendas"]
ZAF["autofix.zymplo.com
Fase 1 en produccion"]
ZAG["agents.zymplo.com"]
end
subgraph AL["CASA ALARMAS"]
AR["registro alarmas
128 agentes · 18 dir / 18 sup / 92 trab"]
APROD["asesor-ia.zymplo.com
repo 404 para esta cuenta
2.831 charlas / 8 dias"]
ACHAT["crm.alarmas.com.py
Chatwoot"]
ATEST["agentic-testing
4 agentes"]
end
REG --> ZR
REG --> AR
ACHAT --> APROD
APROD -.->|"SIN EVAL"| REG
ATEST -.->|"SIN EVAL"| REG
ZAF --> ZAG
classDef vivo fill:#E3F3F0,stroke:#0B7C71,stroke-width:2px,color:#0C1412
classDef muerto fill:#FBF0DC,stroke:#9A5B06,stroke-width:2px,stroke-dasharray:5 4,color:#0C1412
classDef fuera fill:#FBE9E8,stroke:#B4211C,stroke-width:2px,color:#0C1412
class REG,EVL,PORT,APR,ZR,AR,ZM,ZAF,ZAG,ACHAT vivo
class PLAN,DESP,COLA muerto
class APROD,ATEST fuera
Verde: medido y en uso. Ámbar punteado: construido y probado, nunca ejecutó una tarea real. Rojo: agente vivo en producción, fuera del registro y sin eval.
La jerarquía tiene tres rangos y para arriba se termina. No hay presidente ni mega-director
en el código: 0 coincidencias. Los 17 directores de Zymplo y los 18 de Alarmas
tienen reporta_a = NULL — son 35 raíces paralelas, no un árbol.
grep -rln -iE 'presidente|mega|director de directores|\bceo\b' nucleo/jerarquia flota/ → 0
select nombre,reporta_a from ficha where rango='director' → 17 de 17 y 18 de 18 en NULL
Tres cambios estructurales, no un sistema nuevo. Todo lo verde ya existe y está probado.
flowchart TB PRES["PRESIDENTE
un solo vertice"] MDZ["mega-director ZYMPLO"] MDA["mega-director ALARMAS"] PRES --> MDZ PRES --> MDA subgraph NUEVO["LO QUE FALTA"] direction TB PORTAL["porton de DESPACHO
lee piso_eval antes de lanzar"] LIBRO["porton.jsonl
libro de aprobaciones"] VIVO["eval en vivo con su secreto"] RADAR["radar de calidad encendido"] end subgraph EXISTE["LO QUE YA ESTA"] direction TB REG2["registro
portan de nacimiento"] PLAN2["planificador DAG"] COLA2[("cola")] OBR["obrero"] APR2["bucle de aprendizaje"] end MDZ --> DIRZ["17 directores"] MDA --> DIRA["18 directores"] DIRZ --> SUPZ["17 supervisores"] DIRA --> SUPA["18 supervisores"] SUPZ --> TRAZ["85 trabajadores"] SUPA --> TRAA["92 trabajadores"] PLAN2 -->|"siembra"| COLA2 COLA2 --> OBR OBR --> PORTAL PORTAL -->|"consulta"| REG2 PORTAL --> LIBRO VIVO -->|"baja el piso si falla"| REG2 RADAR -->|"caso real que salio mal"| APR2 APR2 -->|"regla + candado + eval"| REG2 PROD["agentes de produccion
el comercial + agentic-testing 4"] -->|"registrar"| REG2 classDef existe fill:#E3F3F0,stroke:#0B7C71,stroke-width:2px,color:#0C1412 classDef nuevo fill:#FBF0DC,stroke:#9A5B06,stroke-width:2.5px,color:#0C1412 classDef jer fill:#F1F5F4,stroke:#6B807B,stroke-width:1.5px,color:#0C1412 class REG2,PLAN2,COLA2,OBR,APR2 existe class PORTAL,LIBRO,VIVO,RADAR,PRES,MDZ,MDA nuevo class DIRZ,DIRA,SUPZ,SUPA,TRAZ,TRAA,PROD jer
Ámbar: lo que hay que construir. Verde: ya existe y está probado por mutación. Gris: la jerarquía que ya está en la tabla, más los agentes de producción que hay que meter en ella.
El enfoque tiene una sola idea: lo que ya está probado no se toca; lo que toca clientes entra al registro; nada nuevo entra sin un eval que pueda reprobarlo.
import crewai → No module named 'crewai'. No está instalado.83 capacidades leídas de documentación oficial, 8 proveedores. Sólo se listan las filas donde hay un hueco real o una ventaja real.
| Capacidad | Ellos | Nosotros hoy | Veredicto |
|---|---|---|---|
| Eval que bloquea el merge | Google ADK: adk conformance compara contra un baseline grabadoadk.dev/evaluate/ |
Los evals corren 4×/día pero no bloquean nadaevals.yml cron '13 1,7,13,19 * * *' | hueco |
| Eval de trayectoria | Microsoft: 11 evaluadores, uno mide eficiencia de navegación con 3 modos de matchinglearn.microsoft.com · preview | Evaluamos la respuesta, no el caminonucleo/evals/banco_neutral.py | hueco |
| Portón humano en el grafo | CrewAI @human_feedback, Microsoft RequestPort, xAI cede la sesión enteradocs.crewai.com/en/concepts/flows |
6 familias probadas 22/22, pero 0 aprobaciones reales registradasfind -name porton.jsonl → vacío | a medias |
| Agente-a-agente (A2A) | Google donó el protocolo a la Linux Foundation; CrewAI delega en runtime a agentes remotosa2a-protocol.org | No lo hablamos0 menciones en adaptadores/ | hueco |
| Despliegue gestionado | Managed Agents, AgentCore Runtime, CrewAI AMP, Foundry4 de 8 lo ofrecen | Runners propios con cron; el despachador nunca corrió en un servidor7 workflows en [self-hosted, agentes-hq] | a medias |
| Enjambre auto-organizado | Kimi K2.5: hasta 100 sub-agentes sin grafo predefinido; xAI empaqueta 4→16 como modelokimi.ai/blog/kimi-k2-5 | Zymplo corre un LangGraph vivo (16 archivos, nodos intent_router / plan_gate / human_escalation), desplegado hoy 12:15. El grafo de la plataforma está declarado y sin ejecutardeploy-prod-langgraph → success · cola de la plataforma: 0 filas |
a medias |
| Eval que puede reprobar | Google lo declara; el resto documenta scoring sin control positivo publicado | Un agente complaciente sale ROJO, 10 pajas reprobadas, 7 trampas de 16 casosnucleo.evals autoprueba → exit 0 | mejores |
| Portones probados por mutación | Ninguno de los 8 publica un arnés que ataque sus propios portones | 22 ataques, 0 pasan, con piso inerte publicado al ladomutar-portones.py → VERDE, piso 22 | mejores |
| Aislamiento entre clientes | Ninguno lo ofrece como candado probado por mutación | Ley 1 en el validador del DAG: una dependencia que cruza casas es ROJOplanificador.py · regla 4 | mejores |
| Aprendizaje del sistema | Sólo 4 capacidades en toda la industria; Microsoft y AWS «early access», Kimi «anunciado» | Bucle corrección→forma→barrido→regla→candado→eval, con 9 casos reales reproducidos47 tests verdes | mejores |
Dónde estamos por delante, y por qué importa
La categoría más flaca de toda la industria es aprendizaje y auto-mejora: 4 capacidades entre las 83 leídas, y las cuatro en early-access o sólo anunciadas. Es exactamente donde tenemos un bucle que corre y reproduce nueve correcciones reales.
Una fuente cayó por su propio control
El investigador de Kimi citó páginas de platform.kimi.ai como fuente. Un
refutador probó una URL inventada de control y obtuvo el mismo redirect 308 al mismo
destino que las páginas «reales». Esas citas no valen y quedan marcadas como tales.
El orden importa: cada paso hace posible el siguiente. El primero es el único que hoy bloquea a todos los demás.
| # | Qué | Dónde | Cómo se sabe que salió bien | Necesita |
|---|---|---|---|---|
| 1 | Reponer la credencial del eval en vivo El gasto ya está autorizado desde el 4 sep, tope US$20. Lo pongo yo con gh secret set: sólo hace falta que me pases el valor | Agentes-HQ | SIN EFECTO por decisión del dueño, 19:54. La consecuencia queda dicha una vez y no se insiste: mientras esa clave no se rote, eval-en-vivo.yml sigue dando 2 todas las noches y los evals nunca ven un modelo real. Es un hueco declarado, con dueño, no un defecto | sin efecto |
| 1b | Borrar la clave del perfil de la Mac Comentada pero con el valor adentro desde el 7 mayo | tu Mac | HECHO 18:04 · 0 tokens en ~/.zshrc · resto del archivo idéntico (sha256) · zsh -n pasa. Falta revocarla en la consola: eso es tuyo | hecho |
| 2 | Registrar el agente de producción Bloqueado, y por un motivo medido: el repo del cerebro devuelve 404 a esta cuenta. Sin ver el código, cualquier eval aprueba a cualquiera | Alarmas | Medido 18:42 · gh api repos/skn-alarmas/agente-comercial-ia → 404 · control positivo core → 200 ⇒ acceso, no ausencia. El registro quedó en 128/128: no se inventó ninguna ficha, y eso es el resultado correcto | acceso |
| 3 | Encender el radar de calidad Ya no es «hoy analizó 0 de 0»: el radar es la tabla quality_ai_reviews (88 columnas, 0 filas) y nunca estuvo prendido — enabled=false por defecto desde la migración del 11 ago. Encenderlo es plata y producción, y el interruptor no es mío | Alarmas | Medido 18:27 · dos caminos independientes dicen lo mismo: fuentes.tsv fila 38 y ciclo.module.ts:98 («el Radar nunca estuvo prendido»). El analizador local SÍ sabe reprobar: veredicto REPROBADO con dos vetos, y sigue aprobando el bueno | portón |
| 4 | El portón lee el piso del eval antes de despachar Ya no mira sólo al nacer. Y la abstracción que hacía falta ya existía y nadie la llamaba: registro.py:348 verificar_antes_de_despachar() | plataforma | HECHO · ficha degradada → ROJO, 0 lanzados, 1 denegado, en cuarentena · ficha sana → VERDE, 1 lanzado · guarda saboteado → 9 pruebas en rojo. Arnés 6/6 corrido por mí a las 19:22, y la suite entera 1537 pasaron / 0 fallaron, también corrida por mí. Un NO_PUDE_MEDIR deniega pero no cuarentena: castigar a la ficha sería acusarla de algo que nadie midió | hecho |
| 5 | Sembrar la primera tarea real por el grafo La cola nunca tuvo una fila | plataforma | select count(*) from tarea > 0, con plan_id no nulo, y el obrero la cierra | yo |
| 6 | Registrar los 4 agentes de agentic-testing Repo público, sin evals | Alarmas | 4 EVAL.md nuevos, los 4 VERDE en la tabla, 0 aprueban a la paja | yo |
| 7 | Abrir la casa de Carritos La plataforma prometía desde el día uno que la tercera empresa no costaría una línea de código. Se cobró: 42 líneas de TOML, cero de Python | Carritos | HECHO 18:29 · antes empresa=None («ninguna empresa reconoció este proyecto») · después carritos 23 contra 0 · exit 0 en 1,48 s, 0 decisiones humanas · y los tres controles idénticos: Zymplo 26·2, Alarmas 26·0, el motor sigue siendo de Alarmas 10·0 | hecho |
| 8 | Sacar los vigías de tu Mac 27 tareas de cron que dependen de que esté prendida (12 Zymplo · 9 Alarmas · 6 propias) | los dos | MEDIDO 19:05 · las 27 quedaron clasificadas: 5 ya corren en la nube (workflow de Alarmas, success hoy 17:56) · 2 listas para apretar el botón (tiendas y PRs, probadas fuera de la Mac con control del detector: 0 rutas /Users/cr con la variable puesta, 9 sin ella) · 20 atadas a esta Mac con el motivo escrito una por una. Falta el push para que corra verde una vez; recién ahí se dan de baja las 2 del cron | yo |
| Proyecto | Agentes con eval | Grafos corridos | Agentes en producción | Qué le falta |
|---|---|---|---|---|
| Zymplo app de 172 rutas, 3 tiendas | 119 | 215 | AutoFix Fase 1tablero congelado hace 42 días | corpus de aprendizaje propio; hoy sólo Alarmas tiene uno |
| Alarmas ~49.000 clientes, 14 servidores | 128 | 89 | el agente comercial + agentic-testing 4los 5 sin eval | conseguir lectura del repo del cerebro, registrar los 4 de agentic-testing |
| Agentes-HQ la plataforma misma | 0 | 0 | — | no se autohospeda: la casa del zapatero |
| Carritos casa abierta hoy 18:29 · traspasada a otra persona el 5 sep | 0 | 0 | — | todo: falta el archivo de señales para que el instalador la reconozca |
Buscados por tres caminos independientes —disco, DNS y GitHub en tres organizaciones— y los tres dieron cero: