Your Agent Made the Image Responsive. Did It Keep the Important Part?

A card can fit the screen and still lose its meaning

A frontend agent adds a responsive image to a project card. The grid no longer overflows. On a phone, however, the project title inside the screenshot is cropped away, while a large desktop asset may still be downloaded.

Three questions have been collapsed into one: how large an asset to deliver, which composition to show, and how much layout space to reserve. Fixing only the CSS width does not settle the other two.

This guide is for designers and engineers reviewing image-heavy directories, portfolios and skill galleries. The aim is a usable visual reference across layouts, not simply a thumbnail with the right outer dimensions.

Methodology: separate delivery from composition

We checked web.dev's responsive-image guidance, MDN's picture-element reference and web.dev's layout-shift guidance on October 14, 2026. The proposed placement record and review cases below are our editorial recommendations.

We did not benchmark a production page, execute an image-generation Skill or measure a bandwidth improvement. Any claimed performance gain needs measurements from the actual implementation. The OpenAgentSkill Gallery is a place to explore creative references, not evidence that a particular image strategy will suit every layout.

Write the image's job before creating variants

Start with one placement, not an entire media folder. Record the source asset and attribution, the information that must remain visible, the intended frame shape, whether cropping is allowed and whether the user can open a larger version.

A decorative landscape and a screenshot documenting a tool's output need different treatment. In the screenshot, a label or key result may be the reason for showing the image. Cropping it to match neighboring cards can remove the evidence the card was supposed to provide.

Our proposed choices are:

These rules concern visual meaning. They do not replace source permissions or text alternatives. Do not have the agent invent missing portions of an author's example and present them as the original work.

Use resolution variants for the same composition

The web.dev responsive-image overview distinguishes descriptive source hints from explicit source selection. With srcset and sizes, a page provides candidates and layout information that help the browser choose an image for the viewing situation.

Our recommendation is to treat a resolution family as the same approved composition at different pixel sizes. Do not mix unrelated crops into that family and hope the browser will infer which one preserves the headline.

Ask the agent to explain the rendered image width in the actual grid. A card in a multi-column container is not necessarily as wide as the viewport. The sizes description should reflect the implemented layout, including its meaningful breakpoints, rather than being copied from another project.

Inspect the selected resource in the browser. A filename containing “mobile” does not prove that the resource was selected, and a sharp-looking screenshot does not reveal how many bytes were transferred. Do not promise a specific file choice across all browser conditions.

Use art direction when the composition must change

MDN's picture reference describes media-dependent source selection, alternative formats and art direction. It also explains the fallback img element. This is the appropriate distinction to consider when a narrow layout needs different visual content, rather than merely fewer pixels.

For a proposed product-demo card, the wide version might show a full workspace while the narrow version focuses on the actual output. Both should remain faithful to the same example and have a traceable source.

Approve each composition separately. Record what was removed and why the remaining view still communicates the intended result. If no acceptable crop exists, preserve the full aspect ratio or change the card layout. Do not hide the problem with a universal cover crop.

Format choice is another axis. Offering an alternative encoding does not authorize changing the subject or deleting explanatory text. Keep the content decision separate from the delivery optimization.

Reserve space for the image you actually show

The web.dev layout-shift guide recommends image dimensions or equivalent reserved space so the browser can allocate layout before an image finishes loading. It also covers responsive images and source dimensions for art-directed alternatives.

Our review recommendation is to compare the reserved frame with the actual composition at each breakpoint. If the desktop and narrow-screen versions use different shapes, a frame sized only for the desktop version is not a complete solution.

Keep unrelated layout changes out of the diagnosis. A banner appearing above the gallery or a late-loading font can also move content. Do not attribute every shift to the image or claim the page is stable because one image has width and height attributes.

A failed image should leave a coherent card with a usable title and destination. Avoid a success-looking generic illustration that disguises the missing source example.

Review the transition, not just two screenshots

Use a non-production page with one wide example, one tall specimen and one image with important text near an edge. These are proposed test fixtures, not tests executed for this article.

Check a narrow phone layout, the actual grid breakpoint and a wide layout. Inspect just below and just above the breakpoint. Record the rendered frame, selected image URL and whether the required subject remains visible.

Repeat with a fresh load under slower image delivery to inspect reserved space. For resource-selection measurements, record cache conditions and device settings; resizing an already-loaded page alone is not a controlled transfer comparison.

Open the full example through its intended link and verify its relationship to the thumbnail. Review a failed request as a separate state. Keep the observed results, not only the agent's explanation of what the markup should do.

Limitations and the final handoff

Responsive markup cannot recover unreadable text baked into a low-quality source, establish reuse rights or make a cropped chart truthful. Some examples need a different layout rather than a more elaborate image pipeline.

The final handoff should include the approved compositions, dimensions, source attribution, intended image role and actual browser observations. Browse the skills directory for frontend workflows, then ask the selected agent to preserve meaning as well as fit. A responsive image is successful when the right content remains understandable, not merely when its box stops overflowing.