flowchart LR
A[Objetivo] --> B[Observar contexto]
B --> C[Seleccionar próximo paso]
C --> D[Actuar]
D --> E[Observar resultado]
E --> F{¿Qué corresponde ahora?}
F -- continuar --> C
F -- terminar --> G[Cierre]
F -- escalar --> H[Intervención humana]
Qué es un agente
Una definición operativa para comprender un sistema que persigue un objetivo mediante contexto, medios, un ciclo de trabajo y controles.
En la página anterior cambiamos la unidad de análisis.
Dejamos de mirar solamente una interacción del tipo:
instrucción → respuesta
para empezar a observar tareas en las que el sistema debe conservar una finalidad durante varios pasos.
Eso nos permite formular la pregunta central de esta página:
¿Qué es exactamente un agente?
La palabra se utiliza hoy con significados bastante diferentes. Algunas empresas llaman agente a cualquier chatbot que utiliza un modelo de lenguaje. Otras reservan el término para sistemas que pueden usar herramientas. Otras exigen planificación, memoria, autonomía o capacidad de actuar sobre sistemas externos.
Para aprender necesitamos una definición suficientemente estable sin convertirla en una afirmación universal sobre toda la industria.
Idea central
En el marco pedagógico de este sitio, un agente es una aplicación que utiliza uno o más modelos de IA dentro de un ciclo para perseguir un objetivo.
Para comprenderlo necesitamos observar cinco elementos:
objetivo + contexto + medios + ciclo de trabajo + control.
La presencia de un modelo potente no basta. La agencia aparece en la organización del sistema alrededor de una finalidad y de la selección iterativa de acciones o próximos pasos.
Una definición operacional
Podemos formular la idea completa así:
Un agente es un sistema orientado a un objetivo que observa su estado y contexto, selecciona próximos pasos, utiliza capacidades o herramientas disponibles, interpreta los resultados y continúa hasta cumplir una condición de término o hasta que deba escalar.
Esta definición es deliberadamente funcional.
No intenta decir que el sistema «piensa» como una persona, que comprende jurídicamente una situación o que posee voluntad propia.
Describe lo que debemos poder observar en la arquitectura.
Google resume una idea próxima al caracterizar un agente como una aplicación orientada a objetivos que integra modelo, herramientas y una capa de orquestación y utiliza el modelo de manera iterativa. Las clases del curso adoptan esa intuición, pero agregan un énfasis especial en límites, evidencia, permisos y revisión humana, porque en trabajo jurídico la pregunta no es solamente si el sistema puede avanzar, sino bajo qué condiciones puede hacerlo de forma gobernable.
Cinco preguntas para reconocer un agente
Antes de entrar en cada elemento, podemos utilizar una prueba sencilla.
Frente a una aplicación, pregunte:
| Pregunta | Qué intenta identificar |
|---|---|
| ¿Qué intenta conseguir? | objetivo |
| ¿Qué información utiliza para decidir? | contexto |
| ¿Qué puede hacer para avanzar? | medios |
| ¿Cómo pasa de un paso al siguiente? | ciclo de trabajo |
| ¿Qué limita, valida o detiene sus acciones? | control |
Si no podemos responder ninguna de estas preguntas, probablemente todavía conocemos demasiado poco sobre el sistema.
Si sólo podemos responder:
«usa un modelo de lenguaje»
conocemos un componente, no la arquitectura agente.
Objetivo
El objetivo es la finalidad que mantiene unida la secuencia de trabajo.
Una aplicación de chat puede recibir:
Resume este contrato.
La tarea es local y termina cuando produce el resumen.
Un agente puede recibir algo como:
Prepara la revisión del expediente contractual del proveedor y deja identificado todo aquello que requiera decisión humana antes de la aprobación.
La diferencia no está simplemente en la longitud de la instrucción.
El segundo encargo describe un estado que el sistema debe intentar alcanzar.
Objetivo versus acción
Conviene separar dos niveles:
OBJETIVO
Preparar un expediente completo para decisión
ACCIONES POSIBLES
buscar anexo
extraer cláusula
comparar estándar
registrar hallazgo
pedir aprobaciónEl objetivo responde:
¿para qué se ejecutan estas operaciones?
Las acciones responden:
¿qué puede hacerse ahora para avanzar?
Un agente puede cambiar de acción sin cambiar de objetivo.
Por ejemplo, esperaba encontrar un DPA en la carpeta principal. No aparece. Entonces cambia el próximo paso: busca en otro repositorio autorizado o registra el documento como faltante.
El objetivo permanece.
Un objetivo útil debe tener una frontera
Objetivos excesivamente abiertos producen sistemas difíciles de gobernar.
Comparemos:
Ayuda a resolver todo lo relacionado con proveedores.
con:
Prepara una matriz de revisión para cada proveedor recibido, utilizando el playbook vigente, y detén el proceso cuando falte información material o se alcance un punto de aprobación humana.
La segunda formulación define:
- un tipo de tarea;
- un resultado;
- un ámbito;
- condiciones de abstención.
Eso hace posible evaluar el comportamiento.
Objetivo no significa autorización
Este punto debe quedar claro desde el comienzo.
Si el objetivo es:
conseguir que el contrato sea aprobado,
el sistema no adquiere por ello permiso para:
- modificar el contrato;
- aceptar una desviación;
- contactar a la contraparte;
- omitir un control;
- registrar una aprobación.
La finalidad no agota las reglas de conducta.
En arquitectura agente, objetivo y restricciones deben coexistir.
Contexto
Para seleccionar un siguiente paso, el sistema necesita información sobre la situación actual.
A esa información la llamaremos contexto.
Puede incluir:
- la solicitud original;
- instrucciones del sistema;
- documentos adjuntos;
- resultados de herramientas;
- estado del expediente;
- criterios internos;
- historial relevante;
- información recuperada desde fuentes autorizadas;
- datos sobre acciones ya realizadas.
El contexto responde:
¿Qué sabe operacionalmente el sistema en este momento para decidir qué hacer después?
El contexto cambia durante la ejecución
Ésta es una diferencia importante frente a imaginar un prompt estático.
Al comienzo:
Contrato: disponible
DPA: desconocido
SLA: desconocido
Riesgo: no clasificadoDespués de buscar:
Contrato: disponible
DPA: disponible
SLA: no encontrado
Riesgo privacidad: medio
Riesgo continuidad: pendienteDespués de una revisión humana:
Contrato: disponible
DPA: disponible
SLA: no encontrado
Riesgo privacidad: aceptado con condición
Riesgo continuidad: escaladoEl agente no sólo recibe información. Actualiza el estado de la tarea a medida que obtiene resultados.
Contexto no significa memoria ilimitada
No debemos anticipar todavía la página específica sobre sesión, RAG y memoria, pero sí proteger una distinción.
Que un sistema utilice contexto no significa que conserve indefinidamente todo lo que ha visto.
Puede existir:
- contexto temporal para el paso actual;
- estado de la sesión;
- información recuperada bajo demanda;
- memoria persistente, si la aplicación la implementa.
No son lo mismo.
Por ahora basta con esta regla:
el agente necesita recibir el contexto relevante para cada decisión, pero no necesita ni debería necesariamente conservar toda la información para siempre.
Medios
El objetivo dice hacia dónde ir.
El contexto describe la situación.
Los medios determinan qué puede hacer el sistema para avanzar.
En una aplicación sencilla, los medios pueden limitarse a generar texto.
En un agente más conectado pueden incluir:
- buscadores;
- acceso a archivos;
- RAG;
- bases de datos;
- APIs;
- herramientas de cálculo;
- sistemas documentales;
- funciones para crear registros;
- conectores con aplicaciones;
- otros agentes especializados.
Medio no equivale a herramienta técnica específica
Para un usuario no técnico resulta útil comenzar por la función.
En vez de pensar:
endpoint
/contracts/query
pensamos:
buscar documentos del expediente.
En vez de:
llamada
POST /ticket/create
pensamos:
registrar un pendiente.
La implementación técnica puede cambiar.
La capacidad funcional permanece reconocible.
Los medios delimitan el espacio de acción
Un agente que sólo puede leer archivos y preparar borradores tiene un perfil de riesgo distinto de uno que puede:
- enviar mensajes;
- modificar bases de datos;
- aprobar solicitudes;
- ejecutar pagos;
- cambiar permisos.
Por eso, cuando alguien afirma:
«Nuestro agente puede actuar»
la pregunta correcta es:
¿Qué acciones concretas están disponibles y cuáles producen efectos fuera del propio sistema?
Tener un medio no significa poder usarlo siempre
Supongamos que el agente dispone de una herramienta de correo.
Podría existir esta política:
preparar borrador → permitido
mostrar borrador → permitido
enviar internamente → requiere aprobación
enviar a contraparte → requiere aprobación expresaLa herramienta define una capacidad.
El control define su uso legítimo.
Ciclo de trabajo
El agente no realiza necesariamente todo el encargo en una sola operación.
Trabaja mediante un ciclo.
Una forma pedagógica de representarlo es:
Google describe este patrón como un proceso que parte de una misión, observa el entorno, selecciona o planifica, actúa y vuelve a observar. Las clases UDD lo condensan en una secuencia muy útil para principiantes:
observar → decidir → actuar → evaluar → continuar o pedir ayuda.
La página siguiente dedicada al bucle desarrollará cada etapa.
Aquí importa comprender por qué el ciclo pertenece a la definición.
El resultado de una acción se convierte en nueva entrada
Ejemplo:
- el agente busca el SLA;
- la herramienta devuelve dos documentos;
- uno corresponde al proveedor correcto y otro a un servicio distinto;
- el sistema debe evaluar cuál es pertinente;
- después decide si ya dispone de información suficiente.
No basta con llamar una herramienta.
El resultado debe reingresar en la tarea.
La trayectoria puede cambiar
Un workflow fijo podría decir:
buscar SLA → revisar SLA → emitir conclusiónPero el agente puede observar:
«El documento encontrado está vencido.»
Entonces la trayectoria razonable cambia:
buscar SLA
→ verificar vigencia
→ detectar versión antigua
→ buscar versión actual
→ si no existe, registrar faltanteLa iteración permite adaptación contextual.
Control
El quinto elemento evita una lectura equivocada de los cuatro anteriores.
Un agente no es un objetivo que puede utilizar cualquier medio hasta conseguirlo.
Debe existir control.
El control responde preguntas como:
- ¿qué está permitido?;
- ¿qué acciones están prohibidas?;
- ¿qué requiere aprobación?;
- ¿qué fuentes pueden utilizarse?;
- ¿qué debe registrarse?;
- ¿qué ocurre cuando hay incertidumbre?;
- ¿cuándo se detiene el sistema?;
- ¿cómo se revisa la trayectoria?;
- ¿quién puede modificar la configuración?
Controles dentro y fuera del modelo
Podemos escribir una instrucción:
No envíes comunicaciones externas sin aprobación.
Eso es útil.
Pero si la regla es crítica, puede ser insuficiente confiar únicamente en que el modelo la siga.
La aplicación puede implementar un control más fuerte:
flowchart LR
A[Agente propone envío] --> B{¿Existe aprobación?}
B -- Sí --> C[Herramienta habilitada]
B -- No --> D[Envío bloqueado]
La diferencia es importante.
Una instrucción intenta orientar la generación.
Un control de arquitectura puede impedir una acción.
Control no es lo contrario de agencia
Puede parecer que cuanto más control existe, menos «agente» es el sistema.
Esa conclusión es equivocada.
La agencia útil puede ser local.
Por ejemplo, el sistema puede decidir libremente —dentro de tres opciones autorizadas— qué documento consultar primero, mientras la aprobación final permanece completamente fuera de su alcance.
El grado de autonomía puede variar por acción.
Esto será desarrollado más adelante en la escala de autonomía y en permisos.
Cómo se combinan los cinco elementos
Retomemos el caso del proveedor de IA.
Objetivo
Preparar expediente suficiente para decisión de aprobación.
Contexto
Contrato, DPA, SLA, ficha del proveedor, playbook, resultados de revisiones y estado de pendientes.
Medios
Buscar documentos, leer, extraer cláusulas, comparar con estándar, crear registro, preparar borrador de preguntas.
Ciclo de trabajo
Observar → seleccionar revisión → ejecutar herramienta → evaluar resultado → actualizar estado → continuar.
Control
No enviar comunicaciones, no aprobar excepciones, no inventar evidencia, escalar riesgos altos, registrar decisiones.
Podemos representarlo así:
flowchart TD
O[Objetivo] --> C[Contexto actual]
C --> S[Selección de próximo paso]
M[Medios disponibles] --> S
S --> A[Acción]
A --> R[Resultado]
R --> C
K[Controles] -. limitan .-> S
K -. limitan .-> A
K -. definen cierre .-> C
El agente no es ninguno de esos componentes por separado.
Es la arquitectura que los coordina.
El modelo sigue siendo sólo una pieza
Aquí conviene recuperar una distinción aprendida al comienzo del sitio.
MODELO ≠ SISTEMA ≠ APLICACIÓN.
Un agente tampoco debe confundirse con el modelo.
Podemos utilizar el mismo modelo en:
- un chatbot;
- un clasificador asistido;
- un workflow;
- un agente con herramientas;
- un sistema multiagente.
Lo que cambia es la arquitectura que lo rodea.
Las clases lo expresan de forma especialmente clara:
un agente no es «una IA más inteligente»; es una forma distinta de organizar el trabajo.
El modelo puede ser más o menos capaz, pero la agencia depende también de:
- estado;
- herramientas;
- orquestación;
- permisos;
- ciclos;
- condiciones de término.
Agente y workflow: una frontera que conviene anticipar sin resolver todavía
Sabemos que ambos organizan trabajo.
Pero no son equivalentes.
Un workflow puede ejecutar automáticamente una ruta predeterminada.
Un agente puede seleccionar la ruta siguiente de manera contextual dentro de límites.
Comparemos:
WORKFLOW
Si falta DPA → solicitar DPA
Si existe DPA → revisar DPAcon:
AGENTE
Observa qué información falta.
Selecciona entre buscar, revisar, registrar, preguntar o escalar
según el estado y los medios permitidos.La diferencia no está en que uno sea manual y el otro automático.
Está en dónde se encuentra la decisión sobre el siguiente paso.
La comparación completa tendrá su propia página.
Un poco más de detalle técnico: el agente como sistema con estado
Un lector no programador puede imaginar un agente como una aplicación que mantiene una pequeña ficha actualizada de la tarea.
Por ejemplo:
OBJETIVO
Preparar revisión de proveedor
ESTADO
Contrato: revisado
DPA: revisado
SLA: faltante
Seguridad: pendiente
Privacidad: riesgo medio
Aprobación negocio: pendiente
ACCIONES DISPONIBLES
buscar documento
leer documento
comparar criterio
crear pendiente
preparar borrador
pedir aprobación
SIGUIENTE PASO SELECCIONADO
crear pendiente por SLA faltanteLa representación real puede ser mucho más compleja y utilizar bases de datos, objetos estructurados, servicios externos u otros mecanismos.
Pero esta versión captura la intuición suficiente:
el sistema necesita saber dónde está para poder seleccionar qué hacer después.
Sin alguna forma de estado, el agente podría:
- repetir acciones;
- olvidar resultados;
- reabrir tareas cerradas;
- perder dependencias;
- actuar sobre información desactualizada.
Qué no debemos exigir a la definición
Una buena definición introductoria también necesita límites.
No toda aplicación agente tiene que:
- usar múltiples modelos;
- tener memoria de largo plazo;
- ser multiagente;
- navegar por internet;
- ejecutar código;
- modificar sistemas;
- operar sin intervención humana;
- planificar durante decenas de pasos.
Ésos son posibles diseños, no requisitos universales.
Podemos tener un agente muy acotado que:
- recibe un contrato;
- determina qué revisión corresponde;
- utiliza dos herramientas de lectura;
- prepara una matriz;
- se detiene ante cualquier acción externa.
Sigue existiendo selección dinámica y ciclo orientado a objetivos.
Por qué esta definición sirve a un abogado
La utilidad de la definición no está en discutir etiquetas.
Está en permitir preguntas concretas.
Si un proveedor dice:
«Nuestra plataforma incorpora agentes jurídicos autónomos.»
podemos traducir inmediatamente:
Objetivo
¿Qué misión reciben?
Contexto
¿Qué información pueden ver?
Medios
¿Qué herramientas y sistemas pueden utilizar?
Ciclo
¿Cómo deciden qué hacer después y cuántas iteraciones pueden ejecutar?
Control
¿Qué no pueden hacer, qué requiere aprobación y qué queda registrado?
La expresión comercial deja de ser una caja negra.
La arquitectura comienza a ser interrogable.
Qué debes recordar
Para este sitio, un agente es una aplicación que utiliza un modelo de IA dentro de un ciclo para perseguir un objetivo.
La definición se vuelve útil cuando la descomponemos:
OBJETIVO
qué intenta conseguir
CONTEXTO
qué información utiliza ahora
MEDIOS
qué puede hacer para avanzar
CICLO
cómo observa, actúa y vuelve a decidir
CONTROL
qué limita, valida, registra o detiene su actuaciónNinguno de estos elementos implica conciencia ni autoridad profesional.
La agencia describe una arquitectura de trabajo.
El problema que todavía queda abierto
Ya tenemos una definición operacional.
Pero el vocabulario de agentes invita fácilmente a exageraciones.
Decimos que un sistema «decide», «recuerda», «actúa» o «persigue objetivos», y esas expresiones pueden hacernos atribuirle propiedades que la arquitectura no demuestra.
Antes de estudiar el bucle en detalle necesitamos construir una defensa conceptual.
La página siguiente aborda precisamente qué NO es un agente: no es una persona, no es autoridad, no es magia y no implica autonomía ilimitada.