El entusiasmo por los agentes aut\u00f3nomos impulsados por LLMs ha pasado de los laboratorios de investigaci\u00f3n a los roadmaps de producto de startups y grandes corporaciones en cuesti\u00f3n de meses. Sin embargo, la transici\u00f3n del prototipo \u2014donde un agente reserva una mesa o resume un PDF con \u00e9xito el 80% de las veces\u2014 a un sistema de misi\u00f3n cr\u00edtica en producci\u00f3n revela una brecha abismal. La premisa central que a menudo se ignora es que, a diferencia del software determinista tradicional, los sistemas ag\u00e9nticos son organismos vivos que mutan constantemente en producci\u00f3n.\n\nEsta volatilidad no es un bug, es una caracter\u00edstica intr\u00ednseca a la arquitectura: prompts que derivan (prompt drift), modelos base que se actualizan sin previo aviso, APIs de herramientas externas que cambian sus esquemas y, sobre todo, la explos\u00f3n combinatoria de estados que un agente puede alcanzar al encadenar razonamiento, uso de herramientas y memoria. Ignorar esta realidad lleva a los equipos a caer en anti-patrones que, aunque inocuos en un notebook de Jupyter, se convierten en pesadillas operativas a escala.\n\n1. El "Prompt Engineering" hardcodeado como configuraci\u00f3n est\u00e1tica\nEl error m\u00e1s com\u00fan es tratar los prompts como c\u00f3digo fijo en el repositorio. En producci\u00f3n, el prompt es el "sistema operativo" del agente. Si no tienes un sistema de versionado, A/B testing y \u2014cr\u00edticamente\u2014 evaluaciones autom\u00e1ticas (evals) para cada versi\u00f3n del prompt, est\u00e1s volando a ciegas. Un cambio menor en la redacci\u00f3n para corregir un caso edge en el formato de fecha puede romper la capacidad de razonamiento en cascada tres pasos m\u00e1s adelante. La soluci\u00f3n no es "mejores prompts", sino infraestructura de evaluaci\u00f3n continua.\n\n2. Acoplamiento fuerte entre el agente y las herramientas (Tools)\nDise\u00f1ar agentes que invocan funciones espec\u00edficas de forma r\u00edgida (ej. get_user_data_v2(params)) crea una dependencia fr\u00e1gil. Si la API interna cambia, el agente falla silenciosamente o alucina par\u00e1metros. La arquitectura robusta exige una capa de abstracci\u00f3n sem\u00e1ntica: el agente declara intenciones ("necesito el historial de compras") y un orquestador resuelve qu\u00e9 API versionada llamar, manejando transformaciones de datos y fallbacks. Esto desacopla el ciclo de vida del modelo del ciclo de vida del backend.\n\n3. Observabilidad basada solo en "logs de texto"\nDepurar un agente leyendo trazas de texto plano es arqueolog\u00eda, no ingenier\u00eda. Necesitas trazabilidad estructurada (spans) que capture: latencia por paso, tokens de entrada/salida por llamada, decisi\u00f3n de routing, herramienta invocada, \u00e9xito/fallo de la herramienta y estado de la memoria. Sin esto, no puedes detectar bucles infinitos, degradaci\u00f3n de calidad gradual (model drift) ni ataques de inyecci\u00f3n de prompt en tiempo real. Herramientas como LangSmith, Arize o Phoenix dejan de ser "nice-to-have" para ser infraestructura cr\u00edtica desde el d\u00eda uno.\n\n4. Gest\u00edn de estado y memoria ingenua\nMuchos equipos implementan memoria como un simple chat_history ilimitado inyectado en el contexto. Esto rompe la ventana de contexto, dispara costos y confunde al modelo con ruido irrelevante de hace 20 turnos. La memoria en producci\u00f3n requiere arquitectura jer\u00e1rquica: memoria de trabajo (ventana deslizante), memoria epis\u00f3dica (res\u00f3menes vectoriales de interacciones pasadas relevantes) y memoria sem\u00e1ntica (hechos del usuario/entidad persistentes). Adem\u00e1s, se necesita una pol\u00edtica de "olvido" program\u00e1tica (GDPR, relevancia, coste).\n\n5. Ausencia de "Guardrails" arquitect\u00f3nicos (no solo de contenido)\nLos guardrails no son solo filtros de toxicidad. En producci\u00f3n necesitas l\u00edmites duros de arquitectura: m\u00e1ximo de pasos de razonamiento (max_turns), timeouts estrictos por llamada a herramienta, presupuestos de tokens por sesi\u00f3n, y circuit breakers que fuerzan escalado a humano o respuesta por defecto si el agente entra en bucle o supera umbrales de coste/latencia. El agente debe ser un proceso supervisado, no un demonio suelto.\n\nPor qu\u00e9 importa ahora: El salto de MLOps a AgentOps\nLa industria est\u00e1 acu\u00f1ando el t\u00e9rmino AgentOps para diferenciar la operativa de estos sistemas del MLOps cl\u00e1sico. En MLOps monitorizas m\u00e9tricas est\u00e1ticas (accuracy, drift de features) de un modelo est\u00e1tico. En AgentOps monitorizas trayectorias de ejecuci\u00f3n no deterministas de un sistema que toma decisiones. La complejidad se desplaza del entrenamiento del modelo a la orquestaci\u00f3n, la evaluaci\u00f3n offline/online y la resiliencia del grafo de ejecuci\u00f3n.\n\nLas empresas que ganen esta ola no ser\u00e1n las que tengan el "mejor prompt", sino las que construyan plataformas internas de AgentOps que permitan iterar r\u00e1pido con seguridad: desplegar nuevas versiones de prompts con feature flags, ejecutar suites de evaluaci\u00f3n sint\u00e9ticas y reales en CI/CD, y tener visibilidad total de qu\u00e9 decidi\u00f3 el agente y por qu\u00e9. El anti-patr\u00f3n definitivo es tratar al agente como una caja negra m\u00e1gica; la ingenier\u00eda seria lo trata como un sistema distribuido probabil\u00edstico que exige disciplina de sistemas, no solo magia de prompting.