Agents
Qué llamamos agente
En el Atlas, un AI agent es un sistema que utiliza un modelo dentro de un proceso de ejecución para interpretar observaciones, seleccionar o proponer acciones y utilizar sus resultados para avanzar hacia un objetivo acotado, con mecanismos de continuación y detención. Esta definición de trabajo se concentra en el comportamiento del sistema. No exige una implementación particular ni constituye un estándar universal de inteligencia artificial.
El término tiene fronteras discutidas. En Building effective agents, Anthropic distingue workflows con caminos predefinidos de agentes cuyo modelo dirige dinámicamente el proceso. La documentación de Agents de OpenAI enfatiza herramientas, trabajo entre pasos y elección de runtime. Son perspectivas relacionadas; ninguna establece por sí sola el significado universal de agent.
Aquí tratamos principalmente agentes basados en modelos de lenguaje, relevantes para ingeniería de software. El uso histórico de agente en AI es más amplio. No pretendemos redefinirlo para todas las disciplinas ni afirmar que cualquier sistema orientado a objetivos necesita un LLM. Dentro de este alcance, importa cuánto del próximo paso se decide durante la ejecución a partir de lo observado.
Modelo, sistema y entorno
Un LLM realiza inferencia sobre entradas y produce salidas. Puede generar una explicación, una propuesta de modificación o una solicitud estructurada de herramienta. Esa salida no implica que el modelo disponga por sí mismo de filesystem, shell, browser, permisos, memoria duradera o capacidad de modificar un servicio. Un componente externo debe interpretar y, cuando corresponda, ejecutar lo solicitado.
El agente combina esa capacidad con un proceso de trabajo. Puede involucrar instrucciones, contexto, herramientas, estado, entorno, políticas y un loop. Es una descripción de componentes posibles, no un checklist obligatorio: un agente sencillo no necesita múltiples herramientas, almacenamiento persistente, delegación ni varios modelos. Tampoco necesita fingir una personalidad para perseguir una tarea.
La distinción se aprecia en Commerce. Una invocación recibe un fragmento de validación de checkout y devuelve una hipótesis. Un sistema agente puede buscar dónde se valida el pago, inspeccionar casos fallidos, elegir otra comprobación y ajustar su hipótesis con el resultado. El modelo participa en ambos; el segundo comportamiento depende además de cómo se organiza la ejecución.
El entorno es aquello que el sistema puede observar y afectar mediante las interfaces disponibles: una API, un repositorio, un terminal, un IDE o un workspace remoto. La pantalla utilizada para conversar no define esa capacidad. Un CLI puede limitarse a devolver texto; un IDE puede albergar ejecución delegada. Cloud indica ubicación, no un grado de agencia.
Un loop conceptual, no un algoritmo universal
Una simplificación útil es observar → decidir → actuar → observar el resultado → continuar o detenerse. Describe una relación de feedback, no una secuencia formal que todos los agentes implementen literalmente. Decidir puede significar responder, pedir aclaración o reconocer que no existe una acción permitida. Tampoco exige publicar un razonamiento interno paso a paso.
En el ejemplo de checkout, el sistema observa un test fallido, decide inspeccionar la conversión de un importe, lee la función y contrasta su salida con el caso reproducido. Si el resultado contradice la hipótesis inicial, puede buscar otra causa. Volver a ejecutar siempre el mismo comando sin incorporar su resultado no demuestra una investigación útil, aunque exista repetición mecánica.
El loop puede vivir en una aplicación, un runtime gestionado o una combinación de componentes. La decisión del modelo y su ejecución efectiva son momentos distintos: una petición de escritura puede rechazarse antes de producir cambios. Un resultado de herramienta también puede indicar indisponibilidad, salida incompleta o una condición que exige intervención humana.
ReAct es una propuesta concreta dentro de este espacio, no el modelo universal de todo agente. Tampoco toda cadena de llamadas a un modelo constituye agencia significativa: si cada transición está fijada y el modelo solo completa valores, conviene describir explícitamente ese control de flujo antes de asignar una etiqueta.
Objetivos, observaciones y acciones
El objetivo orienta qué resultados cuentan como progreso. Un prompt puede comunicarlo, pero prompt y objetivo no son equivalentes: una solicitud puede incluir contexto y restricciones, mientras el objetivo conserva continuidad entre varias acciones. «Explicá este error» y «investigá y corregí la validación sin cambiar el contrato de Payments» delegan alcances diferentes.
Las observaciones incluyen mensajes del usuario, archivos, respuestas de herramientas, estado del entorno o resultados de tests. Son información disponible para decidir. Observar una frase dentro de un archivo no la convierte automáticamente en instrucción autorizada. La procedencia y la autoridad requieren interpretación separada; aquí basta conservar esa frontera, sin desarrollar todavía AI Security.
Una acción puede ser responder, consultar una herramienta, editar, ejecutar una comprobación, solicitar ayuda, delegar cuando esté permitido o finalizar. No se reduce a tool calling. Pedir al responsable de Payments que precise una regla puede ser una acción correcta cuando continuar implicaría inventar comportamiento comercial.
En Commerce, el importe rechazado es una observación; corregir la representación es una acción posible; preservar la semántica del pago es parte del objetivo y de sus restricciones. Confundir esas funciones lleva a tomar cualquier test verde como éxito, incluso si se eliminó la validación que debía protegerse. El loop necesita criterios externos a su propia narración.
Continuación y stop conditions
La ejecución necesita algún mecanismo para dejar de continuar. Puede detenerse al alcanzar el objetivo, declarar un resultado, agotar tiempo o pasos, encontrar un fallo de entorno, recibir una interrupción humana o llegar a una frontera de política. No hay una condición única adecuada para todos los sistemas.
Finalizar una interacción no equivale a haber cumplido el objetivo. «No pude reproducirlo con los datos disponibles» puede ser un cierre honesto; «corregido» sin comprobaciones es una afirmación más fuerte que necesita evidencia. La razón de detención y el resultado alcanzado deben poder distinguirse, especialmente cuando otro participante retoma el trabajo.
Los límites operativos complementan el criterio semántico. Un máximo de pasos puede impedir que una investigación improductiva continúe indefinidamente, pero no determina que el resultado sea correcto. A la inversa, un objetivo claro no evita por sí mismo una sucesión prolongada de acciones. Tiempo, alcance y condición de aceptación responden preguntas diferentes.
Detenerse también puede conservar trabajo parcial y comunicar incertidumbre. Si falla el entorno de tests, el agente puede reportar qué inspeccionó y qué no verificó. Reemplazar esa evidencia ausente por una explicación convincente ocultaría el bloqueo. No es necesario desarrollar aquí un sistema de checkpoints para reconocer esa obligación básica.
Herramientas, estado y memoria
Las herramientas amplían observación y acción: leer código, consultar datos o ejecutar un test. Tener acceso a ellas no basta para llamar agente al sistema. Una operación fija de «ejecutar este test y explicar su salida» puede incorporar una herramienta dentro de asistencia conducida por una persona, sin delegar la selección de un curso de trabajo.
Tool Use describe el aprovechamiento de una capacidad; Tool Calling desarrolla el mecanismo de invocación estructurada. El tratamiento general de Tool Use permanece separado y pendiente. Para esta definición alcanza con preguntar quién selecciona las acciones, qué feedback recibe y qué proceso controla su continuidad. El número de llamadas no ofrece un umbral universal.
El estado de ejecución puede reunir progreso, resultados recientes y una intención pendiente. Agent Memory trata información retenida para uso posterior. Pueden solaparse, pero no son sinónimos: un registro de qué comando está activo tiene una función distinta de recordar una convención aprendida entre tareas. Planning organiza el curso previsto, sin ser requisito de un artefacto explícito en toda tarea. No todos los agentes poseen memoria de largo plazo.
La documentación de Google ADK sobre LlmAgent presenta una unidad que utiliza el modelo para decidir cómo proceder y qué herramientas usar, si corresponde. Ese objeto configurable es un ejemplo de implementación. Sus campos y nombres no obligan a que todos los agentes del Atlas compartan estructura, persistencia o API.
Autonomía acotada
Autonomía describe una delegación de decisiones bajo límites. Conviene examinar autoridad de acción, alcance, duración, cantidad de pasos, necesidad de aprobación, recuperación, delegación y acceso al entorno. No forman una escala de madurez universal: poder trabajar más tiempo no concede más permisos, y poder editar no concede autoridad para desplegar.
Un agente puede requerir confirmación para una acción y conservar iniciativa para elegir las siguientes dentro del alcance acordado. La intervención humana no elimina automáticamente su carácter agentic. La autonomía tampoco implica ausencia de supervisión, acceso irrestricto a la red o libertad para ampliar la tarea cuando encuentra trabajo relacionado.
En Commerce, investigar y modificar Payments UI puede estar permitido, mientras alterar el backend de cobros permanece fuera del encargo. El agente puede detectar allí una causa probable y devolver evidencia para otra decisión. Cruzar esa frontera silenciosamente cambiaría la delegación; no sería simplemente una versión más capaz del mismo trabajo.
Las instrucciones expresan intención, pero la autoridad técnica depende del sistema que permite o bloquea acciones. Un texto que diga «no desplegar» y un entorno que no exponga ninguna credencial de despliegue son controles distintos. agent-permissions-and-approval-boundaries y agent-sandboxing desarrollan esas fronteras de autorización y restricción técnica.
Workflows, automatización y composición
Un workflow tiene más de su control de flujo definido externamente; un agente delega más selección del próximo paso al modelo y al runtime. Es una intuición útil para examinar un sistema, no una clasificación binaria. Muchos procesos combinan tramos fijos con selección dinámica y aprobación humana.
Por ejemplo, una pipeline puede preparar el repositorio, invocar un coding agent para investigar un fallo y ejecutar después verificaciones predeterminadas. El workflow contiene un paso agentic. A la vez, ese agente opera dentro de un workflow que limita entradas, salida y condiciones de avance. Los conceptos son componibles y se describen en niveles distintos.
Automation puede ser completamente determinista. En estos agentes, parte de la interpretación o selección depende de inferencias probabilísticas, mientras otros componentes aplican reglas programadas. Invocar un compilador no lo vuelve probabilístico por haberlo elegido un modelo; tampoco un resultado reproducible de compilación garantiza una interpretación correcta del requisito.
La elección útil empieza por la variación real de la tarea. Si el siguiente paso ya se conoce y debe conservarse, un workflow sencillo puede bastar. Si investigar requiere adaptar acciones a resultados no previstos, delegar parte de esa selección puede tener sentido. «Agent» no es una recomendación automática de mayor complejidad.
workflows-vs-agents amplía esta frontera de control y la composición en ambos sentidos, sin exigir determinismo total al workflow ni libertad irrestricta al agente.
Asistentes, harness y vocabulario de producto
coding-assistants enfatiza apoyo a una progresión conducida por una persona; coding-agent especializa la ejecución delegada en trabajo de software. Son focos sobre interacción y responsabilidad, no cajas excluyentes. Una experiencia puede alternarlos y un producto puede ofrecer varios modos sin cambiar de marca.
agent-harness nombra la infraestructura de runtime y coordinación alrededor del modelo y de la ejecución. El agente describe al sistema que persigue la tarea; el harness sostiene capacidades y control de ejecución. El mismo modelo con otro harness, contexto y políticas puede mostrar comportamientos diferentes. agent-execution-environment ubica los recursos donde ocurren sus acciones.
Las fuentes tienen unidades de análisis distintas. OpenAI describe además un Agent configurable en su SDK; Claude Code se presenta como agentic assistant; GitHub organiza capacidades assistive y agentic. Esas denominaciones no deben convertirse silenciosamente en categorías mutuamente excluyentes del Atlas.
Límites y relaciones en el Atlas
Un agente puede interpretar mal el objetivo, elegir una acción incorrecta, leer mal una salida, detenerse demasiado pronto o seguir más allá del alcance. El feedback ayuda a corregir, pero también puede ser incompleto o mal interpretado. Ni la existencia del loop ni una explicación detallada certifican un buen resultado.
No se requiere un sistema multi-agent para estas propiedades. Tampoco una sesión larga demuestra progreso. El criterio útil es qué decisiones fueron delegadas, qué acciones estuvieron autorizadas y qué evidencia sostiene el resultado. Failure Modes, Evaluation y Memory tendrán tratamiento propio cuando se materialicen, sin anticipar aquí sus taxonomías.
ai-assisted-software-engineering ofrece el recorrido inicial de lectura. Este canonical conserva la definición general; las expectativas particulares de cambios en repositorios y verificación se desarrollan en Coding Agent. Un agente también puede perseguir objetivos fuera de programación: el dominio de la tarea especializa el sistema sin redefinir su base conceptual.
Fuentes
Fuentes primarias consultadas el 2026-10-25. Las distinciones y el ejemplo de Commerce son síntesis editorial del Atlas; los nombres de objetos y productos conservan el alcance de su documentación.
- Anthropic: Building effective agents, publicado en 2024; útil por su distinción de control de flujo, no como inventario actual de productos.
- OpenAI: Agents y Agent definitions, perspectivas de runtime y SDK.
- Google ADK: Simple agents with LlmAgent, vocabulario específico de implementación.
- Claude Code: How Claude Code works y GitHub: About Copilot, ejemplos de terminología que combina asistencia y agencia.