flowchart LR
A[Solicitud] --> B[Modelo o aplicación]
B --> C[Respuesta]
De responder a encargarse de una tarea
El salto desde una IA que produce una respuesta cuando se le pide hacia un sistema que mantiene un objetivo, selecciona pasos, utiliza recursos y sabe cuándo detenerse.
Hasta aquí hemos ido construyendo capacidades por capas. Aprendimos a formular instrucciones más precisas, convertirlas en templates, encapsular formas de trabajo en skills, incorporar conocimiento pertinente, conectar herramientas y organizar pasos mediante workflows y playbooks.
Todo eso permite hacer bastante.
Sin embargo, todavía podemos imaginar un usuario que dirige el trabajo paso a paso:
«Ahora revisa el contrato.»
«Ahora busca el DPA.»
«Ahora compara la cláusula de responsabilidad con nuestro estándar.»
«Ahora prepara las preguntas para el proveedor.»
El sistema ejecuta cada encargo. La persona mantiene el objetivo general y decide continuamente qué ocurre después.
La pregunta que abre esta sección es distinta:
¿Qué cambia cuando dejamos de pedir una respuesta o una acción aislada y encargamos al sistema una tarea que requiere varios pasos?
Ese cambio es el punto de entrada a los agentes.
Idea central
Responder significa producir una salida cuando se recibe una instrucción.
Encargarse de una tarea significa mantener un objetivo durante varias iteraciones, seleccionar qué pasos ejecutar, utilizar los recursos necesarios y reconocer cuándo corresponde terminar, detenerse o pedir ayuda.
La diferencia no consiste simplemente en que la IA sea «más inteligente». Consiste en una forma distinta de organizar el trabajo.
El punto de partida: una respuesta aislada
La interacción más familiar con un modelo de lenguaje tiene una estructura muy sencilla.
Una persona formula una petición:
Resume las principales obligaciones de confidencialidad de este contrato.
El sistema recibe la instrucción y el documento, genera una respuesta y termina.
Podemos representarlo así:
Este patrón es suficiente para una enorme cantidad de trabajo útil. No debemos tratar la agencia como el siguiente escalón obligatorio de toda aplicación de IA.
Si la tarea consiste en:
- corregir la redacción de un párrafo;
- resumir una sentencia;
- traducir una cláusula;
- extraer cinco fechas;
- proponer una primera versión de un correo;
probablemente no necesitamos un agente.
Existe una entrada relativamente clara, una transformación que queremos realizar y una salida que podemos revisar.
El problema aparece cuando el resultado de un paso determina qué debe hacerse después.
Cuando una respuesta deja de ser suficiente
Retomemos el caso conductor del sitio:
Llegó un contrato de un proveedor de IA. ¿Puede aprobarse?
Podemos pedir:
Revisa este contrato e identifica riesgos para el cliente.
Obtendremos una respuesta. Pero una revisión institucional completa puede requerir mucho más que producir un análisis inicial.
Tal vez el contrato menciona un DPA que no fue adjuntado.
Tal vez el DPA revela transferencias internacionales.
Tal vez la ficha del proveedor indica que el servicio será crítico.
Tal vez la política interna exige una revisión de seguridad que todavía no existe.
Tal vez la cláusula de propiedad intelectual parece aceptable, pero una definición ubicada en otro anexo cambia completamente su alcance.
En ese escenario, el trabajo real puede ser algo parecido a esto:
flowchart TD
A[Recibir contrato] --> B[Revisar documentos disponibles]
B --> C{¿Faltan anexos?}
C -- Sí --> D[Buscar o solicitar anexos]
C -- No --> E[Clasificar el caso]
D --> E
E --> F{¿Trata datos personales?}
F -- Sí --> G[Activar revisión de privacidad]
F -- No --> H[Continuar revisión general]
G --> I{¿Aparece riesgo alto?}
H --> I
I -- Sí --> J[Pedir revisión o aprobación]
I -- No --> K[Continuar análisis]
J --> L[Actualizar estado]
K --> L
L --> M{¿Expediente completo?}
M -- No --> B
M -- Sí --> N[Preparar resultado final]
Ahora ya no estamos describiendo una única respuesta.
Estamos describiendo una trayectoria de trabajo.
Y aparece una pregunta que antes resolvía continuamente la persona:
¿Cuál es el próximo paso?
La transición hacia un sistema agente comienza cuando parte de esa selección deja de ser proporcionada manualmente en cada turno y pasa a formar parte del funcionamiento del sistema.
Responder
Conviene conservar primero la categoría más simple.
Responder significa que el sistema recibe una instrucción local y produce una salida correspondiente a esa instrucción.
Por ejemplo:
Usuario: Extrae todas las cláusulas de terminación.
Sistema: identifica y devuelve las cláusulas.
Después:
Usuario: Ahora compara esas cláusulas con nuestra política interna.
Sistema: realiza la comparación.
Después:
Usuario: Ahora redacta preguntas para la contraparte.
La conversación puede durar veinte turnos y seguir siendo, en lo esencial, una secuencia dirigida por la persona.
Esto es importante porque duración no equivale a agencia.
Una conversación larga no se transforma automáticamente en agente.
Tampoco un prompt largo.
Tampoco una respuesta que contiene varios subtítulos y muchas operaciones aparentes.
La pregunta decisiva es otra:
¿Quién está manteniendo la tarea global y decidiendo qué debe ocurrir a continuación?
Mientras esa función permanezca principalmente en el usuario, seguimos cerca del paradigma de respuesta asistida.
Encargarse: mantener una finalidad a través del tiempo
Supongamos ahora que el encargo cambia:
Revisa el expediente contractual del proveedor y prepara todo lo necesario para que podamos decidir si el servicio puede aprobarse. Si falta información, identifica qué falta. Si encuentras un asunto que requiere autorización, detente y escálalo.
Aquí existe un elemento nuevo: el sistema no recibe solamente una operación local.
Recibe una misión o objetivo de nivel superior.
Google describe precisamente el cambio entre modelos utilizados para tareas discretas —responder una pregunta, traducir, generar contenido— y aplicaciones capaces de perseguir objetivos mediante múltiples pasos y acciones. En el marco pedagógico de este curso, nos interesa esa diferencia funcional, no adoptar sin matices ninguna taxonomía comercial concreta.
La tarea ya no es simplemente:
«genera X».
Se parece más a:
«lleva el trabajo desde este estado inicial hasta una condición de cierre válida».
Para hacerlo, el sistema necesita mantener alguna representación de:
- qué intenta conseguir;
- qué ha ocurrido hasta ahora;
- qué información tiene disponible;
- qué falta;
- qué acciones están permitidas;
- qué resultados obtuvo;
- qué condiciones obligan a detenerse.
Esas funciones serán desarrolladas en las páginas siguientes. Aquí importa solamente comprender el salto conceptual.
Mantener un objetivo
Un objetivo proporciona continuidad entre pasos diferentes.
Consideremos estas cinco operaciones:
- localizar el DPA;
- extraer las cláusulas de tratamiento de datos;
- compararlas con la política interna;
- identificar desviaciones;
- preparar preguntas para el proveedor.
Leídas aisladamente son tareas distintas.
Pero pueden formar parte del mismo objetivo:
Determinar si el régimen contractual de tratamiento de datos está suficientemente documentado para continuar con la aprobación del proveedor.
El objetivo permite responder por qué se ejecutan esos pasos y por qué algunos resultados obligan a cambiar de ruta.
El objetivo no es lo mismo que cada instrucción
Ésta es una distinción importante.
Una instrucción local podría ser:
Busca el DPA en la carpeta del expediente.
El objetivo global sigue siendo:
preparar una revisión suficiente para la decisión.
Si el DPA no aparece, repetir indefinidamente la misma búsqueda no cumple el objetivo.
El sistema necesita interpretar el resultado y cambiar de conducta:
«El DPA no está disponible. Debo registrar el faltante y solicitarlo o escalar.»
El objetivo funciona como referencia para evaluar si cada acción realmente produce avance.
Un objetivo debe permitir reconocer progreso
«Ayuda con contratos» es demasiado abierto para gobernar un sistema.
«Haz una buena revisión» tampoco define una condición reconocible.
Una formulación más operativa sería:
Preparar una matriz en la que todas las materias obligatorias estén clasificadas como revisadas, no aplicables o escaladas, y en la que cada hallazgo material esté vinculado con evidencia verificable.
Ahora existen estados observables.
El sistema puede preguntar:
- ¿se revisaron todas las materias?;
- ¿existen pendientes?;
- ¿hay evidencia?;
- ¿se alcanzó un punto de escalamiento?;
- ¿puede cerrarse la tarea?
La capacidad de mantener un objetivo depende, por tanto, de que ese objetivo sea suficientemente preciso para orientar el trabajo.
Elegir pasos
El siguiente cambio es más importante todavía.
Un workflow tradicional puede establecer de antemano:
Paso 1 → Paso 2 → Paso 3 → Paso 4O contener ramas explícitas:
si A → Paso 3
si B → Paso 4Esto puede ser completamente automatizado sin necesidad de introducir agencia.
Un agente aparece cuando el sistema dispone de un espacio de próximos pasos posibles y puede seleccionar entre ellos según lo que observa durante la ejecución.
En las clases del curso, la diferencia se resume así:
workflow: la ruta está diseñada de antemano;
agente: la ruta siguiente puede seleccionarse dinámicamente dentro de límites.
Un ejemplo simple
El sistema recibe un expediente con:
- contrato principal;
- propuesta comercial;
- DPA;
- documentación de seguridad.
Durante la revisión identifica que el contrato principal menciona un «AI Services Addendum» que no aparece en la carpeta.
¿Qué debería hacer?
Podrían existir varias acciones permitidas:
A. continuar ignorando el anexo
B. buscar el anexo en el repositorio
C. registrar que falta
D. preguntar al usuario
E. solicitarlo al proveedor
F. escalar el casoUn sistema gobernado no debería tener libertad irrestricta para cualquiera de ellas.
Podría estar autorizado a:
- buscar internamente;
- si no encuentra, registrar el faltante;
- preparar una solicitud;
- pedir aprobación antes de enviarla.
La agencia se encuentra en la posibilidad de seleccionar el próximo movimiento dentro de ese espacio autorizado.
Elegir no significa «hacer lo que quiera»
Éste será un principio transversal de toda la sección.
Podemos representar la autonomía como:
OBJETIVO
↓
ESPACIO DE ACCIONES PERMITIDAS
↓
SELECCIÓN SEGÚN CONTEXTO
↓
RESULTADONo como:
OBJETIVO
↓
HAZ CUALQUIER COSA HASTA CONSEGUIRLOEn un contexto jurídico, la segunda arquitectura sería especialmente problemática porque el objetivo nunca agota las restricciones relevantes.
Queremos revisar un contrato sin divulgar información confidencial.
Queremos completar un expediente sin inventar documentos ausentes.
Queremos acelerar el proceso sin saltar aprobaciones institucionales.
Queremos obtener una respuesta sin convertir una recomendación automática en una decisión jurídicamente autorizada.
Por tanto, el agente persigue un objetivo dentro de límites.
Utilizar recursos
Un sistema que sólo puede generar texto dispone de un espacio de actuación limitado.
Para encargarse de tareas reales suele necesitar recursos externos.
En páginas anteriores ya estudiamos por separado knowledge, RAG, tools, APIs, connectors y MCP. No necesitamos reconstruirlos aquí.
El punto nuevo es otro:
el sistema puede seleccionar cuándo utilizar un recurso y qué hacer con su resultado.
Supongamos que dispone de estas capacidades:
| Recurso | Función |
|---|---|
| Repositorio contractual | localizar documentos del expediente |
| Buscador jurídico | recuperar fuentes autorizadas |
| Extractor | localizar cláusulas específicas |
| Comparador | contrastar versiones o textos |
| Sistema de tickets | registrar pendientes |
| Correo | preparar o enviar comunicaciones |
En una interacción manual, el usuario podría ordenar una por una esas operaciones.
En una arquitectura agente, el sistema puede recibir una finalidad y decidir, por ejemplo:
«Necesito saber si la política de retención del proveedor está documentada. Primero revisaré el DPA. Si no aparece, buscaré la política de privacidad. Si la información sigue siendo insuficiente, registraré una pregunta pendiente.»
Aquí la herramienta no es el agente.
La herramienta proporciona una capacidad.
La agencia aparece en la selección y coordinación de capacidades orientadas al objetivo.
Una analogía útil: herramientas como manos
La analogía ayuda porque permite separar dos funciones:
- el modelo puede seleccionar o formular qué hacer;
- las herramientas permiten ejecutar determinadas operaciones sobre información o sistemas externos.
Pero la analogía deja de servir si imaginamos que el modelo controla directamente esas «manos» sin intermediación. En sistemas reales pueden existir validaciones, permisos, reglas de orquestación y aprobaciones entre la selección de una acción y su ejecución efectiva.
Cada recurso amplía también el riesgo
Añadir herramientas no sólo aumenta capacidad.
También aumenta la superficie de error.
Existe una diferencia enorme entre permitir que un sistema:
busque un documento;
y permitir que:
envíe un correo a una contraparte.
También existe una diferencia entre:
preparar una modificación de una ficha;
y:
aplicar directamente esa modificación.
Por eso una arquitectura agente no puede evaluarse mirando solamente «qué sabe hacer».
Debemos preguntar también:
- qué recursos tiene habilitados;
- cuáles son de lectura y cuáles producen efectos;
- qué datos pueden recibir;
- qué operaciones son reversibles;
- qué acciones requieren autorización;
- qué ocurre cuando una herramienta falla.
Esta separación entre capacidad y permiso se volverá central más adelante.
Saber cuándo detenerse
Una respuesta aislada tiene una condición de término relativamente sencilla: el modelo termina de generar.
Una tarea de varias iteraciones tiene un problema mucho más difícil.
¿Cuándo debe dejar de actuar el sistema?
Un agente sin buenas condiciones de término puede:
- repetir búsquedas;
- ejecutar pasos innecesarios;
- gastar recursos;
- continuar sobre supuestos incorrectos;
- intentar resolver por sí mismo cuestiones que requieren una persona;
- actuar sobre información insuficiente.
Chip Huyen advierte precisamente sobre el costo de ejecutar planes extensos o defectuosos sin supervisión: un sistema puede continuar durante numerosos pasos aunque el plan inicial no conduzca realmente al objetivo. Por eso planificación, ejecución, validación y condiciones de término deben tratarse como problemas de diseño, no como consecuencias automáticas de disponer de un buen modelo.
Terminar porque el objetivo está cumplido
La condición más evidente es:
se alcanzó el estado deseado.
En nuestro caso:
✓ documentos obligatorios revisados
✓ hallazgos vinculados con evidencia
✓ pendientes identificados
✓ escalaciones resueltas o registradas
✓ matriz final preparadaEntonces el sistema puede cerrar.
Detenerse porque falta información
Supongamos que la decisión depende del DPA y no existe acceso al documento.
La conducta correcta puede ser:
«No puedo completar esta parte. Falta el DPA.»
No:
«Seguiré intentando inferir qué probablemente dice.»
En trabajo jurídico, la abstención frente a evidencia insuficiente puede ser una función de calidad.
Detenerse porque aparece una contradicción
Contrato principal:
el proveedor elimina los datos al término.
DPA:
ciertos registros pueden conservarse durante un período adicional.
Un sistema puede detectar la tensión.
Pero el diseño puede establecer que no debe resolverla silenciosamente si la interpretación afecta materialmente la decisión.
Debe:
- identificar la contradicción;
- mostrar ambas fuentes;
- explicar su relevancia;
- pedir revisión o escalamiento.
Detenerse porque se requiere autoridad
Éste es uno de los criterios más importantes.
El agente puede llegar a una conclusión preliminar:
«La desviación parece aceptable porque el impacto es bajo.»
Pero el procedimiento institucional puede exigir aprobación de un abogado senior.
La acción válida del agente no es:
aprobar.
Es:
preparar antecedentes y solicitar aprobación.
Detenerse por límites operativos
También pueden existir límites puramente técnicos o económicos:
- máximo de búsquedas;
- máximo de iteraciones;
- presupuesto de cómputo;
- tiempo de ejecución;
- cantidad de documentos;
- fallo repetido de una herramienta.
Estos límites evitan que «seguir intentando» se convierta en una conducta indefinida.
Pedir ayuda puede ser el resultado correcto
Un buen agente no es el que siempre consigue terminar solo.
Es el que distingue entre:
- situaciones donde puede continuar;
- situaciones donde necesita más información;
- situaciones donde debe pedir autorización;
- situaciones donde corresponde escalar;
- situaciones donde debe detenerse.
La capacidad de abstenerse es parte del diseño.
De una conversación controlada a una arquitectura agente
Las clases anteriores ya prepararon este salto.
En prompting avanzado aprendimos a trabajar por etapas:
planificar
→ ejecutar etapa 1
→ revisar
→ preguntar si continuamos
→ ejecutar etapa 2En ese esquema, la persona mantiene el control entre pasos.
Después aprendimos workflows y playbooks:
entrada
→ estados
→ condiciones
→ ramas
→ aprobaciones
→ cierreAhora aparece un problema adicional:
¿qué ocurre cuando no podemos anticipar suficientemente todas las rutas y necesitamos que el sistema seleccione dinámicamente entre próximos pasos permitidos?
Ésa es la función que abre la arquitectura agente.
Podemos resumir la progresión así:
flowchart LR
A[Prompt\nqué hacer] --> B[Skill\ncómo hacerlo]
B --> C[Tool\ncon qué actuar]
C --> D[Workflow\nen qué orden]
D --> E[Playbook\nqué ramas y criterios]
E --> F[Agent\nqué paso elegir ahora]
El diagrama no pretende describir una evolución tecnológica obligatoria. Es la secuencia pedagógica del curso.
Un agente puede utilizar prompts, skills, knowledge, tools, workflows y playbooks. No los reemplaza.
Los coordina de otra manera.
Un ejemplo completo: revisar un proveedor de IA
Veamos la diferencia de principio a fin.
Escenario A: asistente dirigido
La persona escribe:
Extrae las cláusulas sobre datos.
Después:
Compáralas con esta política.
Después:
Busca en el DPA si existe una regla sobre retención.
Después:
Prepara una lista de preguntas.
El sistema realiza trabajo útil.
Pero la persona conserva:
- el objetivo completo;
- el orden;
- la selección de recursos;
- la evaluación de progreso;
- la decisión de terminar.
Escenario B: workflow
La organización codifica:
1. cargar contrato
2. extraer cláusulas
3. comparar con estándar
4. generar preguntas
5. enviar a revisiónExiste automatización.
Pero la ruta está predeterminada.
Escenario C: agente acotado
El sistema recibe:
Prepara el expediente de revisión del proveedor de IA según el playbook interno. Puedes buscar documentos dentro del repositorio del expediente y ejecutar las skills de revisión habilitadas. No puedes enviar comunicaciones externas ni aprobar excepciones. Detente cuando falte evidencia material o cuando una desviación requiera aprobación.
Durante la ejecución:
- observa que existe contrato y DPA, pero falta SLA;
- decide que puede comenzar revisión contractual mientras busca el SLA;
- utiliza el repositorio;
- encuentra una versión del SLA, pero detecta que es anterior a la fecha del contrato;
- no la trata automáticamente como vigente;
- registra el faltante;
- continúa con materias que sí tienen evidencia suficiente;
- detecta una desviación alta de responsabilidad;
- prepara el antecedente;
- solicita intervención humana;
- espera antes de continuar con la decisión afectada.
Aquí aparecen las cinco funciones de esta página:
Responder: sigue produciendo salidas locales.
Mantener un objetivo: conserva la finalidad general del expediente.
Elegir pasos: decide qué acción corresponde según lo observado.
Utilizar recursos: selecciona herramientas y capacidades autorizadas.
Saber cuándo detenerse: reconoce evidencia insuficiente y puntos de aprobación.
«Encargarse» no equivale a «ser responsable»
La expresión puede inducir a error si la interpretamos en sentido jurídico o moral.
Decir que el sistema «se encarga de una tarea» describe aquí una propiedad operacional: mantiene una finalidad y coordina pasos.
No significa que asuma responsabilidad profesional.
Tampoco que adquiera competencia institucional.
Tampoco que pueda representar jurídicamente a una persona.
Tampoco que deba adoptar la decisión final.
Esta separación es especialmente importante en Derecho porque el vocabulario cotidiano de agencia —decidir, actuar, encargarse, recordar— puede sonar muy próximo al vocabulario de la responsabilidad humana.
En esta sección utilizaremos esos verbos de manera funcional, pero mantendremos siempre la distinción:
CAPACIDAD TÉCNICA
qué puede hacer
PERMISO
qué está autorizado a hacer
SELECCIÓN OPERACIONAL
qué puede elegir dentro del sistema
RESPONSABILIDAD
quién responde jurídicamente o institucionalmenteUn agente puede ampliar las tres primeras capas sin convertirse en sujeto de la cuarta.
Qué cambia en la evaluación
Cuando sólo pedimos una respuesta, podemos comenzar evaluando esa respuesta.
Cuando encargamos una tarea, la salida final deja de ser suficiente.
Supongamos que dos sistemas entregan exactamente la misma conclusión:
«El proveedor presenta un riesgo alto de continuidad.»
El primero llegó así:
contrato
→ identificó SLA
→ comparó disponibilidad
→ detectó ausencia de créditos suficientes
→ verificó dependencia crítica
→ clasificó riesgo altoEl segundo:
contrato
→ no encontró SLA
→ supuso un nivel de servicio habitual
→ produjo riesgo altoLa conclusión coincide.
La trayectoria no.
Esto introduce una consecuencia que desarrollaremos más adelante:
en sistemas agentes debemos evaluar no sólo qué resultado produjeron, sino también cómo llegaron a él.
La trayectoria comienza a convertirse en objeto de control.
Qué puede salir mal en este primer salto
Antes de estudiar arquitecturas más complejas conviene reconocer cuatro errores.
Confundir multietapa con agente
Una secuencia de cinco prompts puede ser simplemente una secuencia.
La existencia de varias etapas no demuestra decisión dinámica.
Confundir herramientas con agencia
Un sistema que puede buscar o escribir dispone de tools.
No necesariamente decide por sí mismo cuándo utilizarlas.
Confundir automatización con autonomía
Un workflow puede ejecutar veinte pasos sin intervención humana y seguir una ruta completamente predeterminada.
Automático no significa agente.
Confundir autonomía con ausencia de límites
Un agente útil no necesita tener acceso irrestricto.
En contextos profesionales suele ser preferible lo contrario: autonomía localizada dentro de un perímetro claro.
Una fórmula de trabajo
Podemos condensar la intuición de esta página en una secuencia sencilla:
RESPONDER
produce una salida
↓
ENCARGARSE
mantiene un objetivo
↓
ELEGIR
selecciona el próximo paso
↓
ACTUAR
utiliza recursos permitidos
↓
CONTROLARSE
termina, se abstiene o pide ayuda cuando correspondeEl agente no elimina las capacidades anteriores.
Las coloca dentro de un ciclo orientado a objetivos.
Por qué importa para el trabajo jurídico
En trabajo jurídico existen numerosos encargos que no consisten en producir un único texto, sino en llevar un asunto desde un estado a otro:
- intake de una consulta;
- revisión de un proveedor;
- due diligence;
- investigación jurídica;
- preparación de un expediente regulatorio;
- comparación de versiones;
- gestión de incidentes;
- control de cumplimiento;
- preparación de un proceso de aprobación.
Estas tareas contienen decisiones sobre orden, suficiencia, evidencia, escalamiento y cierre.
Precisamente por eso son candidatas a incorporar capacidades agentes.
Pero la misma característica que las vuelve interesantes hace necesario gobernarlas.
Si el sistema puede decidir qué investigar, también puede investigar lo equivocado.
Si puede elegir herramientas, también puede elegir mal.
Si puede continuar sin instrucciones nuevas, también puede continuar cuando debería detenerse.
Si puede actuar, también puede producir efectos que ya no son meramente textuales.
La pregunta profesional no será entonces:
«¿Puede usar agentes el equipo jurídico?»
Sino:
«¿Qué parte del trabajo queremos que el sistema mantenga, seleccione y ejecute por sí mismo, y qué parte debe seguir sometida a reglas, evidencia y autoridad humana?»
Qué debes recordar
El salto hacia agentes comienza antes de cualquier arquitectura sofisticada.
Comienza cuando cambiamos la unidad de trabajo.
En lugar de pensar únicamente:
instrucción → respuesta
empezamos a pensar:
objetivo → pasos → recursos → observaciones → nuevos pasos → condición de cierre
Responder sigue siendo útil y suficiente para muchas tareas.
Encargarse de una tarea exige algo más: continuidad del objetivo, selección de pasos, acceso a medios y reglas para terminar o pedir ayuda.
La diferencia crítica no es cuántas palabras genera el sistema ni cuánto dura la conversación.
Es quién determina el siguiente paso y bajo qué límites.
El problema que todavía queda abierto
Ya tenemos la intuición fundamental.
Un agente no se limita a contestar una instrucción aislada: mantiene una tarea y puede avanzar mediante varias decisiones y acciones.
Pero todavía estamos utilizando la palabra agente de manera funcional.
Necesitamos ahora precisar su arquitectura mínima.
¿Qué elementos debe tener para que tenga sentido hablar de un agente?
¿Cómo se relacionan objetivo, contexto, medios, ciclo de trabajo y control?
Eso es exactamente lo que aborda la página siguiente: qué es un agente.