Oracle AI Agent Memory 26.8: agent memory with image support

By Turing Post (guest post by Daniela Pavlenco, Oracle) · Thu, 22 Oct 2026.

The email is a Turing Post guest post, written by Daniela Pavlenco of Oracle, explaining how Oracle AI Agent Memory 26.8 turns visual context into persistent enterprise memory. The text walks through how to store images as durable records in the database, how to search them via text descriptions and how to keep everyday retrieval lightweight, loading the raw bytes only when an application needs them. It comes with a notebook called "Image-Aware AI Agent Memory". Turing Post introduces the topic by noting that it has lately paid close attention to agent memory: what deserves to survive a conversation, how it becomes useful later and how to preserve the visual evidence behind a decision.

Key points of the post. Oracle AI Agent Memory 26.8 can persist visual evidence as image records in the managed DOCUMENT table. Images can be standalone records or part of the ordered content of a MESSAGE, with text and image parts. Image search is text-based: descriptions or captions are the searchable representation. Reads omit the raw bytes by default, which is expected and presented as core enterprise behaviour. Applications fetch (hydrate) the bytes explicitly with include_bytes=True when they need to display or forward the original image. The accompanying notebook demonstrates the full flow with a generated support-evidence screenshot.

Release capabilities, according to the post. Image DOCUMENT records allow the bytes, MIME type, description, metadata and status to be stored in the managed memory schema, so agents preserve visual evidence as durable context. Image parts in messages allow MESSAGE content to include ordered text and images, for example so a user message keeps the screenshot that accompanied it. Text-based image retrieval uses the associated descriptions, so visual evidence can be located with natural language. Omitting bytes by default keeps normal retrieval lightweight and avoids unintentionally moving binary data through the agent's context. Explicit hydration with include_bytes=True makes the original image available for display, forwarding or auditing. Finally, runtime validation checks images before persisting them or processing them with a model, with configurable limits.

Why image-aware memory matters. The post argues that persistent memory makes agents useful across turns and sessions, but that many enterprise workflows are not text-only: a customer may attach a screenshot of an error, a field technician may upload a product image, or a finance workflow may include a receipt. If the memory layer only stores text, the agent may lose visual evidence relevant to a later decision; for example, a later support turn may refer to an error seen earlier and, without the original visual context, the agent might misinterpret it. The key design decision is that the system does not need to return the bytes on every retrieval: it can store them in the database, search via a text representation and hydrate the bytes only when the application asks for them.

How it works, in four layers. Input: the application provides bytes, MIME type, description, metadata and scope; the notebook generates a PNG and passes it as image_bytes to add_image_async. Persistence: the managed schema stores the image as a DOCUMENT row with document_type=image; SQL inspection reads the IMGDEMO268_DOCUMENT table and checks DBMS_LOB.GETLENGTH(blob). Search: the description or caption becomes the text representation used by image search, and search_async(record_types=['image']) returns the current image. Read: no bytes are returned by default; include_bytes=False yields bytes=None and include_bytes=True returns a byte summary.

Database configuration and requirements. The notebook uses environment variables or Colab secrets for credentials, so the same code can run against Autonomous AI Database or another Oracle AI Database environment. Before opening the connection pool, it sets a Developer Hub program identifier via python-oracledb (oracledb.defaults.program = "devrel-developerhub-image-aware-agent-memory") to attribute database sessions to this example.

Initialising the managed memory store. Image-aware memory follows the same managed-store pattern as other Agent Memory workflows. The notebook makes the schema policy visible so it is clear whether the store can create managed objects or must reuse an existing schema. For a tutorial, CREATE_IF_NECESSARY is convenient if the database user can create objects; for production startup, REQUIRE_EXISTING is safer because schema changes should be deliberate. The sample code creates an OracleDBMemoryStore with pool, embedder, memory_store_id, schema_policy, search_strategy=SearchStrategy.VECTOR and a configured vector_dim.

Synthetic support-evidence image. The notebook generates its own image instead of loading a customer screenshot, so the example is reproducible and safe to publish. The image simulates a support case: checkout timeout spikes, severity, region and a recommended next step. It is the visual input for the rest of the flow, not an AI-generated response.

Saving a standalone image record. The first write saves the generated screenshot as a standalone image record, scoped with user_id and agent_id but not associated with a thread. The separation is intentional: the notebook first demonstrates standalone image memory and then image content attached to messages. The call uses memory.add_image_async with image, description and mime_type=ImageMimeType.PNG.