De la meta a la acción controlada: bucles, verificación y permisos en agentes de IA
Aprenda cómo los agentes de IA convierten un objetivo en llamadas a herramientas mediante un ciclo de planificar, actuar y observar, y por qué la verificación, los niveles de autonomía y las capas de permisos determinan si son seguros.
La mayoría de las personas conocieron los modelos de lenguaje primero como máquinas para responder preguntas: se ingresa una solicitud, se obtiene una respuesta y listo. Los sistemas de agentes rompen ese patrón. Ante un objetivo, planifican, utilizan herramientas, examinan los resultados y continúan hasta que la tarea está completada. Esta explicación aborda el ciclo, las herramientas, la memoria y las configuraciones multiagente, para luego centrarse en lo que más importa en la producción: verificar el trabajo de un agente y limitar su autoridad.
Responder versus trabajar hacia un objetivo
Un chatbot clásico funciona en una sola pasada: se ingresa una pregunta, el modelo genera una respuesta y no ocurre nada más.
User
↓
Question
↓
AI
↓
Answer
Si le preguntas “¿Qué es el aprendizaje automático?”, obtienes una explicación, nada más. Un agente está organizado en torno a un objetivo, al que se llega mediante una secuencia de acciones con retroalimentación en cada paso.
User
↓
Goal
↓
AI Agent
↓
Plan
↓
Use Tools
↓
Observe Results
↓
Take More Actions
↓
Complete Goal
Una solicitud como “analizar este conjunto de datos y generar un informe” debe dividirse en etapas concretas:
Read dataset
↓
Understand columns
↓
Clean data
↓
Analyze statistics
↓
Create graphs
↓
Find patterns
↓
Write report
En resumen, un chatbot responde, mientras que un agente realiza el trabajo y se ajusta según avanza.
¿Qué hace que un sistema sea considerado un agente?
No existe una definición única acordada. Una práctica es la siguiente: un agente recibe una tarea, toma decisiones, utiliza las herramientas disponibles, examina los resultados y elige acciones adicionales hasta alcanzar el objetivo. La característica definitoria es la rama en la parte inferior que envía el control de vuelta hacia arriba.
USER GOAL
↓
AI AGENT
↓
PLAN
↓
SELECT ACTION
↓
USE TOOL
↓
OBSERVE
↓
EVALUATE
↓
NEXT ACTION?
↙ ↘
YES NO
↓ ↓
Continue Finish
Sin ese bucle, se tiene un proceso que se ejecuta una sola vez. Con él, el sistema puede recuperarse de imprevistos, lo cual es tanto su ventaja como la razón por la que necesita supervisión.
El ciclo pensar, actuar, observar
El modelo mental más simple para ese ciclo es pensar, actuar y observar. Imagine pedirle a un agente que encuentre la mejor laptop dentro de su presupuesto y compare tres opciones. Internamente, podría proceder de esta manera:
Goal
↓
Understand requirements
↓
Search for products
↓
Read results
↓
Compare specifications
↓
Check prices
↓
Evaluate options
↓
Generate recommendation
El agente no obtiene información sobre las laptops de su memoria de entrenamiento. Consulta fuentes reales y basa sus recomendaciones en lo que encuentra, y ese contacto con el mundo exterior es lo que lo diferencia de la generación de texto simple.
Tres componentes: modelo, herramientas y estado
Un agente básico puede describirse en términos de tres componentes.
El modelo como tomador de decisiones
Suele tratarse de un modelo de lenguaje grande, que interpreta las instrucciones y decide qué hacer a continuación.
Herramientas como capacidades
Las herramientas son las capacidades externas que el agente puede utilizar, por ejemplo:
Search
Python
Calculator
Database
API
File system
Computer
Vision model
El estado como registro en tiempo real
El estado es lo que el agente sabe sobre la tarea hasta el momento. Responde a preguntas como estas:
What did I search?
What did I find?
What have I already done?
What remains?
En conjunto, estos tres componentes influyen en las acciones que toma el agente:
AI AGENT
│
┌──────────┼──────────┐
↓ ↓ ↓
Model Tools Memory
│ │ │
└──────────┼──────────┘
↓
Actions
Para un análisis más detallado de estos elementos básicos, consulte nuestra guía sobre objetivos, herramientas, memoria y el bucle del agente.
Por qué las herramientas tienen tanta importancia
Pida a un modelo que multiplique 938472 por 827391 y puede que lo haga bien, pero predice los dígitos en lugar de calcularlos, por lo que una calculadora o Python son más fiables. Un agente puede delegar la tarea:
User
↓
LLM
↓
"I need exact arithmetic."
↓
Calculator
↓
Result
↓
LLM
↓
Answer
El modelo no tiene que hacer todo por sí mismo. Delega.
Elegir la herramienta adecuada para la entrada
¿Cómo elige el agente entre sus herramientas? Supongamos que puede acceder a todas estas:
Python
SQL
Search
Calculator
Vision Model
File Reader
Email API
Calendar
Ante la tarea de “mirar esta hoja de cálculo de ventas y explicar por qué disminuyeron los ingresos”, el sistema deduce, a partir del tipo de entrada, la estructura de los datos y la tarea en sí, qué herramienta utilizar:
Input = Spreadsheet
↓
Data = Tabular
↓
Task = Analysis
↓
Tool = Python/pandas
A partir de ahí, la herramienta elegida realiza el trabajo principal y devuelve sus resultados:
pandas
↓
Analyze sales
↓
Find patterns
↓
Return results
Luego, el agente interpreta esos resultados. En la práctica, la elección de la herramienta depende en gran medida de nombres y descripciones claras, ya que eso es todo lo que ve el modelo.
Conexión de varias herramientas en un único flujo de trabajo
Considere la tarea de “analizar nuestros datos de ventas, representarlos gráficamente y enviar el informe por correo electrónico a mi supervisor”, que abarca análisis, visualización, redacción y entrega:
Sales Dataset
↓
Python / pandas
↓
Statistical Analysis
↓
Matplotlib
↓
Create Charts
↓
LLM
↓
Write Report
↓
Email Tool
↓
Send Report
El sistema ahora coordina un flujo de trabajo, donde cada salida sirve como entrada para el siguiente paso, por lo que un error temprano se transmite hasta llegar al correo electrónico.
Planificación mediante descomposición de tareas
“Crear un sitio web para mi proyecto” es una tarea demasiado grande para abordarla de una sola vez. Un agente competente la divide en partes ordenadas:
Goal
↓
Understand requirements
↓
Create project structure
↓
Build frontend
↓
Build backend
↓
Connect database
↓
Run application
↓
Test
↓
Fix errors
↓
Deploy
Esto es descomposición de tareas: el objetivo se convierte en una serie de acciones más pequeñas que pueden ejecutarse y verificarse una por una.
Reaccionar ante los fallos en lugar de informarlos
El bucle resulta útil cuando algo falla. Supongamos que el agente ejecuta algún código:
Write code
↓
Run code
↓
ERROR
Un chatbot solo puede informar del error. Un agente puede leerlo, corregir el código e intentarlo de nuevo:
Write code
↓
Run code
↓
ERROR
↓
Read error
↓
Identify problem
↓
Modify code
↓
Run again
↓
SUCCESS
De forma generalizada, ese es el bucle de los agentes, donde la evaluación genera un nuevo plan:
┌──────────────┐
│ PLAN │
└──────┬───────┘
↓
┌──────────────┐
│ ACT │
└──────┬───────┘
↓
┌──────────────┐
│ OBSERVE │
└──────┬───────┘
↓
┌──────────────┐
│ EVALUATE │
└──────┬───────┘
│
└──────→ PLAN AGAIN
Un bucle que puede intentarlo de nuevo también podría hacerlo indefinidamente, por lo que los sistemas reales limitan las iteraciones.
Memoria y continuidad entre pasos
Sin memoria, cada tarea comienza desde cero:
Task 1
↓
Forget
↓
Task 2
↓
Forget
Con el estado conservado, cada paso se basa en el anterior:
Task 1
↓
Save result
↓
Task 2
↓
Use previous result
↓
Task 3
La memoria existe en varios ámbitos:
- Estatuto a corto plazo: almacena información de la tarea en curso.
- Memoria a largo plazo: persiste a través de las interacciones, siempre que el sistema lo permita.
- Memoria externa: se encuentra fuera del modelo, en bases de datos, documentos, almacenes vectoriales o archivos.
Un agente puede consultar documentos del proyecto y resultados anteriores antes de realizar el paso actual:
Agent
↓
Memory
↓
Project documents
↓
Previous results
↓
Current task
Combinar la recuperación de información con acciones
La generación mejorada mediante recuperación de información (RAG) se combina naturalmente con los agentes. Para responder a partir de documentos internos de la empresa, un agente los busca, lee las secciones relevantes y razona sobre ellas:
Question
↓
Search company documents
↓
Retrieve relevant information
↓
Read context
↓
Reason about it
↓
Answer
Al añadir herramientas, el agente también puede actuar sobre lo que encuentra:
AI AGENT
│
┌───────────┼───────────┐
↓ ↓ ↓
RAG Python APIs
↓ ↓ ↓
Documents Analysis Actions
Dividir el trabajo entre varios agentes
Cuando un agente no es suficiente, varios agentes especializados pueden trabajar bajo la coordinación de un coordinador:
MAIN AGENT
│
┌────────────┼────────────┐
↓ ↓ ↓
Research Agent Coding Agent Data Agent
│ │ │
Search Code Analysis
Los agentes encargados de la investigación, la programación y los datos se ocupan cada uno de su especialidad, mientras que el agente principal dirige las tareas entre ellos. Este es un sistema multiagente.
La analogía del equipo y sus limitaciones
La estructura se asemeja a una empresa de software con roles distintos:
Manager
↓
Developer
↓
Tester
↓
Designer
↓
Deployment
Un sistema de IA puede reflejar esa división del trabajo:
Coordinator Agent
↓
Research Agent
↓
Coding Agent
↓
Testing Agent
↓
Deployment Agent
La comparación es aproximada, pero indica una dirección: coordinar modelos y herramientas especializados en lugar de depender de un solo modelo. Cada agente adicional también aumenta los costos y la latencia, por lo que la especialización debe ser real.
Cómo cometen errores los agentes
La autonomía no implica fiabilidad. Un agente puede:
- elegir la herramienta incorrecta
- interpretar mal el objetivo
- generar código defectuoso
- obtener información irrelevante
Los errores se acumulan en cada etapa posterior:
User Goal
↓
Wrong interpretation
↓
Wrong tool
↓
Wrong result
↓
Wrong action
Cuanta más libertad tenga un agente, más necesario es verificar su trabajo.
Incorporar la verificación en el bucle
El patrón antiétnico es un agente que actúa y simplemente asume que la acción funcionó:
Act → Assume success
El patrón óptimo incluye una verificación explícita antes de continuar:
Act
↓
Observe
↓
Verify
↓
Continue
En el caso del código, la verificación consiste en ejecutar una prueba con un desvío claro según el resultado:
Write Code
↓
Run Tests
↓
Tests Pass?
├── NO → Fix
└── YES → Continue
En el caso de los datos, se trata de una comprobación de validez del resultado antes de que alguien dependa de él:
Database Query
↓
Check Result
↓
Is result reasonable?
├── NO → Investigate
└── YES → Continue
Verificar en lugar de asumir es lo que realmente diferencia a un agente adaptativo de un simple script. Es preferible utilizar verificaciones deterministas, como pruebas o validación de esquemas, en lugar de pedirle al modelo que se evalúe por sí mismo.
La autonomía es un dial, no un interruptor
Los agentes no necesitan libertad total. Imagine una escala que comienza con un sistema que solo responde:
Level 1
AI only answers
Los niveles superiores añaden acciones sugeridas, luego llamadas a herramientas, después planificación de múltiples pasos y, finalmente, flujos de trabajo ejecutados con supervisión limitada:
Level 2
AI suggests actionsLevel 3
AI calls toolsLevel 4
AI plans multiple actionsLevel 5
AI executes workflows with limited supervision
Cada paso hacia arriba en la escala eleva los requisitos para el agente:
Permissions
Safety
Monitoring
Verification
Human oversight
El nivel más bajo que resuelve el problema suele ser la opción más segura.
Determinar qué puede manipular un agente
Imagine un agente conectado a todo lo siguiente:
Email
Banking
Files
Database
Cloud infrastructure
Production servers
Un acceso sin restricciones sería imprudente. Un diseño más seguro dirige las acciones a través de una capa de permisos:
AI Agent
↓
Permission Layer
↓
Allowed Tools
↓
Action
Luego se establecen permisos por acción: leer un archivo puede estar bien, mientras que eliminar, enviar por correo electrónico, desplegar o acceder a la base de datos dependen del contexto:
Read file ✓
Delete file ?
Send email ?
Deploy software ?
Access database ?
El principio es el mínimo privilegio.
Límites y aprobación humana
Los agentes de producción también necesitan límites estrictos en su funcionamiento:
Allowed tools
Maximum actions
Time limits
Budget limits
File permissions
Network permissions
Human approval
Para acciones de alto impacto, el agente prepara la acción y espera a que una persona la apruebe:
Agent
↓
Prepare Action
↓
Human Approval
↓
Execute
Ese es un diseño con intervención humana. Los bucles limitados se tratan en nuestro artículo sobre bucles agentes limitados en TypeScript.
Dónde se aplican los agentes
Ese mismo modelo se utiliza en muchos campos.
Desarrollo de software
Requirement
↓
Coding Agent
↓
Code
↓
Testing
↓
Bug Fixing
Análisis de datos
Dataset
↓
Data Agent
↓
Cleaning
↓
Analysis
↓
Visualization
↓
Report
Soporte al cliente
Tenga en cuenta el paso de “acción permitida”: los agentes de soporte trabajan dentro de un conjunto estrecho y previamente aprobado de operaciones.
Customer Question
↓
Retrieve Account Information
↓
Understand Problem
↓
Take Permitted Action
↓
Respond
Investigación
Research Question
↓
Search
↓
Read Papers
↓
Extract Information
↓
Compare Findings
↓
Generate Report
Productividad personal
Goal
↓
Calendar
↓
Email
↓
Documents
↓
Tasks
↓
Summary
Un tipo diferente de interfaz
El software convencional relaciona un control con una función y, finalmente, con un resultado:
Button
↓
Function
↓
Result
Un agente relaciona un objetivo establecido con un plan, llamadas a herramientas y acciones:
Goal
↓
Planning
↓
Tools
↓
Actions
↓
Result
En lugar de aprender qué botones presionar, el usuario describe el resultado deseado. Esto cambia la interacción humano-computadora y hace que la visibilidad de las acciones del agente sea un requisito de diseño.
Una nota sobre la palabra “thinking”
Cuando decimos que un agente “piensa”, generalmente nos referimos a pasos computacionales: interpretar la entrada, planificar, elegir acciones, evaluar las salidas y actualizar el estado. Eso no implica la existencia de conciencia. Más precisamente, los agentes ejecutan ciclos iterativos de razonamiento y selección de acciones hacia un objetivo; “agente” describe el comportamiento y la arquitectura, no la experiencia.
La imagen completa en un solo ciclo
Juntos, estos elementos forman esta arquitectura: planificar, actuar a través de una herramienta, observar, verificar y luego continuar o detenerse.
USER
│
▼
┌─────────┐
│ GOAL │
└────┬────┘
↓
┌─────────────┐
│ AI / LLM │
└──────┬──────┘
↓
PLAN
↓
SELECT ACTION
↓
┌─────────────┼─────────────┐
↓ ↓ ↓
Search Python SQL
↓ ↓ ↓
└─────────────┼─────────────┘
↓
RESULT
↓
OBSERVE
↓
VERIFY
↓
Continue or Finish
Ese ciclo se encuentra en el centro de la mayoría de los sistemas agentes.
Hacia dónde va esto
Imagínese pidiéndole a su computadora su informe de investigación semanal, y un agente que gestiona toda la secuencia:
Open research sources
↓
Collect information
↓
Read documents
↓
Analyze data
↓
Create charts
↓
Write report
↓
Check errors
↓
Prepare final document
La computadora entonces coordina las aplicaciones en lugar de simplemente alojarlas. A largo plazo, el progreso se ve así:
Rule-Based Software
↓
Machine Learning
↓
Chatbots
↓
LLMs
↓
Tool-Using LLMs
↓
AI Agents
↓
Multi-Agent Systems
El cambio no se refiere solo a modelos más grandes, sino también a modelos que operan cada vez más con sistemas externos.
Puntos clave
Un chatbot le indica cómo podría analizar un conjunto de datos. Un sistema orientado a agentes podría encontrarlo, cargarlo, analizarlo, representarlo gráficamente, identificar problemas, redactar el informe, solicitar la aprobación y entregarlo:
Find the dataset
↓
Load it
↓
Analyze it
↓
Create visualizations
↓
Detect problems
↓
Write a report
↓
Ask for approval
↓
Deliver the result
La progresión va de responder, luego planificar, actuar, observar y verificar. Algunos puntos a tener en cuenta al diseñar cualquier agente:
- Es el bucle, no el modelo, lo que convierte a un sistema en un agente; límítele con restricciones de iteración, tiempo y presupuesto.
- Delegue tareas específicas como cálculos aritméticos, consultas y ejecución de código a herramientas, y describa esas herramientas con claridad.
- Verifique cada paso consecutivo mediante comprobaciones que no dependan de la evaluación del propio modelo.
Los agentes no son tanto máquinas que piensan como personas, sino sistemas que convierten un objetivo en acciones concretas. La pregunta clave no es cuán capaz es el modelo, sino qué está dispuesto a permitirle hacer.
Lecturas relacionadas
- Agentic AI Explicado: De los Modelos de Lenguaje a los Agentes Autónomos — Una explicación estructurada de cómo los LLM se transforman en sistemas agentes a través de herramientas, memoria, planificación, arquitecturas multiagente e integración MCP.
- Verificando qué hacen los agentes de IA: permisos, puertas de aprobación y niveles de riesgo — Aprenda por qué los agentes autónomos necesitan una mentalidad de verificación, y cómo el principio de mínimo privilegio, la aprobación humana y la autonomía basada en riesgos ayudan a contener sus errores.
- Marcas de agua textuales estadísticas vs credenciales C2PA en la salida de Claude — Entienda cómo funcionan las marcas de agua textuales basadas en SynthID de Claude y las credenciales de archivos C2PA, qué pueden demostrar los detectores y cómo evaluar cualquier herramienta que afirme eliminarlas.
- Construyendo agentes de IA sobre tus servicios y APIs existentes de .NET — Cómo los equipos de C# pueden transformar servicios y APIs existentes en herramientas de agentes reguladas, con las reglas de contexto, seguridad y observabilidad que los mantienen seguros.
- Lecciones de la portada Zig a Rust impulsada por IA de Bun: La verificación es el trabajo real — Qué enseña el paso de Zig a Rust asistido por agentes en Bun sobre los conjuntos de pruebas como contratos, guías de portabilidad, código inseguro y por qué la verificación ahora limita la programación con IA.