Oracle AI Agent Memory 26.8: memoria de agentes con soporte de imágenes

🕒 Publicado en Zendoric: 23 de octubre de 2026 · 00:20
✨ Generado con IA · cómo se hace
El correo es un post invitado de Turing Post, firmado por Daniela Pavlenco de Oracle, que explica cómo Oracle AI Agent Memory 26.8 convierte el contexto visual en memoria empresarial persistente.
Por Turing Post (post invitado de Daniela Pavlenco, Oracle) · Thu, 22 Oct 2026.
El correo es un post invitado de Turing Post, firmado por Daniela Pavlenco de Oracle, que explica cómo Oracle AI Agent Memory 26.8 convierte el contexto visual en memoria empresarial persistente. El texto recorre cómo almacenar imágenes como registros duraderos en la base de datos, cómo buscarlas mediante descripciones de texto y cómo mantener ligera la recuperación diaria, descargando los bytes en bruto solo cuando una aplicación los necesita. Se acompaña de un cuaderno (notebook) llamado «Image-Aware AI Agent Memory». Turing Post introduce el tema indicando que últimamente ha dedicado mucha atención a la memoria de agentes: qué merece sobrevivir a una conversación, cómo se vuelve útil después y cómo preservar la evidencia visual detrás de una decisión.
Puntos clave del post. Oracle AI Agent Memory 26.8 puede persistir evidencia visual como registros de imagen en la tabla gestionada DOCUMENT. Las imágenes pueden ser registros independientes o formar parte del contenido ordenado de un MESSAGE, con partes de texto y de imagen. La búsqueda de imágenes se basa en texto: las descripciones o pies de foto son la representación buscable. La lectura por defecto omite los bytes en bruto, algo esperado y presentado como un comportamiento empresarial central. Las aplicaciones obtienen (hidratan) los bytes explícitamente con include_bytes=True cuando necesitan mostrar o reenviar la imagen original. El cuaderno de acompañamiento demuestra el flujo completo con una captura de pantalla de evidencia de soporte generada.
Capacidades de la versión, según el post. Los registros DOCUMENT de imagen permiten guardar en el esquema de memoria gestionado los bytes, el tipo MIME, la descripción, los metadatos y el estado, de modo que los agentes preserven evidencia visual como contexto duradero. Las partes de imagen en mensajes permiten que el contenido de un MESSAGE incluya texto e imágenes ordenados, por ejemplo para que un mensaje de usuario conserve la captura que lo acompañaba. La recuperación de imágenes basada en texto usa las descripciones asociadas, de modo que se puede localizar evidencia visual con lenguaje natural. La omisión de bytes por defecto mantiene ligera la recuperación normal y evita mover datos binarios por el contexto del agente sin querer. La hidratación explícita con include_bytes=True deja disponible la imagen original para mostrarla, reenviarla o auditarla. Por último, la validación en tiempo de ejecución comprueba las imágenes antes de persistirlas o procesarlas con un modelo, con límites configurables.
Por qué importa la memoria con imágenes. El post argumenta que la memoria persistente hace útiles a los agentes entre turnos y sesiones, pero que muchos flujos empresariales no son solo texto: un cliente puede adjuntar una captura de un error, un técnico de campo puede subir la imagen de un producto, o un flujo financiero puede incluir un recibo. Si la capa de memoria solo guarda texto, el agente puede perder evidencia visual relevante para una decisión posterior; por ejemplo, un turno de soporte posterior puede referirse a un error visto antes y, sin el contexto visual original, el agente podría no interpretarlo correctamente. La decisión de diseño clave es que el sistema no necesita devolver los bytes en cada recuperación: puede guardarlos en la base de datos, buscar mediante una representación de texto e hidratar los bytes solo cuando la aplicación lo pida.
Cómo funciona, en cuatro capas. Entrada: la aplicación aporta bytes, tipo MIME, descripción, metadatos y ámbito; el notebook genera un PNG y lo pasa como image_bytes a add_image_async. Persistencia: el esquema gestionado guarda la imagen como una fila DOCUMENT con document_type=image; la inspección SQL lee la tabla IMGDEMO268_DOCUMENT y comprueba DBMS_LOB.GETLENGTH(blob). Búsqueda: la descripción o el pie se convierte en la representación de texto usada por la búsqueda de imágenes, y search_async(record_types=['image']) devuelve la imagen actual. Lectura: por defecto no se devuelven bytes; con include_bytes=False se obtiene bytes=None y con include_bytes=True se devuelve un resumen de bytes.
Configuración de base de datos y requisitos. El notebook usa variables de entorno o secretos de Colab para las credenciales, por lo que el mismo código puede ejecutarse contra Autonomous AI Database u otro entorno de Oracle AI Database. Antes de abrir el pool de conexiones, establece un identificador de programa de Developer Hub mediante python-oracledb (oracledb.defaults.program = "devrel-developerhub-image-aware-agent-memory") para atribuir las sesiones de base de datos a este ejemplo.
Inicialización del almacén de memoria gestionado. La memoria con imágenes sigue el mismo patrón de almacén gestionado que otros flujos de Agent Memory. El notebook hace visible la política de esquema para que quede claro si el almacén puede crear objetos gestionados o debe reutilizar un esquema existente. Para un tutorial, CREATE_IF_NECESSARY es cómodo si el usuario de base de datos puede crear objetos; para el arranque en producción, REQUIRE_EXISTING es más seguro porque los cambios de esquema deben ser deliberados. El código de ejemplo crea un OracleDBMemoryStore con pool, embedder, memory_store_id, schema_policy, search_strategy=SearchStrategy.VECTOR y vector_dim configurado.
Imagen sintética de evidencia de soporte. El notebook genera su propia imagen en lugar de cargar una captura de cliente, para que el ejemplo sea reproducible y seguro de publicar. La imagen simula un caso de soporte: picos de timeout en el checkout, severidad, región y un siguiente paso recomendado. Es la entrada visual del resto del flujo, no una respuesta generada por IA.
Guardado de un registro de imagen independiente. La primera escritura guarda la captura generada como registro de imagen independiente, con ámbito user_id y agent_id pero sin asociarla a un hilo. La separación es intencionada: el notebook primero demuestra la memoria de imágenes independiente y después el contenido de imagen adjunto a mensajes. La llamada usa memory.add_image_async con image, description y mime_type=ImageMimeType.PNG.
🔗 Relacionadas en Zendoric
- Cómo la memoria persistente convierte a los agentes de IA en sistemas realmente agénticos · 2026-09-11
- ¿Qué debería recordar un agente? Memoria de agentes: personalización, automejora y memoria organizativa · 2026-10-18
- Oracle conecta la IA a sus políticas de nube: la batalla ya no es el modelo, es la fontanería · 2026-07-08


