Aprender la ingeniería de IA agente según lo que enseñan los fallos.

Los desarrolladores que se dedican a la ingeniería de agentes suelen intentar absorber todos los frameworks al mismo tiempo, probando LangChain, CrewAI, AutoGen y LangGraph en una sola semana sin entregar nada tangible. El problema radica en el orden de aprendizaje: estudian las herramientas antes de comprender los fallos que estas están diseñadas para evitar. Esta guía presenta un camino de catorce pasos siguiendo el orden en que realmente se desarrollan las habilidades, desde los conocimientos básicos de Python hasta la creación de un agente que funcione sin supervisión. A lo largo del camino aprenderá los tres modos de fallo que influyen en cada decisión de diseño, el conjunto mínimo de herramientas necesario para la mayoría de los trabajos en producción, y los patrones estructurales (archivos de estado, revisión por parte de un verificador, evaluación en capas y definición de permisos) que diferencian una demostración de un sistema en el que se puede confiar desde el primer día.

Parte 1: El modelo mental

1. La ingeniería de agentes no es la ingeniería de prompts con un nuevo nombre

La ingeniería de prompts consiste en diseñar lo que se le dice a un modelo. La ingeniería de agentes se refiere a crear el sistema que decide en qué debe trabajar el modelo, cuándo debe detenerse y cómo reaccionar cuando su respuesta es incorrecta.

La definición práctica es concreta: se construye un software en el que un LLM elige la próxima acción, invoca una herramienta para ejecutarla, examina el resultado y repite el proceso hasta completar la tarea, sin que una persona dirija cada paso. Un chatbot responde a un mensaje; un agente elige acciones, las ejecuta, verifica sus resultados e itera. Esa diferencia constituye toda la tarea.

Esto implica tres responsabilidades que el trabajo con prompts nunca requirió:

• Tratar los errores como una preocupación fundamental. Los agentes fallan constantemente: las APIs se agotan, el JSON devuelve datos mal formados, el modelo inventa llamadas a herramientas y las salidas de estas violan sus esquemas. El código que asume éxito colapsará en el peor momento posible, generalmente durante una demostración.
• Gestionar el estado. Una sola llamada a un LLM no conserva ninguna información. Un agente que realiza diez pasos de llamadas a herramientas, intentos repetidos y subagentes necesita un estado estructurado y duradero que sobreviva más allá de cualquier ventana de contexto.
• Integrar la evaluación en la infraestructura. No existe una intuición que indique si un agente tiene razón. Se necesitan mecanismos automatizados, como pruebas, rúbricas o un modelo de evaluador, que rechacen las salidas defectuosas sin que una persona revise cada ejecución.

Las descripciones de los puestos para estos roles suelen parecerse a un catálogo. Los marcos de orquestación (LangGraph, LangChain, LlamaIndex), los protocolos (MCP, A2A), las características de los modelos (llamadas a funciones, salidas estructuradas, caché de prompts), los temas de recuperación de información (RAG, RAGAS, búsqueda híbrida, reclasificación, modelos de embedding, bases de datos vectoriales y gráficas) y las habilidades operativas (ejecución en entornos aislados, capacidad de observación, evaluación) aparecen todos, generalmente seguidos de una solicitud de familiaridad con la iteración rápida. La lista parece abrumadora, pero la mayoría de los elementos se reducen a un puñado de ideas fundamentales bajo nombres diferentes. Si comprendes esas ideas, será fácil identificar a qué se refieren los nombres de los productos.

2. Tres modos de fallo explican la mayor parte del trabajo

Antes de escribir código, entiende por qué fallan los sistemas agentes. Casi todas las herramientas y patrones en este campo existen para contrarrestar uno de estos tres comportamientos.

Pereza agencial. Ante una tarea larga y dividida en partes, el modelo se detiene temprano y declara éxito tras haber avanzado parcialmente. Resuelve 20 de los 50 tickets pendientes y describe el resto como ya manejado. La contramedida es una condición de parada explícita que sea verificada por algo distinto al modelo en funcionamiento.

Sesgo de auto-preferencia. Cuando se le pide que revise su propio resultado, un modelo lo aprueba de manera fiable. Un revisor con interés en el resultado no puede juzgarlo objetivamente. La contramedida es estructural: el agente que genera el trabajo no debe ser el mismo que lo revisa.

Desvío del objetivo. Con el paso de muchos pasos, y especialmente después de que el contexto se resuma o comprima, el agente pierde gradualmente de vista el objetivo original. Una restricción como “no tocar el módulo de pagos” puede desaparecer silenciosamente en el paso 47. La contramedida es un archivo de especificaciones persistente que se vuelve a leer en cada ejecución, manteniendo las restricciones que de otro modo el modelo perdería.

Cuando el ecosistema parezca abrumador, pregúntese sobre cualquier herramienta o patrón nuevo cuál de estos tres problemas aborda. Esa pregunta elimina la mayor parte del ruido.

3. Un conjunto básico reducido y cuatro cosas para posponer

Las listas de requisitos son largas, pero la mayor parte del trabajo del agente en producción se basa en cuatro capas, que es mejor aprender en este orden:

Core stack (learn these, in this order):
1. Python + async    : the bedrock; everything else builds on it
2. LLM APIs          : Anthropic, OpenAI; understand tokens, context, costs
3. Tool use / MCP    : function calling; how models act on the world
4. LangGraph         : stateful orchestration for multi-step, multi-agent work

Posponga lo siguiente hasta que haya lanzado al menos un agente real:

• Afinación. Los proyectos iniciales casi nunca la necesitan. Un modelo base capaz con prompts bien diseñados generalmente supera a un modelo afinado con prompts de mala calidad.
• Preocuparse excesivamente por las bases de datos vectoriales. Algo como Chroma funciona bien localmente y un servicio gestionado como Pinecone es adecuado en entornos de producción. Espera antes de elegir uno hasta que la recuperación de datos se convierta en un verdadero cuello de botella en lo que estás desarrollando.
• Cambiar de frameworks. Elige un framework de orquestación (LangGraph es una buena opción por defecto), termina un proyecto y solo entonces explora otras opciones. Cambiar de herramientas cada semana porque cada una promete ser más simple no garantiza que nada se termine.
• Agentes de voz y del navegador. Estas son especializaciones basadas en las mismas bases. Domina primero los agentes de texto; los patrones se aplican también aquí.

Parte 2: Los componentes básicos

4. Python y código asíncrono

No es necesario dominar completamente Python, pero sí se necesita suficiente conocimiento para depurar errores, y los agentes fallan con frecuencia. Enfócate en:

• Clases y modelos de datos. Los agentes transfieren datos estructurados de un paso a otro, por lo que es necesario modelarlos. Un esquema Pydantic funciona como el contrato entre las llamadas a herramientas y la lógica del agente; trátalo como algo obligatorio, no opcional.
• Asincronía con asyncio. Los agentes pasan gran parte de su tiempo esperando a que las herramientas respondan: una consulta a la base de datos, una llamada HTTP, un subproceso. El código síncrono se bloquea durante cada espera, mientras que el código asíncrono puede realizar otras tareas. Un código de agente lento suele ser código síncrono que espera en secuencia.

HTTP y REST. Sin APIs, un agente puede pensar pero no actuar. Aprenda a leer la documentación de las APIs, respetar los límites de frecuencia, interpretar las respuestas de error y volver a intentarlo de manera sensata. Una herramienta que se cae al recibir un HTTP 429 es una herramienta en la que el agente no puede confiar.

Gestión de errores. Envuelva cada llamada a una herramienta en try/except. Los agentes funcionan sin supervisión, y una excepción no manejada que imprime un rastro de llamadas y finaliza no ayuda a nadie en medio de la noche.

Un umbral práctico: si pudiera asignar una tarea a un ingeniero junior con una lista de verificación y confiar en un conjunto de pruebas para detectar sus errores, ya sabe lo suficiente de Python como para comenzar. Se puede aprender más más adelante.

5. Fundamentos de los LLM: tokens, contexto y costo

Modelos como Claude, GPT y Gemini son potentes, pero necesitan orientación, y no se puede dirigir lo que no se comprende.

Tokenización. Los modelos leen tokens, no palabras, y un mismo término puede dividirse en varios tokens según el tokenizador. Como regla aproximada para el inglés, un contexto de 100,000 tokens contiene alrededor de 75,000 palabras. Todo lo que esté fuera de ese rango, ya sea la conversación de la semana pasada o un archivo que se olvidó incluir, simplemente no existe para el modelo. Si algo es importante, debe estar dentro del contexto.

Límites de contexto y recuperación. Los modelos no recuerdan; cada sesión comienza vacía. Incluir todo en la instrucción de entrada es costoso y reduce la calidad a medida que aumenta el volumen. La generación mejorada por recuperación existe para obtener solo lo relevante.

Inferencia, no entrenamiento. Casi nunca entrenará un modelo. Usted realiza inferencias con el modelo de otra persona y paga por token. El costo es la cantidad de tokens de entrada multiplicada por el precio de entrada, más la cantidad de tokens de salida multiplicada por el precio de salida; por lo tanto, un bucle que realice 50 llamadas con un contexto de 20,000 tokens tendrá una factura considerable.

Estímulo para agentes. Los estímulos para agentes difieren de los estímulos para chats. Tres patrones son los más importantes: el enfoque de cadena de pensamiento, en el que el modelo razona explícitamente antes de actuar; ReAct, un ciclo de razonamiento, acción y observación; y la reflexión, en la que el modelo critica su propio borrador antes de devolverlo. La mayoría de las demás técnicas de estímulo son variaciones de estos. Para conocer más sobre el ciclo ReAct, consulte cómo los agentes ReAct combinan el razonamiento con acciones del mundo real.

6. El uso de herramientas y MCP convierten a un chatbot en un agente

Un modelo limitado a generar texto es un chatbot. Un modelo que puede invocar una función, inspeccionar el resultado y decidir qué hacer a continuación es un agente, y el uso de herramientas es el mecanismo que lo posibilita.

Mecánicamente, se describe cada función con un nombre, una descripción en lenguaje natural y un esquema JSON para sus parámetros, y estas definiciones se envían junto con el mensaje del usuario. El modelo decide si se necesita una herramienta y, de ser así, devuelve una llamada a la herramienta estructurada con argumentos en lugar de texto simple. Tu código ejecuta la función, envía el resultado de vuelta y el modelo continúa desde allí. La descripción es tan importante como el esquema, ya que es lo que utiliza el modelo para decidir cuándo aplicar una herramienta.

La mayoría de las herramientas prácticas para agentes se dividen en cuatro categorías. Las firmas a continuación las ilustran: herramientas que leen (observan el mundo), herramientas que escriben (cambian el estado), herramientas que ejecutan código y herramientas que verifican el trabajo:

# Category 1: Read  (agent observes the world)
def search_codebase(query: str, path: str) -> list[str]: ...
def fetch_url(url: str) -> str: ...
def read_file(path: str) -> str: ...

# Category 2: Write (agent changes state)
def create_file(path: str, content: str) -> None: ...
def open_pull_request(title: str, body: str, branch: str) -> str: ...
def send_slack_message(channel: str, text: str) -> None: ...

# Category 3: Execute (agent runs code)
def run_tests(test_path: str) -> dict: ...
def execute_sql(query: str, db: str) -> list[dict]: ...

# Category 4: Verify (agent checks its own work)
def lint_code(file_path: str) -> list[str]: ...
def run_type_checker(path: str) -> bool: ...

Estas categorías también son una herramienta útil para evaluar riesgos. Las herramientas de lectura y verificación suelen ser seguras para usar libremente, mientras que las herramientas de escritura y ejecución modifican algo y requieren permisos más estrictos, un tema que vuelve a surgir en la etapa de seguridad.

El Protocolo de Contexto del Modelo (MCP) es un estándar emergente que reemplaza el código de integración personalizado por un protocolo. Una analogía común es USB-C para la IA: en lugar de escribir un adaptador a medida cada vez que el agente necesita acceder a GitHub, Slack o una base de datos, se conecta un servidor MCP existente, y la aplicación anfitriona descubre las capacidades del servidor y las utiliza sin necesidad de código adicional.

Las integraciones que brindan los mejores resultados más rápidamente son GitHub para ramas, solicitudes de integración y problemas; Slack para notificaciones y resúmenes; su base de datos para consultas y escrituras controladas; y el sistema de seguimiento de problemas del equipo. Con estos cuatro elementos conectados, un agente puede manejar la mayor parte del flujo de trabajo de ingeniería.

7. Recuperación de información, porque el contexto tiene un límite

La generación mejorada mediante recuperación de información proporciona a un agente conocimientos que no caben en su contexto. Se trata de una respuesta a una restricción real y no de una moda: la ventana de contexto es finita, mientras que su código y documentación no lo son.

Un sistema de recuperación de información consta de cuatro partes principales:

• Fragmentación, donde los principiantes suelen cometer errores. Los fragmentos demasiado grandes contienen demasiado material irrelevante; los fragmentos demasiado pequeños pierden su significado. El tamaño adecuado depende del contenido, y el código fuente generalmente necesita límites diferentes (como funciones completas) que la documentación en prosa.
• Embebimientos, que hacen posible la búsqueda de similitudes. Un modelo de embebimiento convierte el texto en un vector numérico de modo que los pasajes similares generen vectores cercanos entre sí.
• Búsqueda, que encuentra los vectores almacenados más cercanos a la consulta embebida y devuelve sus fragmentos.

Evaluación, que distingue a un sistema que realmente funciona de uno que solo parece funcionar. Las medidas clave son la precisión en la recuperación (¿lo que se obtuvo era realmente relevante?), la fidelidad (¿la respuesta quedó dentro del material recuperado?) y la relevancia de la respuesta (¿abordó realmente la pregunta?). Herramientas como RAGAS o un modelo de evaluador pueden puntuar estos aspectos. Sin mediciones, la mejora se reduce a conjeturas.

La recuperación avanzada rara vez sigue una línea recta desde la consulta hasta la respuesta. Los sistemas en producción suelen reescribir la pregunta antes de buscar, volver a clasificar los resultados después de la búsqueda y utilizar un paso de evaluación para determinar si el material recuperado realmente responde a la pregunta. En efecto, el modelo razona sobre qué obtener y si la obtención tuvo éxito.

8. Orquestación con estado mediante LangGraph

Una sola llamada a un LLM no constituye un agente. Un agente ejecuta múltiples pasos, mantiene el estado entre ellos, toma decisiones según lo que observa y se recupera de los fallos. LangGraph proporciona una estructura exactamente para eso.

Estructuralmente, una aplicación LangGraph es un grafo dirigido cuyos nodos son funciones simples, como agentes, herramientas o pasos de procesamiento. Las aristas definen cómo se transfiere el control entre ellos. Cada nodo lee y actualiza un objeto de estado compartido y tipado.

El boceto a continuación define un estado que incluye una tarea, un plan, resultados, errores y una bandera de finalización, y luego registra cuatro nodos: un planificador que divide el trabajo, un ejecutor que lleva a cabo un paso, un verificador que comprueba los resultados y un manejador de errores que vuelve a intentarlo o escala el problema. El borde condicional después del verificador es el núcleo del bucle: finalizar cuando el estado indique que está listo, redirigir al manejador en caso de errores y, de lo contrario, ejecutar el siguiente paso. Tenga en cuenta que se trata de un fragmento; un grafo ejecutable también necesita un punto de entrada, los bordes restantes y una llamada a compile().

from langgraph.graph import StateGraph, END
from typing import TypedDict

class AgentState(TypedDict):
    task: str
    plan: list[str]
    results: list[str]
    errors: list[str]
    done: bool

graph = StateGraph(AgentState)

graph.add_node("planner", plan_task)       # breaks work into steps
graph.add_node("executor", execute_step)   # runs one step
graph.add_node("verifier", verify_output)  # checks the result
graph.add_node("handler", handle_error)    # retries or escalates

graph.add_conditional_edges(
    "verifier",
    lambda state: END if state["done"] else
                  "handler" if state["errors"] else
                  "executor"
)

En comparación con un bucle de Python escrito a mano, el framework añade tres funcionalidades:

• Puntos de control. Al compilar el grafo con un punto de control, el estado se guarda después de cada paso, de modo que una ejecución interrumpida (un portátil que se apaga, una sesión reiniciada) puede reanudarse desde donde se detuvo en lugar de comenzar de nuevo.
• Pausas con intervención humana. Al establecer interrupt_before en un nodo de alto riesgo, el grafo se detiene, muestra la acción propuesta y espera aprobación antes de continuar. Esto es una parte importante de lo que diferencia a un agente de demostración de uno en producción.
• Ramas paralelas. Los pasos independientes pueden ejecutarse simultáneamente mientras el marco de trabajo se encarga de combinar sus resultados en el estado, por lo que solo es necesario describir la estructura en lugar de escribir código de sincronización.

Una regla razonable: opta por un marco de grafos cuando el agente tenga más de unos tres pasos, ramificaciones en los resultados de las herramientas o bucles hasta que se cumpla una condición. Una cadena lineal simple sin ramificaciones funciona bien en Python puro. Los compromisos se tratan con más profundidad en elegir entre cadenas y grafos con estado.

Parte 3: Construirlo correctamente

9. Cinco proyectos, en secuencia

Leer sobre agentes y construirlos son habilidades diferentes, y el aprendizaje solo funciona con proyectos prácticos. Estos cinco, realizados en orden, abarcan cada concepto que se requiere para el trabajo de producción.

1. Un agente con una herramienta. Elija una única API, como GitHub o un servicio meteorológico, y escriba un agente que determine si se necesita dicha API, la invoque y procese su respuesta para incluirla en la contestación. Utilice la API bruta de Anthropic u OpenAI sin ningún framework, de modo que pueda observar el ciclo de uso de la herramienta sin que ninguna abstracción lo oculte.
2. Un agente ReAct con tres herramientas. Agregue búsquedas en la web, una calculadora y un ejecutor de código, y escriba usted mismo el ciclo de razonar, actuar y observar. Por lo general, es aquí donde por primera vez se ve a un agente darse cuenta y corregir su propio error.
3. Recuperación de información a partir de un códigobase que conoce. Indexe un repositorio real, cree un sistema de recuperación sobre él y haga preguntas que requieran comprender varios archivos. Mida la calidad de la recuperación y corrija los segmentos que fallen. Este proyecto demuestra por qué el particionamiento en fragmentos es más importante que cualquier otra cosa.

Un agente de gráfico multietapa. Aborda la triaje en CI: lee los registros de pruebas fallidas, clasifica el fallo, busca en la base de código la causa probable, elabora una solución y ejecuta las pruebas, con el estado fluyendo a través de cinco nodos. Haz que el verificador sea un nodo separado del corrector; de lo contrario, te encontrarás con un sesgo de preferencia propia.

Un bucle autónomo programado. Ejecuta el proyecto cuatro según un horario cron sin que nadie lo supervise. Dale un archivo de estado para que continúe en lugar de reiniciarse, un presupuesto estricto de gastos para que no aumente los costos de la API, y un registro de auditoría que anote lo que hizo. Aquí es donde “funciona en una demostración” se convierte en “funciona sin supervisión”.

10. El archivo de estado: los agentes olvidan, los archivos no

Esto parece demasiado simple como para ser importante, pero constituye la base de todo agente autónomo fiable: un archivo Markdown, un documento JSON o una fila de base de datos que existe fuera de la conversación y registra lo que se ha hecho y qué viene a continuación.

Los modelos no conservan nada entre sesiones. Todo lo que un agente aprende durante una ejecución desaparece a menos que se anote, por lo que un bucle sin estado persistente comienza desde cero cada vez, mientras que uno con estado retoma donde lo dejó. El ejemplo a continuación registra la última hora de ejecución, el conteo de elementos procesados y restantes, el trabajo en curso, el trabajo completado, los elementos elevados a un humano, y lecciones con fecha, como peculiaridades del entorno que deben evitarse la próxima vez:

// STATE.md: what every working autonomous agent needs
{
  "last_run": "2026-07-01 03:00 UTC",
  "items_processed": 47,
  "items_remaining": 12,
  "in_progress": [
    "fix/auth-token-refresh: tests passing, awaiting CI"
  ],
  "completed": [
    "fix/null-check-in-billing: merged, CI green"
  ],
  "escalated_to_human": [
    "src/payments/refund.ts: root cause unclear after 3 theories"
  ],
  "lessons": [
    "2026-06-30: E2E tests require Stripe webhook secret in env. Skip if missing.",
    "2026-06-29: Windows runner has TLS 1.2 issue. Use bash, not PowerShell."
  ]
}

La lista de lecciones merece atención. Es la forma en que un bucle deja de repetir el mismo error y también funciona como una especificación persistente que evita la desviación de los objetivos. Existen dos formatos comunes: un archivo en Markdown almacenado en el repositorio está controlado por versiones, es fácil de comparar y sencillo, lo cual resulta adecuado para individuos y equipos pequeños. Para bucles de producción que deben ser monitoreados por varias personas, un sistema externo como un tracker de problemas como Linear o una base de datos funciona mejor. El principio es simple: el agente olvida, el repositorio recuerda; por lo tanto, todo lo importante debe quedar fuera de la ventana de contexto.

11. Maker-checker: separar al autor del revisor

Un agente realiza el trabajo y otro agente, con su propio contexto, lo verifica. Esta es la solución estructural al sesgo de auto-preferencia, y aplicarla de manera consistente es uno de los indicadores más claros de un diseño de agentes maduro.

Un modelo que califica su propio resultado es demasiado generoso consigo mismo. Pregúntale al agente que escribió la corrección si es correcta y encontrará razones para decir que sí. Dale a un revisor independiente la corrección junto con una rúbrica, sin que sepa quién la escribió ni por qué, y él detectará defectos reales.

La diferencia en el código: la versión incorrecta pide a un único agente que corrija un error y confirme su propia corrección. La versión correcta ejecuta una herramienta de corrección en un modelo y luego transmite únicamente el código resultante junto con una rúbrica específica al revisor, instruyéndolo a ignorar la autoría y la intención, y a devolver un resultado de aprobación con justificación o uno de rechazo con referencias a las líneas afectadas. El revisor utiliza un modelo más potente, ya que el juicio es la tarea más difícil:

# Wrong: one agent does both
result = await agent("Fix the auth bug and verify your fix is correct")

# Right: maker and checker are separate agents, separate contexts
fix = await agent(
    "Fix the auth bug in src/auth/middleware.ts",
    model="sonnet"
)

review = await agent(
    f"""Review this fix against the rubric below.
    Do not consider who wrote it or their intent.

    Fix:
    {fix.code}

    Rubric:
    - Does it handle the null case on line 47?
    - Does it preserve the existing token expiry logic?
    - Does the test cover the regression case?

    Return: PASS with reasoning, or FAIL with specific line references.""",
    model="opus"   # harder model for the harder judgment task
)

La regla para emparejar es que el revisor recibe solo dos entradas: la rúbrica y el artefacto, y nunca la identidad del autor, las razones detrás del cambio ni la conversación que lo generó. Cualquiera de estos elementos vuelve a introducir preferencias personales a través del enfoque utilizado. La rúbrica también es importante; las preguntas específicas y verificables, como las mencionadas anteriormente, funcionan mucho mejor que preguntar simplemente si el cambio es bueno.

Esta misma división se aplica mucho más allá del código: autores y revisores, escritores y verificadores de hechos, generadores y jueces. Una vez que lo notes, verás con qué frecuencia las herramientas predeterminadas fusionan silenciosamente estos dos roles.

12. Evaluación: la barrera que hace confiable un ciclo

Un agente sin verificador es simplemente un chatbot que se invoca repetidamente. La evaluación determina si un resultado es lo suficientemente confiable como para actuar sobre él, fusionarlo o publicarlo. Utiliza tres niveles, que aumentan en costo y en el tipo de juicios que pueden realizar:

• Verificaciones deterministas. Las pruebas, los linters, los verificadores de tipo y las compilaciones ofrecen un resultado binario sin necesidad de juicio alguno. Son la primera y más económica barrera; siempre que una verificación determinista pueda rechazar una salida defectuosa, úsala.

Juez basado en LLM. Un segundo modelo evalúa los resultados del primer modelo según una rúbrica. Este método funciona cuando la rúbrica es específica, pero falla si es vaga. El juez debe ser al menos tan capaz como el modelo que genera los resultados y nunca se le debe indicar quién produjo dichos resultados. Gestionar adecuadamente a un juez constituye una disciplina en sí misma, abordada en gestionar LLM como juez como sistema de producción.

Aprobación humana. Las acciones irreversibles, como despliegues en producción, códigos de pago, actualizaciones forzadas y cambios arquitectónicos, requieren la aprobación de una persona antes de que el agente proceda. En LangGraph, interrupt_before permite esta pausa. Úselo únicamente para acciones cuya reversión sea costosa, en lugar de utilizarlo como medida para bloquear todo.

Para saber si la evaluación funciona, supervise la tasa de cambios aceptados. Si un agente diseñado para corregir pruebas fallidas resuelve el 70% de sus problemas con cambios que pasan la revisión automática y humana, su tasa es del 70%. Si es inferior al 50%, los humanos están dedicando su tiempo a terminar el trabajo que inició el agente, y el ciclo cuesta más de lo que ahorra.

13. Seguridad: un agente sin supervisión es una superficie de ataque sin vigilancia

Cualquier agente autónomo que interactúe con infraestructura real representa una exposición de seguridad al operar sin supervisión. El riesgo es concreto: mediante inyección indirecta de comandos, un agente que lee un correo electrónico o página web maliciosa puede ser manipulado para ejecutar las órdenes de un atacante. Las principales amenazas:

• Inyección a través de las salidas de las herramientas. Las páginas web, los problemas de GitHub y los tickets de soporte pueden ocultar instrucciones dentro de contenido ordinario, por ejemplo una línea que indica al agente que ignore instrucciones anteriores y elimine los archivos de prueba. La cuarentena es la defensa: cualquier agente expuesto a contenido no confiable recibe acceso solo de lectura. Mantenga separados los agentes que solo leen y aquellos que actúan.
• Crecimiento excesivo de permisos. Un agente validado con acceso solo de lectura recibe un permiso de escritura “solo por conveniencia”, y nadie lo revisa nuevamente. Revise periódicamente los permisos (un mes es un intervalo razonable) y otorgue únicamente lo mínimo necesario para la tarea.
• Secretos en los registros. El registro detallado en bucles que ejecutan durante mucho tiempo dispersa las credenciales en salidas que nadie monitorea. Desactive el registro detallado en los bucles de producción y sanee lo que quede.

Código generado sin revisión. Los agentes pueden abrir solicitudes de integración más rápido de lo que las personas pueden leerlas. Si el sistema de CI carece de análisis estático, auditorías de dependencias y escaneo de datos confidenciales, el código vulnerable puede llegar a la rama principal sin que nadie se dé cuenta. La automatización hace que estas verificaciones sean aún más importantes, no menos.

Un modelo de permisos hace que estas reglas sean explícitas. El ejemplo a continuación aprueba automáticamente acciones de solo observación como leer archivos, ejecutar pruebas y ver el estado o las diferencias de Git, pero requiere intervención humana para hacer push, editar archivos del entorno, modificar el código de pago y cualquier acción que incluya una marca de fuerza:

# Safe agent permission model
permissions = {
    "auto_approve": [
        "Read(*)",           # read anything
        "Bash(npm test)",    # run tests
        "Bash(git status)",  # observe state
        "Bash(git diff*)",   # observe diffs
    ],
    "require_human": [
        "Bash(git push*)",   # never push without approval
        "Edit(.env*)",       # never touch secrets
        "Edit(src/payments/*)",  # never touch payments code
        "Bash(*--force*)",   # never force anything
    ]
}

La prueba para cada regla es una sola pregunta: si esta acción resulta ser incorrecta, ¿cuán costoso es revertirla? Si la reversión es barata, se aprueba automáticamente; si es costosa, debe decidirlo un humano. Decidir caso por caso es cómo comienza el crecimiento excesivo de permisos.

14. Convertir las habilidades en una carrera

Un camino de aprendizaje debe llevar a algún lugar. A continuación se presenta una visión concreta de dónde se aplican estas habilidades.

Qué mostrar. Omita los clones de tutoriales. Tres proyectos reales que resolvieron problemas reales tienen mucho más valor:

• Un agente programado cuyos resultados se utilizan en la práctica, como el bucle creado en el paso 9.
• Un sistema de múltiples agentes en el que al menos dos agentes desempeñan roles diferentes que impiden estructuralmente que una sola instancia del modelo haga ambas cosas, como en el patrón maker-checker del paso 11.
• Un sistema de recuperación con métricas de evaluación documentadas, que muestre la situación antes y después de una corrección en la recuperación, en lugar de solo indicar que funciona.

Cuánto tiempo lleva. Como estimación aproximada, una persona que ya domina Python y estudia de 10 a 15 horas por semana puede esperar que este camino dure alrededor de ocho meses. Considérelo una cifra de planificación, no una promesa.

Dónde empezar. Los roles varían mucho en cuanto a su accesibilidad desde cero:

• Ingeniero de automatización con IA en una empresa cuyo negocio principal no es la IA. Se necesita alguien que pueda crear, por ejemplo, un bucle que corrija pruebas durante la noche. LangGraph, MCP y conocimientos básicos de CI son suficientes; no se requieren decenas de frameworks.
• Ingeniero de IA en una startup cuyo producto es un agente. Esto exige dominio completo de las etapas de recuperación de información, evaluación, diseño y despliegue de múltiples agentes, con estándares más altos y posibilidades mayores.

Ingeniero de infraestructura agente en una gran empresa tecnológica, lo que añade conocimientos especializados en sistemas distribuidos además de todo lo demás, y se trata de un puesto senior y no de un punto de entrada.

Lo que la mayoría de los planes de aprendizaje pasan por alto es que no es necesario saberlo todo antes de comenzar. Lo importante es tener un agente implementado que resuelva un problema real, pruebas de que se puede cuantificar su éxito y la capacidad de explicar contra qué modos de fallo está protegido su diseño. Pocos candidatos cuentan con los tres elementos, y ningún certificado puede sustituirlos.

Conclusión

Por un tiempo, la mayor parte del potencial en la IA aplicada radicó en el prompt: una redacción mejor, un contexto más adecuado y resultados de un solo intento más precisos. A medida que los modelos se han vuelto lo suficientemente capaces para actuar, ese potencial ha pasado a otro nivel, al sistema que decide en qué trabajan los agentes, cuándo se verifica su salida, cómo se registran sus acciones y qué ocurre cuando fallan.

• Aprenda los conceptos antes que los marcos de trabajo, y evalúe cada herramienta según el tipo de fallo que previene: pereza, preferencias personales o desviación.
• Mantenga el estado fuera del modelo, en un archivo o base de datos que el agente vuelva a leer en cada ejecución.
• Nunca permita que el autor de un cambio sea también su revisor; dele al revisor únicamente el resultado del trabajo y una rúbrica específica.
• Estructure la evaluación desde verificaciones deterministas, pasando por jueces, hasta la aprobación humana, y mida la tasa de cambios aceptados.

Permite controlar los permisos según la reversibilidad, manteniendo a los agentes que leen contenido no confiable alejados del acceso de escritura.

Nada de esto requiere formación en investigación ni experiencia en ajustes detallados. Se necesita un conocimiento sólido de Python, una comprensión clara de las formas en que los LLMs cometen errores, y el hábito de implementar la verificación antes del propio bucle. Crea el primer agente, déjalo ejecutarse durante la noche y revisa sus cambios por la mañana.

Lecturas relacionadas

• De un chatbot de un solo nodo a un agente respaldado por MCP en LangGraph — Construye una aplicación de LangGraph capa por capa: estado y reductores, bordes, bucles de herramientas, hilos con puntos de control, tres modos de transmisión en tiempo real y herramientas proporcionadas a través de MCP.
• Diseñando una memoria de agente de cuatro capas con LangGraph y Amazon Bedrock — Aprenda a dotar a los agentes de LLM de memoria episódica, semántica y procedural funcional en Bedrock y LangGraph, así como a protegerla contra el envenenamiento de datos, fugas de PII y filtraciones entre usuarios.