image-generation-via-a2a

Image generation via A2A

The slides app's generate-image script has two paths:

1. A2A delegation to the Images app — preferred when IMAGES_A2A_URL (and ideally IMAGES_A2A_KEY or a shared A2A_SECRET) is configured. The Images app maintains brand libraries with reference images, palette, and style brief; every generation grounds in the user's chosen library.
2. Direct Gemini provider — fallback. Uses the slides app's generic DEFAULT_STYLE_REFERENCE_URLS and the user's GEMINI/OPENAI key. Works without the Images app, but generations are off-brand by default.

templates/slides/actions/generate-image.ts checks IMAGES_A2A_URL first; on success it returns the A2A reply verbatim. On any failure (network, timeout, blocked) it falls through to the direct provider — slides keeps working standalone.

When to use which path

You don't get to choose at the action layer — the script picks based on env. But you should know:

• Workspace deploys with both slides and images apps mounted should always have A2A configured. Nothing else is needed from the slides agent's side.
• Standalone slides deploys (no Images app) fall through automatically.

Calling explicitly from the agent

When generating images for slides, call:

pnpm action generate-image --prompt "..." --deck-id <id> --slide-id <id>

If A2A is configured, the script delegates and prints the Images agent's reply (which contains previewUrl, downloadUrl, embedPath). Parse those URLs out of the reply and drop the previewUrl into the slide HTML's <img src="...">.

The Images agent must mark delegated generations with source: "a2a" and callerAppId: "slides" when it calls generate-image-batch or refine-image. That keeps the Images audit log useful for design review.

Multi-slide image generation

Do not fire parallel add-slide calls into the same deck. Keep deck writes sequential: add one slide, wait for the result, then add the next slide. If a single slide needs several image variants, the image-generation action may request multiple variants internally, but the deck write itself should remain a single add-slide or update-slide call.

Iteration

When the user gives feedback ("make slide 3's hero darker, more navy"), call the Images A2A refine-image skill with the previous assetId (extracted from the previewUrl returned earlier) plus the new feedback. Replace only the slide-3 <img src="..."> with the new URL. Do not delete the prior asset — it stays in the library so the user can pick which version to keep.

What about the existing slides path?

It's preserved on purpose. If a workspace runs slides without images, generation still works — it just uses the slides app's generic style references instead of a curated library. Don't delete the direct path; it's our fallback.

Cross-app reply parsing

The Images A2A reply comes back as plain text in the callAgent return value. The Images agent (per its a2a-images skill) is instructed to include assetId, runId, previewUrl, downloadUrl, and embedPath exactly as returned by the action. Look for those keys in the reply text (they're typically formatted as a structured paragraph or JSON block).

If parsing the reply fails, surface "I couldn't parse the Images agent's response" to the user rather than guessing at URLs.