Aug 21, 2026

Building a production image-generation workflow

Image generation needs more than a prompt and an endpoint. Design for model capability, moderation, retries, provenance, cost, and evaluation.

TUTORIAL7 min readThe Currai team / Engineering

The smallest image-generation demo sends a prompt and receives pixels. A production workflow must also choose a capable model, control inputs, handle provider failures, store provenance, and determine whether the result is usable.

Treat image generation as an observable pipeline rather than a single API call.

Separate generation from understanding

Generation creates a new image from text or reference images. Understanding extracts information from an existing image. Some platforms expose separate endpoints even when both jobs share authentication and billing.

Choose the operation explicitly:

GoalOperation
Create a campaign visualImage generation
Produce variations from a product photoImage-to-image generation
Read a receiptVision understanding
Generate accessible alt textVision understanding
Inspect a generated asset for policy issuesVision understanding or classifier

Confusing these capabilities leads to incorrect model selection and opaque errors.

Define a generation contract

Do not pass arbitrary UI input directly to a provider. Normalize it into an internal request with fields such as:

type ImageJob = {
  prompt: string;
  model: string;
  size: { width: number; height: number };
  count: number;
  referenceImages?: string[];
  safetyProfile: "standard" | "strict";
  idempotencyKey: string;
};

Validate dimensions, formats, prompt length, reference-image limits, and model capabilities before sending the request. Record the normalized request, not secrets or unredacted sensitive assets.

Handle the asynchronous reality

Image calls are slower and heavier than typical text completions. Use a job state machine rather than holding a fragile browser request open:

queued → running → validating → complete | failed

Return a job identifier immediately. Retry only transient failures, apply idempotency so retries do not create duplicate billable images, and set a clear timeout. When providers return base64, persist the decoded asset to controlled storage before the temporary response disappears.

Validate the output before delivery

Provider success only proves that an image was produced. Product success may require:

  • Correct dimensions and file type
  • Prompt adherence
  • Legible text
  • Brand or style consistency
  • Absence of prohibited content
  • Acceptable visual artifacts
  • Accessibility metadata

Use deterministic checks for files and dimensions. Use classifiers, vision models, or human review for semantic requirements. High-impact or public-facing creative should retain an approval step.

Make routing observable

Fallbacks can improve availability, but changing image models may change style, safety behavior, cost, and prompt interpretation. Record which provider and model actually produced every asset, including version, latency, retries, cost, and moderation decisions.

Evaluate model changes on a representative prompt set. Compare adherence, visual defects, human preference, latency, and cost. Do not route only on price unless quality is already constrained by a passing threshold.

Trace image jobs with Currai

Currai can connect the user request, agent decision, generation call, validation step, and final outcome in one trace. That makes it possible to see whether failures came from the prompt, model, provider, moderation layer, or delivery pipeline.

Instrument the workflow with the Currai integration skill.

Sources and further reading

03

Keep going with nearby topics from the Currai blog.