Fable 5 Slideshows With Image Models

The useful idea behind pairing a reasoning model with an image model is division of labor.

• The reasoning model mines the audience, chooses an angle, and writes the slide arc.
• The image layer produces scene candidates.
• Ghostfeed stores the deck, places editable text, preserves background provenance, and creates variants.
• A person judges whether the sequence is worth publishing.

What Fable 5 should run

Use the reasoning model upstream:

1. synthesize customer evidence;
2. identify several distinct angles;
3. choose a hook mechanic;
4. write the job of every slide;
5. produce scene descriptions;
6. check whether the product earns its place in the story.

Do not ask it to generate the final flattened carousel. Keep the script and visual casting editable.

What the image layer should run

Generate or source scenes from the slide descriptions. Create candidates for the difficult slides rather than accepting the first result.

In Ghostfeed, backgrounds can come from Pinterest, workspace collections, product collections, avatar image pools, uploads, or external URLs. The selected source remains attached to the slide.

The handoff into Ghostfeed

The handoff should match the input:

• If Fable produced the complete concept and scene plan, start with From Prompt and pass the audience, angle, proof, and any @-mentioned products, collections, or avatars.
• If the job began from a working TikTok Photo Mode post or image-only Instagram carousel, use From Social so Ghostfeed preserves the source slide count and beat structure while rewriting the deck.
• If Fable already decided every slide and you want Claude to art-direct it through MCP, use From Scratch, then cast one background and place editable text on every slide.

Do not count the project as delivered when the model returns prose. Count it when the Director produces a ready deck, the human accepts the sequence, and the export is usable.

For a batch of follow-ups, start from that ready base in Generate variants. Ghostfeed drafts distinct hooks from the base and product context, then preserves or rotates each background according to its source pool. That prevents an uploaded product screenshot from being randomly replaced while still letting Pinterest and collection-backed slides change.

The concrete Fable-to-Ghostfeed handoff: Claude creates and art-directs an editable photo-mode deck through MCP.

What the human actually does

The human is not manually dragging every pixel. The high-value decisions are:

• whether the angle is real;
• whether slide one earns a swipe;
• whether the images feel native;
• whether the product proof is honest;
• whether the sequence repeats itself;
• whether the variant tests something meaningful.

Only after that division of labor works should you ask how many decks it can sustain.

"900 AI slideshows a week" is not a production plan.

It is a number with all the difficult units hidden.

How many slides per piece? How many image attempts per approved slide? How long does a reviewer spend? How many distinct concepts are underneath the output? Where do failed jobs go? Who approves claims?

Until those questions have answers, volume is marketing.

Here is the capacity model I would use before selling or staffing an AI slideshow operation.

Define the unit

Track at least four:

• storyboard: one approved narrative plan;
• slide: one approved image-copy composite;
• slideshow: one approved sequence;
• deployment: one slideshow published to one account or placement.

One seven-slide storyboard might produce:

• seven approved slides;
• two CTA variants;
• two platform assemblies;
• eight deployments.

That is not eight new ideas. It is one storyboard, perhaps eight slide variants, two slideshow assets, and eight deployments.

Start from approved output

The basic equation:

Generation throughput matters only if it is lower.

The full constraint is:

This is why "images generate in parallel" does not prove the operation scales. Parallel generation can turn one slow review queue into a mountain of unreviewed files.

Model attempts, not just slides

Let:

• S = slides per slideshow;
• A = average attempts per approved slide;
• R = percentage of slides requiring regeneration after sequence review;
• N = approved slideshows required.

Expected image generations:

Example:

• 20 approved slideshows;
• seven slides each;
• 2.2 attempts per approved slide;
• 15% sequence-review rework.

Call it 355 image generations—not 140.

If you quote the client on final slides while budgeting the renderer on ideal first attempts, margin will disappear inside retries.

Split attempt rates by slide class

One average hides where money goes.

If hand-interaction slides take 5.4 attempts and text-led scenes take 1.3, the storyboard can route around unnecessary hand shots before generation.

That is a creative improvement and a capacity improvement.

Calculate reviewer load

Suppose one seven-slide piece needs:

• 3 minutes to review the storyboard;
• 45 seconds per selected slide;
• 2 minutes for sequence review;
• 90 seconds for claims and CTA;
• 2 minutes average revision handling.

A reviewer with 300 focused minutes has a theoretical ceiling of:

That assumes:

• no client interruptions;
• no unclear briefs;
• no outages;
• no escalation;
• no duplicated work;
• no fatigue.

Plan below the theoretical ceiling. I would start with a 60–70% utilization target until the observed queue is stable.

Put limits on work in progress

More concurrent jobs make the dashboard look active while cycle time gets worse.

Use WIP limits:

When a stage hits its limit, upstream work pauses.

That backpressure is not a bug. It prevents expensive generation from outrunning judgment.

Persist every stage

A slideshow job should survive:

• worker restart;
• provider timeout;
• model outage;
• reviewer delay;
• changed copy;
• partial generation;
• duplicate webhook.

Store:

Every expensive result gets written immediately. Never hold 240 generated slides only in process memory and hope the final batch write succeeds.

Separate model QC from approval

A vision model can inspect:

• identity similarity;
• object count;
• text corruption;
• obvious anatomy errors;
• mismatch with the slide spec;
• continuity against adjacent slides.

It can return a reason code and evidence.

It cannot be the accountable owner for:

• whether a claim is supportable;
• whether a likeness is licensed;
• whether the story exploits a sensitive trait;
• whether a disclosure is adequate;
• whether the piece is good.

Automated QC reduces the candidate pool. Human approval decides what represents the brand.

The final capacity unit is the approved sequence, not six successful API responses.

Add client approval latency

Agencies often model internal production and ignore the customer.

If a client approves twice a week, producing 30 new sequences every day creates inventory, not throughput.

Measure:

• median approval time;
• 90th-percentile approval time;
• average revision rounds;
• percentage approved without change;
• claims requiring client evidence;
• assets blocked by missing access or rights.

Set a maximum approval queue and an expiry rule for time-sensitive work.

Example:

If a trend-dependent slideshow has not been approved within 48 hours, return it to strategy review instead of publishing stale work.

Price the operation from observed cost

Per-approved-slideshow cost:

Then add margin and a risk buffer.

Do not benchmark against "a full content team" unless the deliverable is truly comparable. A human strategist, designer, customer researcher, editor, and community manager do more than emit images.

Ramp through proven stages

Stage 1: five per week

Prove:

• storyboard schema;
• references;
• asset persistence;
• slide-level QC;
• sequence review;
• approval records.

Stage 2: five per day

Prove:

• concurrency limits;
• idempotent retries;
• reviewer dashboard;
• cost accounting;
• client handoff.

Stage 3: portfolio production

Add:

• workspace isolation;
• fair queue allocation;
• client-specific claim rules;
• per-client budgets;
• audit logs;
• performance lineage.

Stage 4: higher volume

Increase capacity only after the bottleneck has six to eight weeks of observed data.

The target might become 900 weekly deployments. It may be 90 genuinely different slideshows. It may be 20.

The right number is the maximum output the operation can approve, learn from, and distribute without degrading quality or account health.

The number I care about

Not slides generated.

Not posts scheduled.

I care about:

useful creative learnings per dollar of approved production

A system that publishes 50 sequences, kills three bad hypotheses, validates one proof pattern, and cuts review time next week is compounding.

A system that publishes 900 near-duplicates because the queue can is just a faster content mill.

Ghostfeed is built around reusable assets and explicit approval state: one piece of evidence can become an avatar, source frame, reaction, slideshow, and platform-ready asset without losing the chain. The operating advantage comes from that chain, not an inflated output counter.

For the creative handoff, use the AI slideshow storyboard and image-prompt system. For general queue architecture, read How to scale AI UGC production.