# Cuando el agente reescribe sus propias skills: autonomía sin change control

> Cuando un agente modifica sus skills, prompts o herramientas, la mejora deja de ser configuración y se convierte en un cambio de software que exige pruebas y reversión.

- Author: Viktor Berthelius (BRTHLS)
- Published: 2026-10-15
- Category: automation aiops
- Tags: self-improving-agents, agent-skills, change-control, evals
- Language: es
- Canonical: https://www.brthls.com/magazine/cuando-agente-reescribe-skills-autonomia-change-control-es
- Source: BRTHLS Magazine — https://www.brthls.com

---

## Problema

Una skill parece un documento: instrucciones, ejemplos y quizá una referencia a herramientas. En ejecución, se comporta como código. Cambia qué contexto lee el agente, qué acciones considera posibles, cómo interpreta una petición y qué resultado declara correcto.

El riesgo aumenta cuando el propio agente puede modificar esa capa. Una corrección local puede mejorar una tarea y degradar otras; una nueva herramienta puede ampliar capacidad y también autoridad; un prompt más agresivo puede elevar una métrica mientras oculta más incertidumbre. Llamarlo «aprendizaje» no elimina el hecho operativo: algo que decide comportamiento ha cambiado.

La investigación de la [Darwin Gödel Machine](https://arxiv.org/html/2505.22954v3) hace visible esta frontera. El sistema modifica su propio repositorio, evalúa las variantes y conserva un archivo de agentes derivados. No presupone que cada cambio sea beneficioso: lo somete a evidencia empírica.

## Tesis

Un agente no debe reescribir en producción la misma skill que está usando para decidir. La autonomía útil separa propuesta, evaluación y promoción.

La skill, el prompt, el harness y el registro de herramientas forman parte del plano de control. Si el agente puede alterarlos, la empresa necesita tratarlos como una release: diff legible, versión, entorno aislado, evals representativas, aprobación proporcional al riesgo y rollback probado.

La idea no es bloquear la mejora automática. Es impedir que el sistema sea a la vez autor del cambio, único evaluador y autoridad de despliegue. Esa concentración convierte una regresión en política activa antes de que nadie pueda verla.

## Framework

El cambio seguro necesita separar cinco objetos que suelen mezclarse:

| Objeto | Qué debe conservarse | Gate de promoción |
| --- | --- | --- |
| intención | problema que intenta corregir | hipótesis concreta |
| artefacto | skill, prompt, código o herramientas | diff revisable |
| autoridad | datos y acciones alcanzables | permisos no ampliados o aprobación explícita |
| evaluación | tareas, fallos y casos límite | mejora sin regresiones críticas |
| release | versión que entra en operación | canary y rollback disponibles |

La Darwin Gödel Machine aporta una decisión útil: no sustituye la prueba por la confianza en quien genera. Alterna modificación y evaluación, conserva variantes y ejecuta código generado dentro de un entorno controlado. Su [repositorio oficial](https://github.com/jennyzzt/dgm) advierte además de que ejecutar código producido por modelos puede ser destructivo y documenta Docker, pruebas, logs y estructura de herramientas.

En empresa, el benchmark genérico debe transformarse en una cartera local de aceptación. Una skill comercial se prueba con permisos realesistas, clientes duplicados, datos incompletos y negativas. Una skill de código se prueba con repositorios representativos, tests adversos y límites de escritura. Una skill creativa se prueba con activos protegidos, claims prohibidos y excepciones de marca.

El archivo de variantes también importa. «Última versión» no es suficiente cuando una mejora en un segmento empeora otro. Conservar linaje, diff, resultados y entorno permite elegir una rama adecuada, comparar comportamiento y volver a una versión conocida.

## Por qué importa ahora

Los agentes ya consumen plugins y skills como dependencias reutilizables. El siguiente paso lógico es que propongan ajustes a partir de trazas, errores y resultados. Eso acorta el ciclo de mejora, pero también desplaza el cambio desde el backlog humano hacia el runtime.

La pregunta deja de ser si el agente sabe editar un archivo. Pasa a ser quién define la función objetivo. Optimizar velocidad puede reducir comprobaciones. Optimizar tasa de cierre puede endurecer mensajes. Optimizar tests superados puede favorecer casos conocidos. Una métrica nunca representa por sí sola todo el contrato operativo.

Por eso las evals deben contener invariantes, no solo outcomes. El agente puede buscar una solución nueva, pero no puede degradar privacidad, trazabilidad, accesibilidad o reversibilidad para conseguirla. Esos límites viven fuera de la superficie que el propio agente modifica.

## Anti-ejemplo

Un agente detecta que una herramienta falla al consultar el CRM. Reescribe su skill para reintentar con más amplitud, ejecuta un caso de prueba satisfactorio y promueve el cambio. El resultado parece mejor, pero la nueva instrucción consulta más registros, duplica efectos ante timeouts y convierte un fallo recuperable en exposición de datos.

El error no fue permitir que el agente propusiera una mejora. Fue aceptar una prueba estrecha como autorización de release. La misma entidad cambió el comportamiento, eligió el test y declaró el éxito.

Tampoco basta con guardar el texto anterior. Si cambian permisos, dependencias o formato de estado, restaurar una skill no restaura necesariamente el sistema. El rollback debe incluir la configuración y las migraciones que acompañaron al cambio.

## Protocolo (3 pasos)

1. **Aísla la propuesta.** El agente trabaja en una rama o artefacto inmutable y entrega intención, diff, permisos afectados y riesgos esperados.
2. **Evalúa la frontera.** Ejecuta casos normales, fallos, negativas e invariantes con datos y herramientas representativos, sin credenciales de producción.
3. **Promueve con salida.** Despliega primero sobre tráfico limitado, observa outcomes y conserva una reversión completa a la última versión aceptada.

| Momento | Evidencia mínima | Decisión humana |
| --- | --- | --- |
| propuesta | diff y justificación | merece evaluación |
| evaluación | resultados y regresiones | puede entrar en canary |
| operación | outcome y trazas | promover, corregir o revertir |

## Relacionado

- [Plugins para agentes: empaquetar capacidad exige un contrato verificable](/magazine/plugins-agentes-contrato-capacidades-es)
- [Skill Card: el SBOM de capacidades para agentes](/magazine/skill-card-sbom-capacidades-agente-es)
- [Eval Flywheel: los agentes de producción no se arreglan con prompts, se arreglan con casos](/magazine/eval-flywheel-agentes-produccion-no-se-arreglan-con-prompts-es)

## Fuentes consultadas

- [Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents](https://arxiv.org/html/2505.22954v3)
- [Repositorio oficial de Darwin Gödel Machine](https://github.com/jennyzzt/dgm)

## Próximo paso

Elige una skill que hoy pueda actualizarse sin release formal. Separa propuesta, eval y promoción, y prueba una reversión completa. Si el agente puede cambiar su criterio sin dejar diff, versión y salida, todavía no está aprendiendo de forma gobernable: está desplegando política sin control.

## Lecturas conectadas

- [Skill Card: el SBOM de capacidades para agentes](https://www.brthls.com/magazine/skill-card-sbom-capacidades-agente-es) — Conexión editorial.
- [Eval Flywheel: los agentes de producción no se arreglan con prompts, se arreglan con casos](https://www.brthls.com/magazine/eval-flywheel-agentes-produccion-no-se-arreglan-con-prompts-es) — Conexión editorial.
- [Plugins para agentes: empaquetar capacidad exige un contrato verificable](https://www.brthls.com/magazine/plugins-agentes-contrato-capacidades-es) — Conexión editorial.

---

_Cite as: Berthelius, V. (2026). "Cuando el agente reescribe sus propias skills: autonomía sin change control". BRTHLS Magazine. https://www.brthls.com/magazine/cuando-agente-reescribe-skills-autonomia-change-control-es_