Contextual Visual Personalization in E-Commerce

A Picsha AI Technical Whitepaper | July 2026

Abstract

Traditional e-commerce platforms rely on a static visual catalog: every visitor, regardless of context, sees the same product photos. Dynamic visual personalization has historically been impractical due to the massive cost of manual editing, storage bloat, and the slow turnaround of traditional render pipelines.

By combining Agentic Infrastructure with the Magic Image Manipulation Interface (MIMI), Picsha AI makes visual personalization practical at production scale. This document defines the architecture of a Shopping Assistant Agent that transforms product images based on user context (location, weather, preferences, and browsing intent) — and shows how two complementary rendering paths, generative MIMI and deterministic compositing, cover the full spectrum from bespoke one-off creative to catalog-wide personalization.

The economic insight is simple: a personalized render is expensive exactly once. A single 16¢ generative render of a backpack on a rain-soaked trail is amortized across every shopper in rainy Seattle who views that product, because identical request configurations are served from the derivative cache in under one second — without ever touching the generative model again.

I. The Dynamic Personalization Architecture

Visual personalization operates in real time during a user session. A Conversational Shopping Assistant acts as the orchestrator, communicating with Picsha via the Agent-to-Agent (A2A) protocol to query and transform product assets on demand.

[ User Interaction ] ──> [ Shopping Assistant Agent ] <── [ Weather/Context API ]
                                    |
                                    |  A2A: message/send
                                    v
                           [ Picsha A2A Agent ]
                                    |
                                    |  canonical render URL
                                    v
                    [ Picsha Delivery Pipeline @ CDN Edge ]
                          |                    |
                     cache hit             cache miss
                          |                    |
                  cached derivative     MIMI render, then
                      (< 1s)          cached for all future
                                           visitors

The Personalization Flow:

1. Context Resolution: The Shopping Assistant Agent detects the user's current session parameters (e.g., browsing a hiking backpack from Seattle, where it is currently raining).
2. Intent Structuring: The Assistant maps that raw context onto a canonical context template — a small, fixed vocabulary such as weather=rain, region=pnw, intent=trail. This canonicalization step is what makes personalization cacheable (see Section III).
3. A2A Request: The Assistant calls the Picsha A2A Agent:

   {
     "jsonrpc": "2.0",
     "method": "message/send",
     "params": {
       "message": {
         "kind": "message",
         "role": "user",
         "parts": [{
           "kind": "text",
           "text": "Generate a dynamic render URL for backpack asset '550e8400-e29b-41d4-a716-446655440000'. Use the canonical context template: weather=rain, region=pnw, intent=trail. Fit it to 800x800."
         }]
       }
     }
   }
   

4. Autonomous Execution: The Picsha A2A Agent executes its generate_render_url tool with the canonical parameters supplied by the Assistant, producing a deterministic render URL such as: https://cdn.picsha.ai/render/550e8400-e29b-41d4-a716-446655440000?w=800&h=800&mimi=rainy%20trail%20pnw
5. MIMI Delivery: Picsha's delivery pipeline at the CDN edge checks whether this exact configuration has been rendered before. If yes, it serves the cached derivative in under one second; if no, it performs the AI render via MIMI, stores the derivative, and every subsequent visitor with the same context gets the cached result.

The Composite Fast Path (Recommended for Catalog Scale)

For high-traffic personalization, Picsha offers a deterministic alternative to generative rendering that removes AI inference from the request path entirely:

1. At ingest, product images uploaded with "remove_background": true receive a stored alpha cutout — computed once per unique image, with content-hash deduplication ensuring re-uploaded duplicates never pay twice.
2. Once per context, the retailer registers pre-rendered scenes (e.g. Miami_Sunny, London_Rainy) in the org's Backgrounds Library (POST /v1/backgrounds).
3. At request time, ?bg_asset=<backgroundId> composites the cutout over the scene — pure CPU work, no generative model and no generative charge. Cold composites complete in single-digit seconds; cached composites are immutable CDN objects served at standard edge latencies.

Choosing a Path

Generative MIMI remains the right tool for bespoke scene generation; the composite path is the right tool where the same handful of contexts applies across thousands of products.

II. Shopping Assistant Agent Tools

To make the Shopping Assistant Agent autonomous, it should be equipped with specific tools to resolve context and communicate with Picsha. We recommend the following tool definitions:

1. get_user_context()

Resolves the browser session context, including geolocation, current local weather, and past shopping category interest.

• Returns: { location: "Seattle", weather: "rainy", temperature: "54F", currentCategory: "outdoors" }

2. query_picsha_agent(prompt: string)

Uses the A2A protocol to interact with Picsha's agentic endpoints using natural language.

• Arguments: prompt (e.g., "Search for hiking backpacks and return the top match")
• Returns: Structured asset data including thumbnail_url and original id.

3. build_personalized_render(assetId: string, contextParams: object, layout: object)

Maps canonical context parameters onto a strict MIMI template and requests the render URL from Picsha.

• Arguments:
  • assetId: ID of the target product.
  • contextParams: Canonical environment parameters (e.g. { weather: "rain", region: "pnw" }).
  • layout: Height, width, and crop instructions.
• Returns: A dynamic CDN rendering URL: https://cdn.picsha.ai/render/550e8400-e29b-41d4-a716-446655440000?w=800&h=800&mimi=rainy%20trail%20pnw

III. Edge Cache Optimization

Running generative model processing on every page load would cause costs to skyrocket and introduce unacceptable latency (a cold 2K generative render takes ~25–29 seconds). Picsha solves this with content-addressed derivative caching built into the image delivery pipeline:

1. Parameter Normalization: Instead of free-form natural language prompts (which would yield zero cache hits — every user's phrasing is unique), the Shopping Assistant Agent maps user context to strict, canonical parameters (weather=rain, region=pnw). Picsha normalizes the full transformation configuration (dimensions, format, standardized mimi template) into a deterministic configHash.
2. Derivative Indexing: Every rendered derivative is indexed by [sourceAsset, configHash]. Content-hash deduplication at ingest means duplicate uploads of the same product image resolve to the same source, so they share cached derivatives too.
3. Sub-second Delivery: Subsequent visits by the same user — or by any user with identical context (all users in rainy Seattle browsing the same backpack) — bypass the generative model completely: the edge resolves the configHash and redirects to the cached derivative in under one second. The derivative objects themselves are immutable and CDN-cached, so repeat views are served at standard edge latencies without touching origin at all.

This is the core scaling property: cost and latency are functions of unique contexts, not traffic volume.

IV. Concurrency and Scale: Asynchronous and Pre-rendered Execution Patterns

A cold MIMI generation is a heavyweight operation: ~11–14 seconds for a 1K Lite render (mimi_mode=lite), ~25–29 seconds for a standard 2K render, and ~30–33 seconds for native 4K (mimi_mode=4k) — with the free preview-faithful 4K export upscale (upscale=4k) adding only ~4 seconds when the 2K base is cached. The real-time story is the cache: identical request configurations return from the derivative cache in under 1 second. Because cold generations take tens of seconds, production architectures decouple generation from the page load using one of three execution patterns:

1. Asynchronous UI Hot-Swapping (Chat & Messaging)

In a chat interface, the Shopping Assistant Agent responds with the textual recommendation instantly, alongside a visual card showing a loading/shimmer skeleton placeholder for the image. Cached renders return in under 1 second, but a cold 2K generation takes ~25–29 seconds (or ~11–14 seconds via mimi_mode=lite), so the assistant triggers the render with async=true to keep the UI strictly non-blocking:

• Picsha immediately returns 202 { status: "processing", jobId }.
• The client polls GET /render/status/{jobId} (every 2–3 seconds with backoff); A2A clients receive task status updates over the protocol instead of polling.
• When the job reports completed, the frontend hot-swaps the skeleton loader with the rendered personalized image.

2. Pre-rendered Catalog Batching

Instead of on-the-fly rendering, the retailer runs a nightly job that pre-warms the cache. For the top 500 catalog items, it requests the 5 most common weather/geographic combinations (e.g. Miami_Sunny, London_Rainy, Seattle_Overcast). When users visit, the cache delivers every pre-rendered asset at sub-second speed — no visitor ever waits on a cold generation.

The composite fast path changes the economics of this batching dramatically. Rendering 500 products × 5 contexts generatively would cost $400 per refresh (2,500 renders at 16¢). With composites, the 5 scene backgrounds are registered once for the entire catalog, each product pays a single cutout charge at ingest, and the 2,500 product-by-context combinations are CPU composites carrying no generative charge. Pre-warming is a matter of issuing the bg_asset URLs in a nightly sweep — or simply letting first-visitor traffic populate the cache, since even cold composites complete in seconds rather than tens of seconds.

3. Background Email/Push Campaign Preparation

For marketing communications like cart abandonment, the personalization request is issued at the moment the event is triggered (e.g., 5 minutes after abandonment). By the time the email is compiled and dispatched (typically an hour later), the personalized asset is fully rendered and cached at the CDN edge — the tens-of-seconds cold render is invisible to the recipient. For fully generative campaign creative, POST /v1/assets/generate produces a brand-new asset from a text prompt; because generated images enter the standard ingestion pipeline, completion is signaled by the ordinary asset.processed webhook, making campaign automation fully event-driven.

V. Practical Personalization Scenarios

Each scenario also has a composite-path equivalent: register the beach track, the rainy pavement, and the evening living room once as Backgrounds Library scenes, and serve every product in the category against them with ?bg_asset= — pixel-consistent, deterministic, and free of generative charges.

By serving context-relevant imagery, retailers bridge the gap between studio product cataloging and real-world consumer aspirations — and because Picsha's caching makes cost a function of unique contexts rather than traffic, personalization that was previously reserved for hero campaigns becomes viable across the entire catalog.