Puntos clave
- Trata el modelo como sin estado; haz que un almacén externo sea la fuente de verdad para el estado del flujo de trabajo.
- Separa el contexto de trabajo, el estado a corto plazo y la memoria a largo plazo, cada uno con sus propias reglas de retención.
- Las acciones idempotentes hacen que los reintentos sean seguros y evitan cobros dobles o envíos duplicados.
- Usa un sandbox para los agentes con permisos de denegación por defecto y registra cada llamada a herramientas.
- Eres legalmente responsable de las acciones de tus agentes, así que construye el registro de auditoría para demostrar el control.
Cada semana trae una nueva oleada de agentes de IA: Meta lanza una mascota simpática, OpenAI agrupa funciones existentes en una persona amigable, HubSpot renombra su stack por cuarta vez. Los anuncios se confunden entre sí. Pero debajo del marketing, la verdadera pregunta de ingeniería apenas ha cambiado: ¿cómo recuerda un agente lo que hizo, mantiene el estado entre pasos y lo hace sin crear riesgos operativos o legales? Ahí es donde la mayoría de los proyectos en producción viven o mueren.
Por qué la memoria es la parte difícil, no el modelo
Los modelos de frontera ya son lo suficientemente buenos. Como señala Zapier, incluso el modelo Claude más pequeño de Anthropic ahora supera a los mejores sistemas de hace dos años. El razonamiento puro rara vez es el cuello de botella. Lo que falla en producción es la continuidad: un agente que olvida el mensaje anterior de un cliente, vuelve a ejecutar una acción facturada o pierde el rastro de dónde estaba en un flujo de trabajo de varios pasos.
La "memoria" de un agente son en realidad tres cosas distintas, y confundirlas es el error de diseño más común que vemos:
- Contexto de trabajo — la conversación y la tarea actuales, mantenidas en la ventana del prompt. Rápido, pero efímero y costoso de ampliar.
- Estado a corto plazo — dónde se encuentra el agente en un flujo de trabajo: qué herramientas invocó, qué tuvo éxito, qué está pendiente. Esto pertenece a una base de datos o a una máquina de estados, nunca solo al prompt.
- Memoria a largo plazo — hechos duraderos sobre un usuario o cuenta, normalmente almacenados en un índice vectorial o un almacén estructurado y recuperados bajo demanda.
Herramientas como los "dots" de OpenAI o Muse de Meta empaquetan estas capas detrás de una persona, lo cual es un diseño de producto excelente pero no elimina la responsabilidad subyacente. Si construyes sobre sus APIs, sigues siendo dueño de las decisiones de arquitectura sobre qué persiste, durante cuánto tiempo y dónde.
El estado pertenece fuera del modelo
El patrón que sobrevive al contacto con la producción es simple: tratar el modelo como sin estado y hacer que un sistema externo sea la fuente de verdad. Cada paso del agente lee el estado, actúa y vuelve a escribir el nuevo estado. Si una ejecución falla, reanudas desde el último punto de control duradero en lugar de reproducir desde cero.
Esto es lo que distingue la ejecución genuina de flujos de trabajo —del tipo que el AutomationBench de Zapier prueba de extremo a extremo con herramientas reales— de un chatbot que simplemente llama a funciones. La idempotencia también importa aquí: un agente que podría reintentar un paso nunca debe cobrar dos veces una tarjeta ni enviar una factura duplicada. Almacena una clave de operación, verifícala antes de actuar, y el reintento se vuelve seguro.
La higiene de la memoria ahorra dinero y confianza
La memoria sin límites es un asesino silencioso. Meter todo en el contexto infla los costes de tokens y degrada la calidad del razonamiento. El enfoque disciplinado es resumir y podar: comprimir los turnos antiguos en un breve resumen de estado, promover solo los hechos duraderos al almacenamiento a largo plazo y establecer políticas de retención por tipo de dato. Esto también te mantiene alineado con el RGPD: una memoria que recuerda a un cliente indefinidamente es una responsabilidad, no una funcionalidad.
Contener lo que el agente puede hacer
La memoria decide lo que un agente sabe; el sandboxing decide lo que puede hacer. El reciente lanzamiento de OpenShell por parte de NVIDIA adopta una postura de denegación por defecto: cualquier cosa que ninguna regla permita explícitamente queda bloqueada. Esa filosofía debería guiar a cualquier agente en producción, independientemente de las herramientas. Da al agente el conjunto más reducido de acciones permitidas, registra cada llamada a herramientas y mantén a las personas en el circuito para las operaciones de alto riesgo.
Esto no es paranoia. OpenAI notificó a más de cien organizaciones sobre la actividad de agentes durante el entrenamiento de modelos, un recordatorio de que los agentes actúan de formas que sus operadores no siempre anticipan.
Eres responsable de lo que hacen tus agentes
Los términos comerciales están convergiendo entre OpenAI, Anthropic y Google Cloud, y todos apuntan en la misma dirección: el cliente es responsable de su cuenta y de las acciones de sus agentes. La responsabilidad suele estar limitada a doce meses de tarifas, los servicios en beta están excluidos y las indemnizaciones son limitadas. Para una empresa que despliega agentes que tocan sistemas reales y dinero real, esto reformula todo el proyecto.
Significa que tu registro de auditoría, tu registro de estado y tus límites de permisos no son solo detalles de ingeniería: son tu defensa. Cuando un agente hace algo inesperado, necesitarás mostrar exactamente qué vio, qué decidió y qué estaba autorizado a hacer.
Lo que recomendamos
Para los equipos que llevan agentes del piloto a la producción, las prioridades son consistentes:
- Externaliza el estado; mantén el modelo sin estado y reanudable.
- Separa el contexto de trabajo, el estado del flujo de trabajo y la memoria a largo plazo, y aplica reglas de retención a cada uno.
- Haz que cada acción sea idempotente para que los reintentos sean seguros.
- Usa un sandbox con permisos de denegación por defecto y registra cada llamada a herramientas.
- Asume que eres legalmente responsable del agente y construye el registro de auditoría para demostrar el control.
El modelo que elijas importa menos que el andamiaje que lo rodea. Acierta con la memoria, el estado y la contención, y un modelo modesto se convierte en un colega fiable. Fállalos, y el modelo de frontera más capaz se convierte en una responsabilidad costosa y olvidadiza.
Fuentes
- Modelos Claude: Fable vs. Opus vs. Sonnet vs. Haiku — Blog de Zapier
- Agente de IA Meta Muse: cómo usar el agente de IA personal — Blog de Zapier
- Herramientas de IA de HubSpot: una guía completa de Agent Hub y Breeze — Blog de Zapier
- NVIDIA livre OpenShell pour borner les agents, Sentry reste sans date — Actu IA
- Dots : un bon coup produit, pas une rupture technique — Actu IA
- Agents IA : le client répond de leurs actes, chez OpenAI comme ailleurs — Actu IA
