Adoptar AI engineering no consiste en elegir un modelo. Se parece más a sumar a un colega nuevo y capaz cuyo trabajo a veces es brillante y a veces falla de formas que nadie anticipó. Las decisiones reales son cuánta libertad darle, qué resguardos hacen aceptable esa libertad y qué partes del sistema construir, adoptar o no tener. Las malas decisiones casi nunca se notan en la demo; se notan en la primera factura inesperada o el primer incidente.
Esta lección reúne el curso alrededor de tres decisiones: elegir el nivel de autonomía más bajo que resuelva el problema, decidir qué construir y qué adoptar, y poner los resguardos fuera del modelo. Después repasa los errores frecuentes y las habilidades que sostienen las tres. Los tres productos del curso sirven de ejemplo de decisiones concretas, no de recetas universales.
Usa la menor autonomía que resuelva el problema
Los sistemas de IA van desde una sola llamada a un modelo hasta varios trabajando juntos. Cada escalón le deja al modelo decidir más, y suma costo y riesgo que solo se justifican si el problema lo pide. La mayoría de las aplicaciones reales viven en los tres primeros niveles.
| Nivel | Quién decide el siguiente paso | Resguardo principal | Sirve para |
|---|---|---|---|
| 1. App que llama a un modelo | nadie; no hay acciones | revisar la salida | generar, resumir, extraer |
| 2. Workflow | tu código | el diseño de los pasos | procesos conocidos, responder a partir de documentos |
| 3. Agente | el modelo | las instrucciones | exploración de bajo riesgo |
| 4. Agente con harness | el modelo, con límites | topes a cuánto puede iterar | agentes que corren sin supervisión constante |
| 5. Harness gobernado | el modelo, bajo reglas | políticas, aprobaciones, aislamiento | sistemas reales con efectos reales |
| 6. Varios agentes gobernados | varios modelos | todo lo anterior, más controles entre roles | una necesidad medida de separar funciones |
El salto del nivel 2 al 3 es el que más cambia el riesgo. Antes, tú escribes la secuencia de acciones; después, diseñas el espacio de acciones entre las que el modelo puede elegir (De la aplicación con LLM al agente). Un , el programa que ejecuta el ciclo del agente, lo vuelve confiable, pero solo lo vuelve seguro cuando se le agregan reglas y aislamiento.
Qué construir y qué adoptar
Casi todas las capas tienen opciones ya hechas:
| Categoría | Qué te ahorra | Ejemplos |
|---|---|---|
| Frameworks de agentes | escribir tú el ciclo y el manejo de herramientas | LangGraph, OpenAI Agents SDK, Pydantic AI |
| Agentes de código | construir un agente que trabaje en un repositorio | Claude Code, Codex, OpenHands |
| Gateways de modelos | lidiar con muchos proveedores de modelos | OpenRouter, LiteLLM, Vercel AI Gateway |
| Observabilidad | reconstruir qué pasó y cuánto costó | OpenTelemetry, Langfuse, Arize Phoenix |
| Evals | medir calidad y detectar regresiones | promptfoo, DeepEval, Inspect AI, Ragas |
| Sandboxes | ejecutar código sin arriesgar la máquina anfitriona | gVisor, Firecracker, E2B, Modal |
| Ejecución durable | flujos que sobreviven a caídas | Temporal, Restate, DBOS |
Uno de los registros de diseño de docket reduce la decisión a una sola prueba (ADR 0005: Cutting half of Phases 20 and 21 as overengineering): ¿mediste una necesidad de esta pieza en tu sistema, o solo es algo que a otros les funciona bien? Al aplicarla, docket descartó OpenTelemetry: sensato para una plataforma grande, innecesario para un operador en una sola máquina. Construye lo que te diferencia o lo que ningún proveedor puede darte bajo tus restricciones, como datos que no pueden salir de casa, normas de cumplimiento o ser dueño del punto donde se aprueban las acciones. Adopta el resto y deja por escrito qué capas dejas fuera a propósito.
Los tres productos decidieron distinto, cada uno con una razón explícita:
En docket
- Modelopropone una acción
- Revisión de reglascada acción, sin excepciones
- Permitir
- Consultar a una persona
- Rechazar
- La herramienta corresolo si se permitió o aprobó
- Resultadovuelve al modelo
la siguiente vuelta del ciclo
Pon los resguardos fuera del modelo
La pregunta útil no es "¿el modelo debería negarse?", sino "¿qué parte del sistema lo detiene?". Una instrucción en el compite con un texto que se presenta como requisito. Una revisión de comandos puede pausar y consultar a una persona. Una red que solo alcanza fuentes de paquetes confiables vuelve imposible la descarga.
- El promptle pide al modelo que tenga cuidado
- Revisión de comandospausa los comandos que se sabe riesgosos
- La redsolo alcanza fuentes confiables
Los resguardos se agrupan en tres tipos, y un sistema sólido usa los tres. Prevenir: dar solo los permisos necesarios, mantener los secretos fuera de alcance, exigir aprobación para acciones riesgosas. Contener: aislar la ejecución, restringir la red, poner topes a y ciclos. Detectar y recuperar: guardar trazas y un registro de auditoría, y poder cancelar y revertir. Un buen prompt ayuda en los tres, pero no garantiza ninguno. Un ciclo que queda corriendo todo el fin de semana, por ejemplo, solo lo detiene un presupuesto total, no un límite por paso. Ver Gobernanza y human-in-the-loop y Sandboxing y seguridad de agentes.
Errores frecuentes
- Confiar solo en el system prompt. Cubre el caso normal; las reglas aplicadas en el código cubren el peor.
- Secretos al alcance del modelo. Terminan en logs o commits; mantenlos dentro de la herramienta.
- Sin presupuesto ni timeouts. Pon topes de gasto por llamada, por tarea y por proyecto.
- Reintentos que no son seguros de repetir. El resultado son dos cobros o dos deploys (Ejecución durable de agentes).
- Varios agentes porque suena avanzado. Agrega un rol solo cuando una medición muestra que ayuda (Sistemas multi-agente).
- Evaluar solo la respuesta final. Evalúa también los pasos, y contrasta a los jueces automáticos con personas.
Las habilidades de fondo
Estas decisiones descansan en habilidades que se apoyan unas en otras, y conviene organizarlas por capacidad y no por herramienta, porque las herramientas cambian. Van desde las bases del software, como reintentos que nunca duplican un efecto, pasando por cómo funcionan los modelos, los documentos y los agentes, hasta los controles que cubre este curso: reglas y aislamiento, , trazas, y seguridad. En la cima está la arquitectura: justificar cada parte, y cada parte que decidiste no construir. Lo que las atraviesa a todas es el hábito de desconfiar de las afirmaciones, incluidas las propias, hasta verlas cumplirse en el uso real.
En la práctica
- Empieza por el nivel más bajo que funcione, y sube solo cuando una necesidad medida lo pida.
- Pregunta de cada componente a qué necesidad medida responde aquí. Si nadie puede contestar, déjalo fuera y anota por qué.
- Pregunta de cada acción riesgosa qué capa la detiene si el modelo se equivoca. Si la respuesta es "el prompt", todavía no está detenida.
- Decide pronto cuál es tu fuente de verdad del costo, y pon topes de gasto por tarea y por proyecto.
Para profundizar
Cada producto documenta el razonamiento detrás de sus decisiones (en inglés):
- Stack and decisions repasa cada parte de Adapta, qué otras opciones se consideraron y en qué carpeta está su código.
- DOCKET Architecture describe las capas de docket y por qué ejecuta el ciclo del agente por su cuenta en lugar de depender de un proceso de agente externo.
- Security: Layered & Convention-Based presenta los resguardos de docket capa por capa, desde las instrucciones al agente hasta la revisión por la que pasa cada llamada a herramienta, incluido lo que no se controla.
- Introduction explica cómo Tack deja el agente en manos de herramientas existentes, como Claude Code o Codex y se queda con la planificación, la historia y la recuperación.
Para llevar
- Elige el nivel de autonomía más bajo que resuelva el problema; cada nivel suma costo y riesgo.
- Construye lo que te diferencia o lo que tus restricciones exigen; adopta el resto y declara lo que dejas fuera.
- Las garantías viven fuera del modelo: permisos, reglas, red, secretos y presupuestos.
- Justifica cada componente con una necesidad medida, no con una tendencia.
Comprueba lo aprendido
¿Por qué el salto de un workflow a un agente es el mayor cambio de riesgo?
En un tu código decide cada paso. En un agente el modelo elige entre las acciones que permites, así que dejas de escribir el camino y pasas a diseñar el espacio de caminos posibles, incluidos los malos.
Un agente encuentra un README que le pide descargar y ejecutar un script. ¿Qué resguardo lo detiene de forma más confiable?
Una red que solo alcanza fuentes confiables. Un prompt puede quedar opacado por un texto convincente, y una revisión de comandos puede pasar por alto una variante, como le pasa a docket con una línea de Python. Sin acceso a la red, la descarga falla sin importar cómo luzca el comando.
¿Por qué un equipo construiría su propio ciclo de agente en lugar de adoptar un framework?
Cuando ser dueño del punto donde se revisa cada acción importa más que la comodidad, como en docket. Quien es dueño del ciclo es dueño de esos puntos de control, así que un framework haría depender los resguardos del diseño de otro.