Agent Execution Environment

Dónde ocurre el trabajo

Agent Execution Environment es el contexto concreto de runtime donde un agente puede observar y realizar acciones, con determinados recursos de cómputo, filesystem, procesos, red, identidades y workspace. Describe dónde y con qué medios ocurre el trabajo efectivo. No concede autoridad por sí mismo ni garantiza aislamiento; esas preguntas corresponden a permisos y sandboxing.

El alcance depende de las acciones disponibles. Un agente puede consultar servicios mediante APIs sin disponer de shell propio. Otro puede ejecutar comandos en una máquina local, contenedor, VM, workspace cloud o runner de CI. Un mismo sistema puede combinar varios entornos: inferencia remota, coordinación en un servicio y herramientas que actúan en la estación del usuario. La ubicación de la conversación no basta para localizar esas acciones.

La distinción evita promesas falsas. Una interfaz web puede controlar recursos locales; una CLI puede delegar trabajo remoto. La arquitectura de Agents API permite distinguir el harness gestionado del entorno opcional de archivos/cómputo. Es un ejemplo de producto, no una exigencia de tener un contenedor propio para todo agente ni de usar exactamente esos componentes.

Recursos disponibles y alcance efectivo

El entorno ofrece una combinación concreta de sistema operativo, herramientas instaladas, directorios, procesos y conexiones. Algunos recursos pueden existir sin estar disponibles para la tarea. Otros pueden resultar accesibles mediante una herramienta remota aunque no estén montados en el filesystem. Inventariar solo archivos visibles deja fuera servicios, identidades y efectos que también forman parte del trabajo posible.

En Commerce, reproducir un rechazo de checkout puede requerir código de Payments UI, runtime de tests y datos sintéticos. Que producción sea alcanzable por red no la convierte en dependencia necesaria de la investigación. Tampoco la ausencia de una credencial local prueba que ningún conector disponga de autoridad remota. Interesa identificar qué interfaz usa cada acción y bajo qué identidad se ejecuta.

La disponibilidad es diferente del éxito. Un comando puede existir y fallar por versión, plataforma o configuración; una conexión puede ser posible y carecer de autorización. Cuando cambia el entorno, una tarea antes reproducible puede dejar de serlo sin que haya cambiado el modelo. Esa evidencia debe distinguirse de un defecto del código investigado o de una decisión equivocada del agente.

Local, remoto y background

Local indica ejecución sobre recursos de la máquina del usuario o su entorno de trabajo inmediato. Puede facilitar acceso a herramientas ya preparadas y al checkout actual. También puede acercar la tarea a archivos, procesos o credenciales ajenos al encargo. Local no significa acceso irrestricto: controles del runtime, sistema operativo y herramientas pueden limitarlo.

Remoto indica ejecución en infraestructura separada. Puede ofrecer un workspace preparado o recursos diferentes de la estación del usuario, con sus propios límites y dependencias. Remote no implica sandboxed automáticamente. Importan la configuración, identidades y conexiones efectivas. La application card de GitHub Copilot distingue experiencias locales y cloud con distintos entornos y flujos; no define una garantía universal para cualquier agente remoto.

Background describe continuidad sin una sesión de primer plano constantemente atendida. Puede ocurrir local o remotamente. No equivale a autonomía mayor ni a seguridad: una tarea en background puede pausar por autorización, conservar límites estrictos o necesitar intervención. Separar ubicación y ciclo de interacción permite preguntar quién observa el progreso y qué ocurre cuando hace falta una decisión.

En una investigación de Payments UI, mover la ejecución a cloud puede cambiar dependencias y datos disponibles; enviarla a background cambia cuándo se reciben resultados. Ningún cambio autoriza modificar el backend de cobros. La delegación y las capacidades necesitan evaluarse por separado, sin convertir local → remoto → background en una escala de madurez.

Workspace y entorno

Workspace es la vista de recursos del proyecto: checkout, worktree, archivos o área de trabajo presentada al agente. Environment incluye además cómputo, procesos, red, configuración e identidades que hacen posibles las acciones. Dos worktrees pueden compartir máquina, credenciales y servicios. Separar sus cambios de Git no separa automáticamente esas otras capacidades.

Un directorio puede ser el único ámbito de escritura autorizado mientras el proceso conserva capacidad de lectura más amplia. También puede haber archivos montados de solo lectura y herramientas que escriben en servicios externos. La ruta de trabajo ofrece contexto, pero no demuestra el límite completo. Esa distinción conecta con agent-sandboxing sin redefinir workspace como un mecanismo de seguridad.

Filesystem, procesos y red

El filesystem puede ofrecer lectura, escritura en el proyecto, directorios seleccionados o acceso más amplio. Esas opciones son dimensiones de configuración, no niveles universales de agente. Leer información sensible ya puede tener consecuencias aunque no se modifique nada. Los archivos generados y las cachés también pueden persistir datos fuera del árbol que la persona espera revisar.

La ejecución puede limitarse a operaciones predefinidas, exponer una shell o permitir procesos generales. Una capacidad más amplia puede resolver tareas variadas y aumentar efectos posibles. Un test aparentemente local puede ejecutar scripts del repositorio, contactar servicios o iniciar procesos. El nombre de la operación no describe necesariamente todas sus dependencias ni su alcance real.

La red puede estar deshabilitada, restringida por destinos o conectada a infraestructura privada o internet. No existe una política única adecuada para toda tarea. Un control debe examinar qué procesos cubre y dónde se aplica. La documentación del firewall de Copilot delimita explícitamente su cobertura; ese ejemplo muestra por qué no conviene inferir protección uniforme por la sola presencia de un firewall.

Credenciales y sistemas externos

Una acción puede utilizar identidad del usuario, identidad de servicio o una credencial efímera. Lo relevante es hacer explícita su autoridad y alcance. Tener una credencial disponible en el entorno no significa que el modelo deba recibirla como texto ni que toda herramienta tenga que poder leerla. Una integración puede mediar autenticación y devolver solo el resultado necesario.

La guía de seguridad de sandboxes de OpenAI describe separación de credenciales y acceso mediado. El principio editorial aquí es distinguir disponibilidad, exposición e identidad efectiva, sin imponer una implementación ni un proveedor de secretos. Guardar un secreto en un gestor no evita que quede expuesto si después se entrega indiscriminadamente al proceso ejecutor.

Una API remota agrega su propia autorización. Aunque el entorno permita emitir una solicitud, el servicio puede rechazarla o permitir más de lo esperado. La lectura de un registro, su modificación y una operación de despliegue pueden usar identidades diferentes. agent-permissions-and-approval-boundaries trata esa autoridad; el entorno local no absorbe las reglas del sistema externo.

Entorno, permisos y aprobación

Reachability describe la posibilidad de llegar a un recurso; autorización determina si la acción está permitida. Un archivo visible puede estar fuera del encargo y una herramienta registrada puede restringir sus destinos. Una instrucción de tarea tampoco altera por sí misma las reglas del sistema operativo o del servicio. Conviene conservar esas preguntas distintas al describir capacidades.

Una aprobación es una decisión adicional antes de una acción concreta. Puede requerir una persona o una política de revisión según el runtime. No es una propiedad equivalente a «entorno remoto» o «entorno local»: ambos pueden requerirla. Ejecutar en background no elimina esa condición; puede significar que el trabajo queda pendiente hasta resolverla.

El agent-harness puede mediar estas interacciones y enviar operaciones a distintos ejecutores. El entorno las realiza con sus recursos y restricciones. En caso de desacuerdo entre lo solicitado, lo autorizado y lo técnicamente posible, una descripción honesta conserva qué ocurrió. No debe afirmar que una acción se ejecutó solo porque la inferencia la propuso.

Ciclo de vida y aislamiento

Un entorno persistente puede conservar preparación y resultados entre tareas. También puede retener estado inesperado, datos sensibles o procesos que afectan nuevas ejecuciones. Uno efímero puede reducir persistencia y facilitar una preparación repetible, pero su duración breve no impide filtrar un secreto o modificar un servicio mientras está activo.

Container y VM son mecanismos posibles para alojar recursos y construir fronteras. No son definiciones del concepto Environment ni garantías intercambiables. Montajes, privilegios, conexiones y controles determinan qué queda separado. Un entorno local puede estar restringido y uno cloud puede tener acceso demasiado amplio; la etiqueta de ubicación no responde la pregunta de aislamiento.

Eliminar el entorno tampoco revierte efectos externos. Un dato enviado, un correo emitido o una actualización de una API puede sobrevivir al proceso. Los artefactos que sí deben conservarse necesitan una decisión explícita de salida. Esto no requiere desarrollar checkpoints en este documento: basta reconocer que duración del compute y duración de los efectos son dimensiones distintas.

La preparación del entorno también puede producir efectos: descargar paquetes, ejecutar un script de inicialización o conectar un volumen no son operaciones invisibles por ocurrir antes de la tarea principal. Necesitan el alcance que corresponda y pueden cambiar lo observado después. Un entorno preparado para desarrollo tampoco acredita autorización para publicar; separar preparación, ejecución y salida evita que una decisión de infraestructura absorba silenciosamente decisiones del encargo.

Fallos y relaciones en el Atlas

Dependencias ausentes, diferencias de plataforma, rutas inválidas, red indisponible o credenciales insuficientes pueden impedir una tarea. El resultado informa sobre las condiciones de ejecución; no demuestra que el cambio propuesto sea correcto ni que el agente deba ampliar su acceso. Resolver una dependencia y solicitar más autoridad son decisiones diferentes, cuyo alcance depende del encargo.

En Commerce, un test que no inicia por falta de runtime exige reportar esa limitación. Usar producción para compensarlo cambiaría recursos y riesgos, no sería un detalle mecánico. Conservar esa distinción permite revisar evidencia y retomar el trabajo sin inventar resultados. También ayuda a comparar ejecuciones sin atribuir cualquier diferencia al modelo.

Este canonical ubica las acciones y los recursos. Agents conserva la definición del sistema; Harness, la maquinaria que sostiene el loop; Permissions/Approval, la autorización; Sandboxing, las restricciones técnicas. La comparación aplica a coding, soporte, análisis y browser agents. Ningún ejemplo local, cloud o de CI define por sí solo qué es un agente.

Fuentes

Fuentes primarias consultadas el 2026-10-25. La definición, las dimensiones de comparación y Commerce son síntesis editorial del Atlas; modalidades y garantías de producto son información versionada.

• OpenAI: Agents API architecture, harness y entorno como responsabilidades distintas.
• GitHub: Copilot Agents application card, experiencias con ubicaciones y flujos diferentes.
• GitHub: firewall coverage and limitations, alcance de un control concreto.
• OpenAI: Sandbox security, credenciales y acceso mediado.