flowchart LR
A["Prompt<br/>instrucción"] --> B["Template<br/>reutilización"]
B --> C["Skill<br/>metodología"]
C --> D["Knowledge / RAG<br/>información pertinente"]
D --> E["Tool / API / Connector / MCP<br/>acceso y acción"]
E --> F["Workflow<br/>secuencia y estados"]
F --> G["Playbook<br/>criterios y ramas"]
G --> H["Agent<br/>selección dinámica"]
Del prompt al sistema
Cómo las capas aprendidas durante el recorrido se acumulan hasta formar un sistema de trabajo: de una instrucción puntual a una arquitectura capaz de organizar información, acciones y decisiones.
A lo largo del recorrido hemos ido resolviendo problemas distintos.
Primero aprendimos a instruir. Después vimos que una buena instrucción podía reutilizarse, que una metodología podía encapsularse, que el sistema necesitaba información pertinente, que podía conectarse con herramientas y que el trabajo podía organizarse mediante procesos y criterios. Finalmente apareció la posibilidad de que una aplicación seleccionara dinámicamente qué hacer a continuación.
Vistos por separado, estos conceptos pueden parecer un vocabulario técnico:
Prompt
Template
Skill
Knowledge
RAG
Tool
API
Connector
MCP
Workflow
Playbook
AgentLa última sección conceptual del handbook tiene otra tarea: volver a unir las piezas.
La pregunta ya no es qué significa cada término. Esa pregunta fue respondida en sus páginas correspondientes.
Ahora queremos entender algo más importante:
¿Qué cambia cuando esas piezas se combinan para formar un sistema de trabajo?
Retomemos el caso conductor. Llega un contrato de un proveedor de IA y alguien necesita preparar la decisión de aprobación.
Al comienzo de este curso habríamos pensado principalmente en la calidad de la respuesta:
Revisa este contrato e identifica los principales riesgos.Al final del recorrido podemos ver que la tarea real es bastante más amplia. Puede ser necesario comprobar si llegaron todos los anexos, identificar qué metodología aplicar, localizar políticas internas, recuperar criterios pertinentes, consultar otros sistemas, registrar hallazgos, ordenar etapas, activar una ruta distinta según el riesgo y detenerse cuando hace falta una aprobación humana.
La instrucción sigue siendo necesaria.
Pero ya no es el sistema completo.
Idea central
La evolución desde un prompt hasta un agente no consiste en reemplazar conceptos anteriores por conceptos más sofisticados.
Consiste en acumular propiedades.
Una buena instrucción no desaparece. Se convierte en una pieza dentro de un sistema que además puede reutilizar metodología, aportar información, ejecutar acciones, organizar secuencias y seleccionar próximos pasos.
Una lectura acumulativa
La arquitectura pedagógica de este handbook puede resumirse así:
Esta cadena no debe interpretarse como una clasificación universal de la industria. Distintos proveedores utilizan términos distintos, combinan capas que aquí hemos separado o llaman de otra manera a capacidades parecidas.
La secuencia tiene una función pedagógica: mostrar que cada nueva abstracción aparece porque la anterior deja un problema sin resolver.
Por eso la arquitectura se entiende mejor preguntando, en cada transición:
¿Qué podíamos hacer antes y qué todavía no podíamos hacer?
Del prompt a la template: de una ejecución a una instrucción reutilizable
Con un prompt podemos especificar una tarea.
Por ejemplo:
Revisa este contrato desde la perspectiva del cliente.
Identifica cláusulas que afecten datos, propiedad intelectual,
responsabilidad, continuidad y terminación.
Para cada hallazgo indica evidencia e información faltante.La instrucción puede funcionar muy bien.
Pero si mañana llegan otros veinte contratos, surge un problema nuevo. No queremos reconstruir manualmente la misma arquitectura de instrucciones, ni depender de que cada persona recuerde todos sus elementos.
Por eso aparece la template.
La template conserva aquello que se mantiene estable y deja como variables aquello que cambia:
TIPO_DE_CONTRATO = [...]
POSICIÓN = [...]
CRITERIOS = [...]
DOCUMENTOS = [...]
FORMATO = [...]La mejora ya no está en la calidad de una respuesta puntual. Está en la reutilización consistente de la instrucción.
Sin embargo, todavía seguimos reutilizando principalmente una especificación lingüística.
La siguiente pregunta es distinta:
¿Cómo reutilizamos no sólo el encargo, sino la forma de realizar correctamente la tarea?
De la template a la skill: de palabras reutilizables a metodología reutilizable
Una revisión contractual seria puede tener una metodología.
No basta con decir:
Revisa la cláusula de limitación de responsabilidad.Podemos querer que el trabajo siga una lógica relativamente estable:
1. localizar el cap general;
2. identificar exclusiones;
3. identificar supercaps;
4. comprobar obligaciones fuera del cap;
5. relacionar la cláusula con indemnidades;
6. detectar remedios especiales;
7. comparar con el criterio interno;
8. separar evidencia de evaluación;
9. señalar información faltante.Aquí ya no estamos describiendo sólo qué pedir.
Estamos describiendo cómo hacer una clase de trabajo.
Ésa es la función de la skill dentro del modelo pedagógico del curso.
La transición puede resumirse así:
PROMPT
"haz esta tarea"
↓
TEMPLATE
"puedo volver a formular esta tarea de manera estable"
↓
SKILL
"puedo reutilizar una metodología para ejecutar esta clase de tarea"La mejora parece grande, pero todavía existe una limitación decisiva.
Una metodología correcta puede fracasar si no dispone de la información que necesita.
De la skill a knowledge: saber hacer no significa saber con qué trabajar
Supongamos que una skill indica:
Compara la cláusula con el estándar interno aplicable.La metodología está bien definida.
Pero ¿dónde está ese estándar?
Podría encontrarse en:
- una política;
- una checklist;
- un contrato modelo;
- una base de precedentes;
- una guía de negociación;
- una decisión interna anterior.
Aquí aparece knowledge: la información disponible para la tarea.
La distinción es importante porque una skill y knowledge cumplen funciones diferentes.
La skill responde:
¿Cómo hago esto?
Knowledge responde:
¿Con qué información puedo hacerlo?
Una organización puede tener una excelente biblioteca documental y una mala metodología.
También puede tener una excelente metodología y no disponer de la información pertinente.
Las dos dimensiones deben diseñarse por separado.
De knowledge a RAG: disponer de información no significa poner toda la biblioteca sobre la mesa
Ahora imaginemos que la organización posee diez mil documentos internos.
Técnicamente existe mucho conocimiento disponible.
Pero el modelo no necesita diez mil documentos para evaluar una cláusula concreta. Necesita los documentos pertinentes.
Por eso aparece RAG.
No volveremos aquí a estudiar embeddings, chunking o recuperación. Eso ya corresponde a páginas anteriores.
El delta que importa en esta arquitectura es funcional:
KNOWLEDGE
universo de información disponible
↓
RAG
mecanismo para localizar e incorporar
la información que parece pertinente
para la tarea actualLa diferencia transforma el problema.
Antes preguntábamos:
¿Tenemos la política?
Ahora preguntamos:
¿Puede el sistema encontrar la política correcta cuando la necesita?
Y aparece una advertencia:
recuperar no significa verificar.
Un sistema puede recuperar una política derogada, un documento similar pero inaplicable o un fragmento insuficiente. RAG mejora el acceso a información. No convierte automáticamente esa información en evidencia correcta.
De conocimiento a acción: el límite de un sistema que sólo produce texto
Hasta este punto el sistema puede recibir instrucciones, reutilizar metodología y localizar información.
Pero supongamos que concluye:
Falta el anexo de tratamiento de datos.
Una aplicación puramente generativa puede escribir esa frase.
Eso no significa que pueda:
- buscar el anexo en otro repositorio;
- abrir el expediente;
- consultar la ficha del proveedor;
- registrar el faltante;
- preparar un correo;
- calcular un plazo;
- actualizar una matriz.
Para salir del espacio de la generación y conectarse con otras capacidades aparecen las tools.
En el marco del curso, una tool es un medio que permite obtener información, calcular o actuar.
La tool puede apoyarse técnicamente en una API, un connector o un protocolo como MCP. Esos conceptos no son intercambiables, pero todos participan en una misma transición pedagógica:
ANTES
el sistema puede decir qué habría que hacer
↓
DESPUÉS
el sistema dispone de un medio para obtener algo
o producir un efecto fuera de la respuesta textualÉste es uno de los saltos de riesgo más importantes del recorrido.
Una respuesta incorrecta puede confundir.
Una acción incorrecta puede cambiar el mundo externo al modelo.
Por eso, desde aquí, la arquitectura necesita pensar simultáneamente en capacidad y permiso.
De tools a workflow: poder hacer varias cosas no significa saber en qué orden deben ocurrir
Supongamos que el sistema puede:
- abrir contratos;
- buscar políticas;
- leer una base de proveedores;
- completar una matriz;
- preparar un correo.
Todavía falta organización.
¿Qué ocurre primero?
¿Se puede evaluar antes de comprobar completitud documental?
¿Qué sucede si falta un anexo?
¿Cuándo se deriva a privacidad?
¿Cuándo se considera terminado el trabajo?
Estas preguntas no son preguntas sobre una tool.
Son preguntas de proceso.
Por eso aparece el workflow.
Un workflow define una secuencia de trabajo mediante actividades, estados y condiciones de avance.
flowchart LR
A["Recibir contrato"] --> B["Comprobar documentos"]
B --> C{"¿Completo?"}
C -- "No" --> D["Solicitar faltantes"]
D --> B
C -- "Sí" --> E["Ejecutar revisión"]
E --> F["Consolidar hallazgos"]
F --> G["Solicitar aprobación"]
El workflow aporta algo que no obtenemos de una colección de herramientas: estructura temporal y estado.
Una tarea puede estar pendiente, en revisión, bloqueada, escalada o completada.
La organización del trabajo comienza a existir como objeto propio.
Del workflow al playbook: una secuencia no basta cuando los casos requieren criterios
Un workflow puede decir:
revisar → consolidar → aprobarPero no todos los contratos siguen la misma ruta.
Un contrato puede requerir revisión de privacidad si existe tratamiento de datos personales.
Puede requerir seguridad si existe acceso a sistemas críticos.
Puede requerir aprobación especial si la responsabilidad queda fuera de determinados umbrales.
La secuencia necesita criterios, ramas, excepciones y escalamiento.
Ésa es la función del playbook en este curso.
flowchart TB
A["Hallazgo"] --> B{"¿Supera estándar?"}
B -- "No" --> C["Ruta ordinaria"]
B -- "Sí" --> D{"¿Existe excepción aprobada?"}
D -- "Sí" --> E["Documentar excepción"]
D -- "No" --> F["Escalar"]
El workflow responde principalmente:
¿Qué etapas existen?
El playbook agrega:
¿Qué ruta corresponde en este caso y por qué?
La distinción importa porque un playbook no es simplemente una lista de cláusulas preferidas. Debe convertir criterios institucionales en reglas de decisión utilizables.
Del playbook al agent: cuando la ruta no puede quedar completamente fijada de antemano
Hasta aquí la mayor parte del trabajo puede estar predeterminada.
Sabemos qué pasos existen y bajo qué condiciones se activan.
Pero algunos problemas contienen suficiente variabilidad como para que resulte útil permitir que el sistema seleccione dinámicamente el próximo paso dentro de un conjunto permitido.
Allí aparece el agent.
La diferencia no es:
workflow = manual
agent = automáticoUn workflow puede estar completamente automatizado.
La diferencia relevante es:
WORKFLOW
la ruta está principalmente predeterminada
AGENT
el sistema puede seleccionar dinámicamente
entre acciones o próximos pasos permitidos
según objetivo, contexto y resultado anteriorGoogle describe una arquitectura agentic en términos de modelo, herramientas, orquestación y servicios de ejecución. En las clases, esa idea se traduce a una formulación especialmente útil para abogados: el agente opera dentro de un ciclo en el que observa el estado, selecciona un próximo paso, utiliza medios disponibles, evalúa el resultado y decide si continúa, se detiene o pide ayuda.
La agencia, por tanto, no aparece por escribir un prompt más largo.
Aparece cuando la arquitectura entrega discreción operacional limitada sobre la trayectoria.
El caso completo
Retomemos ahora una sola vez el contrato de proveedor de IA.
La arquitectura acumulada podría funcionar así:
flowchart TB
A["Objetivo<br/>preparar decisión sobre proveedor"] --> B["Prompt / Template<br/>define el encargo"]
B --> C["Skills<br/>metodologías de revisión"]
C --> D["Knowledge / RAG<br/>políticas, contratos y criterios pertinentes"]
D --> E["Tools<br/>leer, buscar, consultar, registrar"]
E --> F["Workflow<br/>orden y estados"]
F --> G["Playbook<br/>criterios y escalamiento"]
G --> H["Agent<br/>selecciona próximos pasos permitidos"]
H --> I{"¿Puede continuar?"}
I -- "Sí" --> H
I -- "Necesita decisión" --> J["Intervención humana"]
J --> H
I -- "Objetivo cumplido" --> K["Resultado + evidencia + trazabilidad"]
Lo relevante no es que esta arquitectura sea la única manera de construir una aplicación.
Lo relevante es que ahora podemos ver qué función cumple cada pieza.
La instrucción no hace el trabajo completo.
La skill no contiene necesariamente los documentos.
RAG no ejecuta acciones externas por sí solo.
Una tool no define el proceso completo.
Un workflow no equivale automáticamente a una decisión contextual.
Un agente no elimina la necesidad de permisos, evidencia ni controles.
Cada capa conserva su función.
No todas las tareas necesitan toda la arquitectura
Existe un riesgo pedagógico al mostrar una cadena tan extensa: pensar que la meta consiste en llegar siempre al último eslabón.
No es así.
Para corregir redacción puede bastar un prompt.
Para una tarea repetitiva puede bastar una template.
Para una revisión especializada puede ser suficiente una skill con documentos adecuados.
Para una operación estable puede ser preferible un workflow determinista.
Un agente sólo añade valor cuando existe un problema real de selección dinámica.
La regla de diseño debe ser:
añadir una capa porque resuelve una limitación identificada, no porque la capa exista.
Ésta es también una regla de simplicidad.
Cada capa agrega capacidad.
Cada capa agrega costo, dependencias y nuevas formas de fallo.
No estamos construyendo una persona digital
La arquitectura puede parecer progresivamente más “humana” porque comienza a incluir memoria, herramientas, decisiones y ciclos.
Conviene mantener la precisión.
Un agente no se convierte por eso en abogado.
No adquiere autoridad profesional.
No asume responsabilidad.
No “comprende” institucionalmente el contrato por el hecho de poder seleccionar una ruta.
La arquitectura distribuye operaciones entre componentes de software y personas.
Eso es muy distinto de transferir personalidad, competencia o responsabilidad.
La última capa no absorbe las anteriores
Decir “tenemos un agente” no responde preguntas como:
- ¿qué instrucciones utiliza?;
- ¿qué skills ejecuta?;
- ¿qué conocimiento puede consultar?;
- ¿qué tools tiene?;
- ¿qué permisos posee?;
- ¿qué workflow lo limita?;
- ¿qué criterios aplica?;
- ¿qué evidencia deja?
La palabra agent no debe borrar la arquitectura.
Qué debes recordar
La arquitectura completa se construye por acumulación de propiedades:
Prompt
instrucción
Template
instrucción reutilizable
Skill
metodología reutilizable
Knowledge
información disponible
RAG
selección de información pertinente
Tool
acceso, cálculo o acción
Workflow
secuencia y estados
Playbook
criterios, ramas y escalamiento
Agent
selección dinámica de próximos pasosLa secuencia no es una jerarquía de inteligencia.
Es una historia de problemas resueltos.
Cada abstracción aparece porque el sistema anterior todavía no podía hacer algo que ahora necesitamos.
El problema que todavía queda abierto
Ya podemos reconstruir la arquitectura de extremo a extremo.
Pero todavía estamos mirando las capas principalmente desde la pregunta:
¿qué capacidad agrega cada una?
La siguiente página cambia la perspectiva.
En vez de recorrer la cadena como una sucesión histórica, vamos a preguntar sistemáticamente:
¿Qué aporta exactamente cada capa al sistema y cómo sabemos cuál necesitamos?
Ese mapa funcional será el paso previo para analizar después su contracara: qué riesgo nuevo introduce cada propiedad que añadimos.