Arquitectura: modelo congelado, herramientas reales, memoria viva
Un modelo frontier (Claude-Sonnet-4, Claude-Opus-4.6 o Qwen3.6-27B) actúa como agente base y controla equivalentes de Photoshop, Illustrator e InDesign a través de más de 230 herramientas [https://arxiv.org/abs/2609.22086v1]. Cada herramienta mapea una operación concreta: crear capas, aplicar máscaras, importar assets, ajustar tipografía, renderizar estados intermedios. El agente recibe un brief, recupera skills relevantes, selecciona un subconjunto de herramientas y ejecuta una cadena de operaciones hasta producir la imagen final renderizada.
Una colección de SKILL.md conforma el banco de habilidades: guías en lenguaje natural que describen procedimientos reutilizables —qué subtareas cubren, qué herramientas invocar y en qué orden, modos de fallo comunes, ramas condicionales—. Una skill está entre una llamada atómica y una trayectoria completa: lo bastante específica para guiar la ejecución, lo bastante general para transferir entre briefs.
Antes de ejecutar, un paso de recuperación consulta el banco con el brief y la lista de herramientas, inyecta los playbooks top-k (k=3 por defecto) en el contexto del modelo y reduce el catálogo de herramientas al conjunto relevante. Desactivar la recuperación recupera el agente original, proporcionando un control natural para medir la mejora.
Cuatro roles corren en el bucle offline: un Prompter que plantea briefs (de tráfico real de usuarios o variantes generadas por LLM), un Solver (el agente), un Grader multimodal que puntúa cada imagen y explica por qué fallan los requisitos no cumplidos, y un Reflector que convierte esos fallos en ediciones dirigidas de los SKILL.md. Solo cambian los SKILL.md; todo lo demás permanece fijo.
Ensanchamiento: descubrir skills que faltan
Subtareas recurrentes que la biblioteca actual no cubre son identificadas por el ensanchamiento. Para cada trayectoria, un LLM congelado extrae y canoniza las subtareas realmente realizadas. Una subtarea cuenta como "descubierta" si ninguna skill recuperada la atiende —porque la recuperación no devolvió nada o porque las skills cubren otra parte del brief—. Las subtareas asociadas a una skill culpada de mal resultado también cuentan como descubiertas.
Las subtareas descubiertas se acumulan en un pool de cobertura persistente indexado por etiqueta canónica. Cuando una etiqueta alcanza k_min = 3 ocurrencias, un LLM congelado destila esos casos en una skill candidata. La candidata solo entra al banco si pasa la puerta de replay contra el agente sin skills. Si es rechazada, sus ocurrencias quedan en el pool para acumular más evidencia en rondas futuras.
Deliberadamente conservador, el umbral de tres responde a que una skill nacida de un solo fallo podría ser artefacto de mala recuperación de assets o un edge case aislado. Exigir tres ocurrencias asegura que el hueco sea sistémico, no incidental. Los autores verifican que las skills acuñadas no son redundantes con el banco semilla: su distancia de embedding al vecino más cercano supera el espaciado interno del banco inicial (0.215 vs 0.158 distancia coseno mediana, Mann-Whitney p < 10⁻⁸) [https://www.simpleprog.com/papers/designer-rsi-evolving-procedural-memory-from-user-traffic-for-agentic-581ce921].
Profundización: endurecer skills que ya existen
La profundización revisa skills que fallan repetidamente. El mecanismo es asimétrico por diseño: la selección es barata y permisiva; la puerta de replay decide qué se despliega.
Cada trayectoria registra qué skills recuperó. Una trayectoria por debajo del umbral de éxito (s_j < 0.6) cuenta como fallo contra todas las skills que recuperó. El Reflector selecciona toda skill cuyo contador de fallos alcance un umbral (por defecto 2), priorizando las que más fallan. Esta priorización es heurística, no filtro de calidad.
Para cada skill seleccionada, el Reflector recibe: el brief, los resultados por requisito y racionales "por qué falla", el SKILL.md actual, y un conjunto contrastivo de llamadas exitosas de esa misma skill en tareas similares —secuencias de herramientas, waypoints intermedios y tokens de razonamiento que funcionaron—. Las ejecuciones exitosas sirven como baseline de no-regresión; las racionales de fallo marcan qué mejorar. El Reflector razona sobre una divergencia concreta éxito-fallo, no solo sobre texto de error.
Emite una edición dirigida nombrando sección y cambio. Si reescrituras dirigidas repetidas fallan la puerta, escala a reescritura mayor de toda la skill. Reescrituras rechazadas disparan un ciclo opcional de exploración que prueba los prompts fallantes con y sin skills y destila hacia el brazo que tuvo éxito, decidiendo actualizar, borrar o mantener —donde mantener reenvía los registros inmejorables al pool de cobertura del ensanchamiento.
La puerta de replay: admisión conservadora bajo ruido
Tanto ensanchamiento como profundización proponen cambios; una única puerta decide cuáles se despliegan. La puerta ataca dos fuentes de confusión que hacen poco fiable la detección ingenua de mejora.
Primero, la puntuación absoluta del Grader VLM para una misma imagen deriva entre corridas. "Aceptar si subió la media" confunde deriva del juez con mejora y admite regresiones. La puerta nunca usa puntuaciones absolutas.
Segundo, los resultados dependen de más que la skill: la recuperación de assets y otro estado upstream pueden diferir entre brazos, permitiendo que una candidata gane solo porque recibió mejores inputs.
Recurre la puerta a matched replay. Para cada cambio propuesto, muestrea prompts que ejercitan la skill y genera varios contextos por prompt, cada uno con assets y estado upstream distintos. Cada contexto se congela y se re-ejecuta en lote bajo ambos brazos: candidata vs. incumbente (para reescritura) o vs. agente sin skills (para acuñación). Las salidas se juzgan pairwise con aleatorización de orden, de modo que dentro de cada contexto la única diferencia bajo test es la condición de skill. Un prompt se gana solo si la candidata gana la mayoría de sus contextos, evitando que una gran ganancia en uno enmascare pérdidas en otros.
Un cambio se despliega solo si no pierde ningún prompt y gana al menos uno: (∃ prompt ganado) ∧ (¬∃ prompt perdido). Es un criterio asimétrico: fácil de rechazar (cualquier regresión lo mata), difícil de aceptar (debe ganar en al menos uno sin perder nunca). Esta asimetría refleja la realidad operativa: las regresiones en producción son mucho más costosas que mejoras perdidas.
Resultados: la combinación supera a cada parte por separado
Sobre 1,406 briefs no solapados de tráfico real y variantes LLM corrió cinco rondas el sistema, produciendo 1,869 trayectorias calificadas sin etiquetas humanas. El banco creció de 76 skills semilla (destiladas de documentación interna) a 139 skills [https://arxiv.org/abs/2609.22086v1].
Un patrón predecible sigue la dinámica. Ronda 1 dominada por reparación: 39 de 59 reescrituras y 44 de 101 acuñaciones pasan la puerta. El ensanchamiento rezaga porque los huecos deben recurrir en k_min requests antes de acuñar. La acuñación pica en rondas 2 y 3 (22/46 y 26/40 comprometidas), llevando el banco de 77 a 124. Ronda 4 acuña mucho pero muchas skills son v1, nunca revisadas, y fallan en requests fuera de su cluster origen. Ronda 5 invierte la mezcla: 21 reescrituras y solo 4 acuñaciones, volviéndose la ronda más fuerte en todo umbral.
No es monótona la trayectoria. Ronda 4 cae por debajo del agente sin skills en umbrales de completitud < 0.3, mientras retiene ganancias en el extremo alto. Es el trade-off cobertura-fiabilidad en acción: acuñar expande cobertura pero carece inicialmente de verificación multi-trial; reescribir convierte cobertura en fiabilidad. Los dos mecanismos son complementarios, no redundantes.
En benchmark interno (200 briefs humanos held-out, fijos en todas las rondas, disjuntos de datos de evolución), el banco evolucionado sube performance en esencialmente todos los umbrales. Respecto a sin skills, ronda 5 eleva la fracción de briefs con completitud ≥ 0.5 de 86% a 93%, ≥ 0.9 de 43% a 56%, y exactamente 1.0 de 24% a 32%. La mayor mejora: +13 puntos porcentuales en el umbral 0.9.
En benchmarks generales de texto-a-imagen, los resultados son fuertes en múltiples backbones congelados. Claude-Sonnet-4 ve éxito de ejecución GenEval2 saltar de 72.7% a 99.3%, con calidad de generación subiendo +11.99 puntos. DPG-Bench sube de 82.7% a 100%. Mejora media de calidad en los cuatro benchmarks generales: +7.70 puntos para Sonnet-4 y +9.67 para Qwen3.6-27B [https://arxiv.org/abs/2609.22086v1].
En benchmarks especializados de diseño gráfico juzgados pairwise por GPT-5.4 en comparaciones ciegas a dos órdenes, el agente Evolve alcanza 61.8% y 67.6% de win rate global contra el agente sin skills en Claude-Sonnet-4 y Claude-Opus-4.6 respectivamente. Los márgenes son mayores en CreatiDesign (68.1% y 71.7%) y OpenCOLE (66.0% y 64.0%), que involucran planificación multi-paso y restricciones de layout.
Aísla los dos mecanismos el estudio de ablación. En 200 briefs held-out, ensanchamiento solo alcanza 49.4% win rate, profundización solo 48.6%, pero su combinación llega a 58.5% (p = 0.025) [https://arxiv.org/abs/2609.22086v1]. La ganancia superaditiva (+3.85 puntos de completitud sobre cold start) refleja acoplamiento del bucle: skills acuñadas requieren descripciones de recuperación refinadas para surgir, mientras que reescribir reencamina fallos inarreglables al pool de huecos para futura acuñación.
Latencia y costo: overhead controlado
Añade ~28% tokens de prompt sobre el agente base la recuperación de skills. Pero la evolución no añade costo marginal de tokens. Con top-k (k=3), Evolve usa menos tokens de prompt y salida que el banco cold-start (436.6k/5167 vs 445.2k/5298), consistente con ejecución más directa y menos reintentos correctivos. Overhead medio de latencia wall-clock: 3.4% a 6.2% entre backbones, y en algunos casos Evolve es más rápido (113 a 82 segundos en DPG-Bench para Sonnet-4), porque el agente guiado por skills comete menos errores.
Límites declarados
Los autores son francos sobre lo que el enfoque no resuelve. Una skill en lenguaje natural puede describir un procedimiento preferido, pero la recuperación sola no garantiza que el modelo la siga cuando tiene una estrategia por defecto fuerte. El modelo puede ignorar el playbook y caer en su distribución de entrenamiento. Operaciones geométricas finas siguen limitadas por percepción del modelo y verificación automática: alineación sub-píxel, espaciado preciso, grading colorimétrico exacto son duros para evaluadores VLM.
Procedimientos largos pierden fidelidad conforme se acumulan instrucciones en muchos pasos de ejecución. Un procedimiento de 30 pasos es más difícil de seguir fiablemente que uno de 5, y el modelo puede saltar u ordenar pasos pese al playbook. La puerta de replay es local a los casos evaluados: rechazar regresiones observadas en el set de replay no garantiza mejora monótona sobre toda la distribución de tráfico de usuarios. También hay problema de cold-start: el banco semilla de 76 skills vino de documentación interna, no de tráfico. Si la documentación es incompleta o desactualizada, la cobertura inicial es limitada, y el ensanchamiento requiere tres ocurrencias antes de acuñar, así que las primeras rondas son lentas.
Qué significa para empresas en Latinoamérica
Para compañías en la región —agencias de diseño, equipos de marketing, e-commerce, medios— la lección práctica es directa: la memoria procedimental es una alternativa viable al fine-tuning para adaptación continua de agentes, especialmente cuando no se pueden o no se quieren actualizar pesos de modelo.
Tres factores la hacen relevante en LatAm:
1. Funciona con APIs hospedadas. No hace falta clúster de GPUs, ni acceso a pesos, ni pipeline de MLOps. El modelo sigue siendo una llamada a Anthropic, OpenAI o proveedores locales; la capa que aprende vive en tu infraestructura, versionada en Git, auditable y portable.
2. Cero etiquetas humanas. El bucle usa tráfico real de usuarios (briefs reales o aumentados) y un grader automático. En contextos donde etiquetar datos de diseño es caro y subjetivo, esto reduce la barrera de entrada drásticamente.
3. Composición de expertise local. El banco semilla puede partir de documentación interna, guías de marca, plantillas aprobadas. El ensanchamiento captura patrones recurrentes de tus clientes; la profundización endurece los flujos que tu equipo ya usa. El conocimiento de diseño de tu organización se codifica en skills, no en pesos de modelo opacos.
Resulta predecible el costo operativo: overhead de latencia bajo, tokens netos menores por ejecución más eficiente, y un ciclo de evolución que puede correr nocturnamente sobre el tráfico del día. Para equipos que ya pagan suscripciones de Creative Cloud y APIs de modelos, la capa de memoria procedimental es una inversión de ingeniería —no de investigación— con retorno medible en completitud de briefs y reducción de re-trabajo.
Advierte la operación: la puerta de replay es tan buena como el grader. Si tu evaluador automático no captura criterios de marca sutiles, la puerta dejará pasar skills que "ganan" en métrica pero fallan en juicio humano. Un grillete humano en el loop de admisión (revisar skills candidatas antes de merge) mitiga el riesgo sin romper la automatización.
No resuelve el diseño generativo de un shot el paper. Resuelve la adaptación incremental de un agente que ya sabe operar herramientas profesionales. Para la mayoría de equipos en LatAm que no entrenan modelos propios, ese es el problema correcto.
