The visual system
Superseded in part by higgsfield-as-art-director.md. The analysis of the current pipeline below is accurate. The recommendation to composite in code and treat full-render as a poor default did not survive probing the MCP surface — Higgsfield exposes a brand kit, 42 ad formats and ~60 presets, and the guardrail objection is answered by reading the render back rather than by controlling generation.
How a static is actually made today, why it looks the way it does, and what an art-director agent would need to do.
What happens right now
angle.scene_prompt (a text field a human typed)
│
▼
Higgsfield MCP ──▶ ONE photograph ← only if the format needs a scene
│
▼
satori → element tree to SVG
resvg → SVG to PNG ← headline, subhead, CTA, scrim, logo
sharp → composite over the scene, crop, JPEGOf the four formats in format-defs.ts, exactly one uses Higgsfield.
| Format | Uses Higgsfield? |
|---|---|
scene-headline | yes — one generated photograph |
proof-card | no — drawn entirely in code |
offer-card | no — drawn entirely in code |
native-text | no — drawn entirely in code |
So three quarters of what came out had no AI imagery in it at all. They do not look like Higgsfield because Higgsfield never touched them. They are text laid out by a renderer, using two hand-written layout specs.
This also explains the sharpest complaint: the proof card and the offer card were near-identical because they are the same code-drawn text card, taking the same thin copy, differing only in my layout code. Different UI, same ad.
Higgsfield and Claude are not alternatives
They are different jobs, and conflating them is why the question comes up.
| What it does | What it cannot do | |
|---|---|---|
| Higgsfield | Generates pixels — photography, illustration, video | Decide what should be shown, or judge whether it worked |
| Claude | Language and judgment — direct, prompt, critique, reject | Generate an image. It has never made a pixel |
Higgsfield is the renderer. Claude is the art director. A system with only Higgsfield produces technically good images of the wrong thing. A system with only Claude produces excellent instructions and no output.
On the transport: MCP over REST for Higgsfield because MCP exposes Marketing Studio, presets and the apps marketplace, where REST exposes raw generation only. That decision stands.
The real ceiling is satori, not Higgsfield
The design quality of a composited creative is bounded by the renderer, and satori implements a subset of CSS. No filters, no blend modes, no masks, limited gradients, no real typographic control beyond size and weight. Two hand-written layouts sit on top of that.
That is the actual reason output looks templated. It is not the image model.
Four ways to render, honestly compared
| How | Design ceiling | Cost | Text | |
|---|---|---|---|---|
| A. satori + sharp *(today)* | Code draws layers over an optional scene | Low | ~50ms, free | Perfect |
| B. Higgsfield makes the whole ad | Image model renders everything | High variety | credits per variant | Unreliable |
| C. Headless browser | Real HTML and CSS to PNG | High | ~1–2s, ~500MB | Perfect |
| D. Scene from Higgsfield, overlay in a browser | C's design over A's reusable scene | High | ~1–2s | Perfect |
B is tempting and wrong as a default: text inside generated images is still unreliable, brand colours are approximate, the logo is not really the logo, and every variant costs credits — which destroys the one-scene-many-creatives economics.
The recommendation is a split path, because the original cost decision assumed every render was equal and it is not:
- Exploration — satori, ~50ms, free. Dozens of variants, layout and copy exploration, previews.
- Deliverable — headless browser, ~1–2s, once, on the creative that was actually approved.
One or two seconds is irrelevant for something a human already chose. Fifty milliseconds matters when generating twelve. The earlier decision to rule out a browser entirely was right for volume and wrong for the final artefact.
What an art director agent has to do
Four jobs, deliberately separate — one pass doing all four averages them, which is the mechanism in rules/taste.md.
1. Visual concept. Given the insight, the format and the brand: what should be shown, and why does *this* image argue *this* point? Output includes what must not appear.
Today this step does not exist. scene_prompt is a static text field written once by a human, so every creative for that angle gets the same picture regardless of what it is arguing.
2. Scene prompt. Turn the concept into a generation prompt: subject, framing, lighting, lens, mood, negative constraints. Knows the model catalogue and presets, since prompt shape is model-specific.
3. Composition. Choose the layout the format and text weight demand. A dominant text-weight format must never receive a hero image — that is how a native post became three words on white.
4. Visual critic. Judge the rendered result, and be able to reject it:
- Does the image support the claim, or merely decorate it?
- Does it contradict anything in the knowledge base?
- Does it show a third-party brand mark? This has already happened — a generated hinge carried a competitor's mark while supporting a claim about a different supplier (register #55).
- Is it recognisably this client, or would it suit any competitor — the swap test, applied to imagery.
- Are people, hands and text in the image structurally sound?
The critic is where the guardrail extends from words to pictures. Everything today checks what a creative *says*; nothing checks what it *shows*.
What Alex actually asked for
"I do not want statics that are purely posters where every client looks the same. What I want is a templated format, but the visuals — the way it brings out the points and the insights — can be different."
That maps exactly onto this split: format is the template, visual concept is per-insight. The missing piece is job 1. Formats are chosen and layouts are drawn, but nothing decides what this particular ad should show, so every creative for an angle inherits one static prompt.