Adforge-AI

AdForge AI turns one product brief into brand-safe, multi-channel campaigns using live NVIDIA NIM agents, Genblaze media generation, and provenance-backed Backblaze B2 storage.

Comment 
## The Problem

Creative teams lose time moving between briefs, copy tools, image generators, spreadsheets, review threads, and file storage. The result is often a collection of disconnected AI outputs with no clear provenance, version history, approval workflow, or durable storage.

AdForge AI was built to solve that operational problem.

## Inspiration

We wanted to build something beyond a chatbot: a creative production system that could transform one product brief into a complete, reviewable campaign.

The project was inspired by one question:

> What if every AI-generated asset had the same accountability as a production asset created by a human team?

That means knowing the prompt, provider, model, generation run, checksum, quality score, revision history, approval state, and storage location.

## What We Built

AdForge AI turns one structured campaign brief into:

- Brand positioning and claim boundaries
- Campaign strategy and concept selection
- Channel-specific copy
- Visual briefs with prompts, crops, and constraints
- Generated media
- Automated quality evaluation
- One bounded revision when an asset needs improvement
- Human approval and secure download
- Searchable campaign memory

The workflow uses eight specialized stages:

1. Brand Analyst
2. Campaign Strategist
3. Copywriter
4. Visual Director
5. Media Producer
6. Quality Critic
7. Revision Manager
8. Campaign Curator

## NVIDIA NIM

Live text and multimodal reasoning run through NVIDIA NIM using open Llama models:

- `meta/llama-3.1-8b-instruct` for brand, strategy, copy, and visual reasoning
- `meta/llama-3.1-70b-instruct` for deeper reasoning and escalation
- `meta/llama-3.2-11b-vision-instruct` for visual evaluation

Every response is validated against a typed schema before moving to the next workflow stage. This prevents malformed or unstructured model responses from silently corrupting the campaign.

## Genblaze and Backblaze B2

Genblaze owns the media-generation boundary. It receives a typed visual-generation request containing the prompt, aspect ratio, and constraints. Genblaze runs the configured `gpt-image-1` image provider and returns the generated media, run ID, provider and model metadata, checksum, and sidecar manifest.

Backblaze B2 is the durable artifact layer. Generated images and manifests are stored in a private B2 bucket using versioned object keys:

```text
campaigns/{campaign_id}/genblaze/runs/{date}/{run_id}/assets/{asset_id}.png

The database stores:

  • B2 object key
  • Manifest key
  • SHA-256 checksum
  • Provider and model
  • Original and refined prompts
  • Generation attempt
  • Quality evaluation
  • Approval state
  • Parent version lineage

The browser never receives B2 credentials. When a user previews or downloads an asset, the FastAPI backend creates a short-lived signed URL for the private B2 object.

This makes Backblaze B2 more than file storage: it becomes durable campaign memory.

How It Works Technically

The frontend is built with Next.js and deployed on Vercel.

The backend is built with FastAPI and SQLAlchemy and deployed on Railway.

PostgreSQL stores:

  • Campaign state
  • Workflow events
  • Agent outputs
  • Generation runs
  • Quality evaluations
  • Asset approvals
  • Version lineage
  • Provenance metadata

The API is the trust boundary. Provider keys, database credentials, B2 credentials, orchestration state, and signed URL generation remain server-side.

The workflow is asynchronous and refresh-safe. Every stage persists an event, duplicate generation requests are idempotent, retries are bounded, and one failed channel becomes partial_success without deleting successful work.

Challenges

The hardest challenges were making the workflow reliable across multiple providers and keeping provenance accurate.

We had to handle:

  • Structured output validation from live model responses
  • Provider failures and bounded retries
  • Image-provider billing limits
  • Private B2 storage and signed retrieval URLs
  • Versioned asset lineage
  • Deployment differences between local SQLite and production PostgreSQL
  • CORS between separate Vercel and Railway environments
  • Accurate provider metadata across Genblaze and NVIDIA NIM

One important lesson was that a generated asset is not complete until its media, storage location, checksum, manifest, and provenance are all persisted.

What We Learned

We learned that production AI systems need explicit contracts and durable state.

The model is only one part of the product. The real value comes from the system around it:

  • Typed agent boundaries
  • Validated structured outputs
  • Clear provider metadata
  • Persistent workflow events
  • Human approval
  • Version lineage
  • Secure artifact storage
  • Short-lived signed downloads
  • Honest partial-success behavior

AdForge AI demonstrates a complete creative-operations loop:

brief → reason → generate → evaluate → revise → preserve → approve → deliver

The result is not just AI-generated content. It is a traceable, durable, and reviewable production campaign.

Built With

Share this project:

Updates

Submission history