1. Modelo mental
Un agente es útil cuando el sistema necesita decidir qué paso ejecutar a continuación a partir del estado actual. Si todos los pasos son conocidos y estables, un workflow determinista suele ser más simple, barato y seguro.
La autonomía no es binaria. Puedes permitir al modelo elegir entre herramientas de lectura pero exigir aprobación para enviar un email, mover dinero, borrar datos o modificar producción. Diseñar estos límites es más importante que el prompt del agente.
Un agente fiable necesita estado, trazas y recuperación. Si no puedes reconstruir qué observó, qué decidió y qué herramienta ejecutó, no puedes depurarlo ni auditarlo.
2. Conceptos que debes dominar
Condición que orienta el agente; debe ser específica y acotada.
Acción disponible con contrato, permisos y errores conocidos.
Información persistente o temporal necesaria para decidir el siguiente paso.
Mecanismo que selecciona o propone pasos.
Punto donde una persona o regla debe aprobar antes de continuar.
Restricción que limita inputs, outputs o acciones.
Propiedad de repetir una acción sin duplicar efectos no deseados.
Logs, trazas, costes, decisiones y resultados por ejecución.
Límite de pasos, tiempo o coste que evita loops.
Ruta segura cuando una herramienta o decisión falla.
3. Workflow paso a paso
Modela la tarea
Dibuja el proceso y marca decisiones reales.
Puedes señalar dónde hace falta autonomía.
Clasifica acciones
Lectura, escritura, irreversible, sensible.
Cada tool tiene nivel de riesgo.
Diseña contratos
Inputs, outputs, errores y permisos de cada herramienta.
La herramienta valida antes de actuar.
Define estado
Qué recordar entre pasos y sesiones.
No dependes de historial infinito.
Añade checkpoints
Aprobación para acciones críticas.
El agente no puede saltarlos.
Limita ejecución
Máximo de pasos, coste y tiempo.
Un loop se detiene solo.
Instrumenta
Traza decisión → tool → resultado.
Puedes reproducir un fallo.
Evalúa escenarios
Normal, herramienta caída, datos ambiguos, prompt injection.
El agente falla de forma segura.
4. Ejemplo completo
Agente de soporte interno:puede leer tickets, consultar base de conocimiento y proponer respuesta. Puede crear un borrador, pero no enviarlo si hay devolución, compensación o cambio de cuenta. Esas acciones requieren aprobación.
El valor no está en que “haga todo solo”, sino en reducir pasos humanos repetitivos sin eliminar el control donde importa.
5. Matriz de decisión
| Decisión | Qué mirar | Señal buena | Señal de riesgo |
|---|---|---|---|
| Workflow fijo | Pasos conocidos | Código determinista | Agente añade variabilidad |
| Agente lector | Exploración multifuente | Tools read-only | Confundes lectura con permiso de acción |
| Agente con escritura | Acciones reversibles | Contratos y logs | Sin idempotencia |
| Agente crítico | Acciones de alto impacto | Checkpoints humanos | Autonomía total |
| Multiagente | Roles realmente separables | Interfaces claras | Complejidad sin necesidad |
6. Fallos y límites
Una guía útil también debe decir cuándo detenerse. Estos son los fallos que más cambian la calidad del resultado:
- Dar acceso amplio “por si acaso”.
- Usar memoria larga sin esquema de estado.
- No limitar número de pasos.
- Herramientas que aceptan parámetros sin validar.
- No distinguir tool result de instrucción no confiable.
- No proteger contra prompt injection en contenido externo.
- No registrar acciones irreversibles.
- Medir éxito sólo por completar tarea y no por seguridad.
7. Cómo medirlo
No midas sólo si “parece bueno”. Define una señal observable antes de escalar.
| Métrica | Qué mide | Cómo observarla | Umbral/alerta |
|---|---|---|---|
| Task success | Objetivo completado | Casos etiquetados | Bajo gate |
| Tool error rate | Fiabilidad integración | Errores/tool | Picos |
| Human approval | Intervención necesaria | Aprobaciones/total | Cae sin control o sube por mala calidad |
| Steps/task | Eficiencia | Trazas | Loops |
| Cost/task | Presupuesto | Tokens+tools | Excede budget |
| Unsafe action | Seguridad | Eventos críticos | Debe ser 0 |
8. Checklist de producción
9. Ejercicios para convertir lectura en habilidad
- Convierte un agente imaginario en workflow fijo y decide qué parte realmente necesita autonomía.
- Clasifica diez tools como read/write/irreversible.
- Diseña un checkpoint para una acción sensible.
- Crea un caso de prompt injection dentro de un documento recuperado.
- Define el máximo de pasos y el comportamiento al alcanzarlo.
10. Qué estudiar después
No intentes memorizar toda la IA. Encadena la siguiente pieza cuando resuelva una duda que ya has encontrado en la práctica.
Apéndice A · Preguntas que deberías poder responder
- ¿Qué parte del problema es determinista y cuál necesita juicio probabilístico?
- ¿Qué dato o ejemplo cambiaría tu decisión actual?
- ¿Cómo distinguirás una mejora real de una respuesta simplemente más convincente?
- ¿Qué ocurre cuando faltan datos, la herramienta falla o la respuesta es incierta?
- ¿Qué parte del proceso debe seguir bajo responsabilidad humana?
- ¿Qué coste operativo aparece después del primer prototipo?
- ¿Qué revisarías dentro de 30, 90 y 180 días para evitar que el sistema envejezca?
Si no puedes responder todavía a varias de estas preguntas, no significa que el proyecto esté mal: significa que has encontrado exactamente los huecos que la siguiente iteración debe cerrar. Ese es uno de los usos más valiosos de una guía técnica: convertir incertidumbre difusa en decisiones explícitas.
Apéndice B · Cuatro escenarios para practicar la decisión
Pregunta:Pasos conocidos.Señal favorable:Código determinista.Alerta:Agente añade variabilidad.
Pregunta:Exploración multifuente.Señal favorable:Tools read-only.Alerta:Confundes lectura con permiso de acción.
Pregunta:Acciones reversibles.Señal favorable:Contratos y logs.Alerta:Sin idempotencia.
Pregunta:Acciones de alto impacto.Señal favorable:Checkpoints humanos.Alerta:Autonomía total.
No memorices la tabla como si fuera una regla universal. Cambia volumen, riesgo, disponibilidad, privacidad o coste y vuelve a recorrer la decisión. Un sistema robusto documenta qué variables sostienen la elección y cuáles podrían invalidarla.
Apéndice C · Cuaderno de campo para tu propio caso
Copia estas preguntas en un documento y complétalas con un caso real. El objetivo es que el conocimiento deje de estar en la página y pase a tu proceso.
- Problema¿Qué trabajo concreto intentas mejorar y para quién?
- Baseline¿Cómo se hace hoy, cuánto tarda y qué errores aparecen?
- Datos¿Qué entra, de dónde viene, quién puede verlo y qué no debería salir del entorno?
- Salida¿Qué formato y criterios convierten el resultado en usable?
- Prueba¿Qué 20–50 casos representarían el trabajo real?
- Riesgo¿Cuál es el fallo más costoso y cómo se detecta?
- Operación¿Quién observa, corrige, actualiza y puede detener el sistema?
- Revisión¿Qué evento o fecha obligará a reevaluar esta decisión?
Guarda también dos ejemplos que funcionaron y dos que fallaron. Con el tiempo, esos ejemplos se convierten en un pequeño dataset de evaluación mucho más útil que cualquier memoria informal de “esto parecía ir bien”.
Apéndice D · De prototipo a producción
Una demo responde a la pregunta “¿puede funcionar?”. Producción responde a otras: “¿funciona de forma repetible?”, “¿qué pasa cuando falla?”, “¿quién lo mantiene?”, “¿cómo sabemos que sigue siendo bueno dentro de tres meses?” y “¿podemos revertirlo?”. El salto entre ambas fases suele ser mayor que el salto entre dos modelos.
Antes de escalar, separa cuatro planos.Calidad:casos y métricas.Operación:latencia, cuotas, errores y costes.Gobernanza:permisos, datos, revisión y responsables.Cambio:versiones, fuentes y fechas de reevaluación. Si uno de estos planos no tiene dueño, el riesgo aparecerá precisamente cuando el uso crezca.
- Define un SLO de calidad y uno operativo.
- Registra versión de modelo, prompt, fuentes y configuración.
- Mantén una muestra estable para detectar regresiones.
- Añade un fallback para proveedor, herramienta o dato ausente.
- Decide qué errores se reintentan y cuáles se escalan.
- Presupuesta revisión humana, no sólo tokens.
- Evita permisos permanentes que sólo necesitabas para una prueba.
- Programa una revisión tras cambios de modelo, precio, política o dataset.
Finalmente, observa el sistema con tráfico real. Una mejora offline puede empeorar experiencia, coste o tasa de escalado. Las métricas de esta guía son el comienzo; adáptalas al impacto de tu caso y conserva siempre ejemplos concretos detrás de cada porcentaje.
Agentes: autonomía útil con límites explícitos
Un agente merece la pena cuando el camino hasta el resultado no puede fijarse completamente de antemano y el sistema necesita elegir herramientas o pasos. Si el proceso es estable y determinista, un workflow convencional suele ser más barato, fácil de probar y seguro. La autonomía es una herramienta de arquitectura, no un objetivo de marketing.
Separa acciones de lectura y escritura. Consultar un inventario o buscar documentación tiene un perfil de riesgo distinto a enviar un correo, modificar una base de datos o comprar. Las herramientas de escritura deben tener permisos mínimos, validación de argumentos y, para acciones de impacto, checkpoints humanos o confirmaciones explícitas.
Controla loops y presupuesto. Define máximo de pasos, tiempo, tokens, reintentos y coste. Un agente persistente puede entrar en ciclos o repetir llamadas. El sistema debe saber cuándo detenerse, cuándo cambiar de estrategia y cuándo escalar a una persona.
La observabilidad debe reconstruir la ejecución: objetivo, decisiones, tool calls, argumentos, respuestas, errores y resultado. No necesitas exponer razonamiento interno; necesitas trazas operativas suficientes para entender qué acción ocurrió y con qué datos.
Evalúa trayectorias, no sólo respuestas finales. Dos agentes pueden llegar a la misma salida con costes y riesgos muy diferentes. Mide tasa de éxito, pasos, llamadas fallidas, acciones innecesarias, latencia, coste y necesidad de intervención humana.
Una escala de madurez para agentes: autonomía útil con límites explícitos
Resuelve un caso real de principio a fin. Conserva entrada, salida y correcciones. Aquí buscas descubrir fallos, no automatizar.
La entrada y la salida ya tienen contrato, existen ejemplos límite y puedes medir calidad, tiempo y coste con el mismo criterio.
Hay observabilidad, permisos, fallback, responsable, revisión de cambios y un mecanismo para detectar regresiones antes de afectar al usuario.
La transición entre niveles debe estar motivada por evidencia. No pases a integración o autonomía sólo porque una demo salió bien. Pasa cuando hayas repetido la tarea con casos representativos, sepas dónde falla y el ahorro neto siga siendo positivo después de incluir revisión y operación.
Para los primeros 30 días, reúne ejemplos y construye el baseline. Entre 30 y 60 días, estabiliza el contrato de entrada/salida y convierte los fallos recurrentes en tests, checklist o reglas. Entre 60 y 90 días, si el volumen lo justifica, añade automatización, monitorización y revisión de costes. Si una etapa no supera sus propios criterios, mantén el sistema en la etapa anterior.
Documenta también las condiciones de salida: qué cambio de proveedor, política, precio, modelo, volumen o riesgo obligaría a reevaluar el diseño. Una arquitectura madura no pretende ser definitiva; hace explícito cuándo deja de ser válida.
Antes de considerar el trabajo terminado, realiza una revisión adversarial: busca deliberadamente entradas ambiguas, datos faltantes, instrucciones contradictorias, límites de cuota y resultados que parezcan correctos pero no puedan verificarse. El objetivo no es demostrar que el sistema funciona, sino descubrir bajo qué condiciones deja de funcionar y comprobar que esos fallos tienen una respuesta segura. Registra cada hallazgo y conviértelo en una prueba futura.
- Guarda al menos 20 casos reales, incluidos fallos.
- Define un criterio de aprobación que otra persona pueda aplicar.
- Separa métricas de calidad, coste y operación.
- Establece quién puede detener o revertir el sistema.
- Programa una fecha de revisión aunque nada parezca haber cambiado.
Documentación que sostiene y actualiza esta guía
Las capacidades y políticas cambian. Usa estas referencias para comprobar los puntos que dependan de un proveedor o de una versión concreta.