Límites en lugar de instrucciones: cómo mantener el control sobre agentes de IA autónomos

Cuanto más autónomos se vuelven los agentes de IA, más a menudo intentamos gestionarlos de la forma habitual: escribimos reglas en el prompt: «no toques esto», «trabaja solo ahí», «nunca hagas aquello». Durante el experimento con tres agentes en paralelo reuní en dos días una colección viva de casos en los que este método falla — y en los que funciona otro. La tesis del artículo es simple: una instrucción es una petición que el agente cumple con cierta probabilidad; un límite es una propiedad del sistema que no depende de la obediencia. Mientras había un solo agente y trabajaba bajo supervisión, la diferencia parecía estilística. Cuando los agentes se multiplicaron, resultó arquitectónica.

Cinco incidentes de una sesión

Todos los casos siguientes ocurrieron en una misma sesión de trabajo en este blog — están documentados, y cada uno ilustra su propia forma en que la gestión mediante texto falla.

No había instrucción — ocurrió un accidente. El agente, preparándose para su tarea, ejecutó git stash en el directorio principal y se llevó al stash mis archivos sin commitear, que no tenían relación con su tarea. Nadie «violó» nada: simplemente no existía la prohibición. Esta es una propiedad fundamental de las instrucciones: se escriben después de los accidentes. La lista completa de lo que el agente no debe hacer es imposible de escribir.

La instrucción existía — y no funcionó. Después del primer accidente añadí a los agentes una regla explícita: «trabaja estrictamente en tu directorio de trabajo». Uno de los agentes de todos modos ejecutó un comando git en el directorio principal — simplemente se dirigió a él por ruta absoluta. No por malicia ni por estupidez: el modelo es probabilístico, y el cumplimiento de una regla textual también es una probabilidad, multiplicada por la longitud del contexto y el número de ejecuciones.

Un límite técnico actuó en silencio. En el mismo experimento no ocurrió ni una sola vez el accidente más esperado: «un agente cambió la rama a todos». No porque los agentes fueran cuidadosos, sino porque git worktree físicamente no permite escribir una misma rama en dos copias de trabajo. La protección está integrada en la herramienta. No hay que recordarla, no hay que seguirla: simplemente existe.

La instrucción estaba donde debía estar un límite. El descubrimiento más desagradable: el prod de este blog estaba protegido por una línea en el prompt. Un push a master dispara el autodespliegue, y de cada agente lo separaba solo el texto «nada de git push». Se mantuvo — pero eso es suerte, no control: el límite real aquí son los permisos de acceso, la protected branch, un token sin permiso de escritura. Una petición ocupaba el lugar de un candado.

Un límite por encima del propio agente. Dos veces durante la sesión el entorno de ejecución detuvo no a los agentes de prueba, sino a mi asistente principal: el clasificador de permisos bloqueó SSH al servidor de prod y el borrado masivo de cambios sin commitear — acciones que formalmente se derivaban de la tarea, pero requerían un «sí» humano explícito. Ambos bloqueos fueron correctos. Y ambos ocurrieron por encima de la «disciplina» del agente, que sinceramente creía estar actuando según el plan.

El principio no es nuevo — solo la entidad es nueva

La ingeniería aprendió esta lección mucho antes de los LLM. En el sistema de producción de Toyota el principio se llama poka-yoke: el error lo previene un dispositivo del proceso, no la vigilancia del ejecutor. Una pieza que solo puede insertarse del lado correcto es más fiable que un cartel de «inserta correctamente». En la ingeniería de plataformas lo mismo se llama guardrails, en seguridad — defense in depth. En todas partes la misma idea: no confíes en que el ejecutor leyó, entendió y no olvidó — haz que la acción incorrecta sea imposible o costosa.

“Una instrucción es una petición. Un límite es una propiedad del sistema. El control que se sostiene sobre peticiones no es control, sino suerte con efecto acumulativo.”

– la conclusión principal de dos días de trabajo con agentes en paralelo

Con los agentes de IA este viejo principio se agudiza por tres razones. Hay muchos agentes — la probabilidad de fallo de la instrucción se multiplica por cada ejecución de cada agente. Los agentes son rápidos — entre «empezó a equivocarse» y «lo rompió del todo» pasan segundos, la persona no llega a intervenir. Y los agentes son literales, pero no fiables: ejecutan el texto del prompt con más diligencia que cualquier junior, y aun así de forma probabilística — y el cumplimiento probabilístico de reglas a escala garantiza la violación.

Cómo se ven los límites en la práctica

Las capas que construí tras esta sesión — desde el sistema de archivos hasta la verificación:

• Sistema de archivos: cada agente — su propia copia de trabajo (git worktree, que Anthropic recomienda para sesiones en paralelo, en Claude Code está integrado), y a nivel de SO — una sandbox: sandboxing en Claude Code aísla el sistema de archivos y la red con primitivas nativas del SO — según Anthropic, esto redujo sus solicitudes internas de permisos en un 84%, y una prompt-injection exitosa queda encerrada dentro.
• Permisos de escritura: prod y master se protegen con permisos, no con el prompt: protected branch, tokens sin derecho de push, cuentas separadas para los agentes. Las peticiones de dejarlo en el prompt pueden hacerse, pero como segunda capa.
• Runtime: worktree no aísla las bases de datos, los puertos ni los contenedores: son compartidos por todas las copias. Los agentes que ejecutan pruebas y servidores necesitan recursos desechables: una BD temporal, su propio puerto, un contenedor por agente.
• Permisos de acción: las operaciones irreversibles pasan por una confirmación o un clasificador, como auto mode en Claude Code, que evalúa cada acción en lugar de preguntar por todo o no preguntar por nada. Es una frontera que solo se mueve con una decisión explícita de una persona.
• Verificación por artefactos: no confiar en el autoinforme del agente, sino en las huellas en el disco. Mi agente colgado parecía estar trabajando en la interfaz; el diagnóstico lo dio la ausencia de archivos nuevos en su copia durante veinte minutos. Los commits a la propia rama son la misma idea: un resultado que sobrevive tanto al fallo como al optimismo del agente.

Las instrucciones en este esquema no desaparecen: se convierten en la última capa, no en la primera. «Trabaja en tu propio directorio» en el prompt sigue siendo útil: reduce la frecuencia de los intentos. Pero entre el intento y el accidente debe haber una frontera, no una esperanza.

Salvedades honestas

La frontera no es absoluta: las sandboxes se eluden, los clasificadores se equivocan, y los análisis publicados de evasiones lo muestran con regularidad. Por eso las fronteras se construyen por capas, como todo en seguridad. Y una frontera cuesta más que una instrucción al inicio: configurar worktree, permisos y sandbox son horas; escribir una línea en el prompt son segundos. La asimetría está en otro lado: la frontera se paga una vez, la instrucción se paga con la probabilidad de fallo en cada ejecución. En mi caso, configurar el aislamiento se amortizó con el primer reinicio del experimento, que transcurrió sin un solo conflicto.

Conclusión

La pregunta de la serie es cómo integrar a los agentes de IA en el trabajo real sin perder el control. La respuesta de este artículo: el control no es lo que se le escribe al agente, sino lo que se construye a su alrededor. Antes de añadir al prompt otro «nunca hagas X», vale la pena preguntarse: ¿y se puede hacer X técnicamente imposible? Si la respuesta es sí, ese es el lugar correcto para el esfuerzo. Que el prompt pida; el sistema debe prohibir.

Fuentes y referencias

• Making Claude Code more secure and autonomous with sandboxing (Anthropic Engineering) — aislamiento del sistema de archivos y de la red a nivel de SO; fuente de la cifra del 84%.
• How we contain Claude across products (Anthropic Engineering, 2026) — cómo están construidas las fronteras de ejecución en los productos agénticos en su conjunto.
• How we built Claude Code auto mode (Anthropic Engineering) — el clasificador de permisos como frontera entre «preguntar por todo» y «no preguntar por nada».
• Poka-Yoke (Lean Enterprise Institute) — el principio clásico de prevención de errores mediante el diseño del proceso.
• git-worktree y git-stash — documentación oficial de Git: la mecánica de las copias de trabajo y del stash compartido.
• Claude Code: Best practices for agentic coding (Anthropic Engineering) — la recomendación de worktree para sesiones paralelas.
• Cómo comparar honestamente LLM en tu propio código: experimento con tres modelos Claude — artículo anterior de la serie: el experimento en el que se recogen los incidentes descritos.