## Problem Users hand agents visual information: a screenshot on a bug report, a diagram in a comment, an image file in the repository. Today none of it reaches the model. Tool results can only carry text, and the executor transport corrupts binary data, so an agent working on a bug report with a screenshot is effectively working blind. ## Desired outcome Add initial image input support to the Duo Workflow Service / AI Gateway so that: 1. An agent can read and actually "see" images attached to GitLab issue descriptions, MRs and comments 2. An agent can read and actually "see" image files in its local environment (local run or CI runner) 3. An image stays visible for the rest of the session, including after a resume, without inflating saved conversations 4. This works on any vision-capable model, including self-hosted ones, and is ignored gracefully on models without vision ## Image size handling Scope includes client-side compression of oversized PNG/JPEG images, targeting inputs up to 10 MB while retaining the 2 MiB per-image transport budget for image bytes before base64 encoding. The input file size limit and transport budget are distinct; format and dimension restrictions apply. The compression spike is complete ([#2839](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/work_items/2839)). Compression is tracked in [#2835](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/work_items/2835); its first draft [!4046](https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp/-/merge_requests/4046) was closed with the JSON-envelope design, and the work restarts on the typed `ImageResponse` path after the client MRs merge. Larger-input support is not yet shipped. This approach uses compression, not client-side downscaling. ## Why this is not trivial today - **Transport:** all executor responses are UTF-8 strings, and the GitLab proxy calls `response.text()`, so image bytes are silently destroyed on arrival - **Message shape:** a tool result is a plain string; nothing constructs an image content block - **Prompt layer:** every user message is re-rendered through a Jinja template, which flattens non-text content, and nothing checks whether the model can see ## Out of scope - Image support for legacy Duo Chat - Image support for external agents using proxy endpoints - User-attached images in chat / Slack ingest (foundations only, follow-up) - Non-image attachments (PDF, audio, video)