Turning Sayura's Canva carousels into a reviewable LangChain production pipeline

At Sayura, a mindfulness and self-reflection app, an AI model could write a caption in seconds. Turning that caption into a carousel worth publishing still took far too long. Sayura is my own product, so this is an internal system, not client work. Its carousels had been made by hand in Canva, and AI content tools had been tried, but the frustrating work was never just writing a caption.

It was the coordination around it:

Content angle → hook → story → images → slide layout
→ quality check → my approval → rendering → publishing handoff

AI tools could help with isolated pieces. They did not reliably connect the workflow: captions, images, pacing, product messaging and the final output still needed manual coordination.

So the build was not “an AI carousel generator.” It was an internal, human-in-the-loop content-production system.

The actual problem

Sayura is a mindfulness and self-reflection product. Its content needed to feel native to TikTok while remaining sensitive, visually coherent and connected to the product.

A slideshow could start with a hook such as “A sign you’re carrying emotions that aren’t yours”. But getting from that line to a publishable five-slide sequence required many decisions:

• Is the hook clear enough to stop a scroll?
• Does the story earn the product mention rather than force it in?
• Do the images carry one emotional world across the sequence?
• Is the text readable on a phone?
• Does the finished asset arrive somewhere I can easily review and publish?

Fewer than 20 outputs were ultimately published. This is not a claim that I built an autonomous content machine or solved growth. It was a real internal production system that made a creative workflow more repeatable and inspectable.

The workflow

I used LangGraph, the workflow library in the LangChain ecosystem, to coordinate specialised stages rather than asking one model to do everything.

Creative brief
  → content strategy and slide copy
  → visual direction and image selection
  → QA and revision loop
  → human approval
  → Playwright rendering
  → Google Drive delivery and verification

The central design decision was a structured creative brief. Before any slide was generated, the system defined the format, tone, narrative arc, image arc, audience and product positioning. That brief became explicit shared state: a record each stage could read rather than re-infer from a long prompt.

That gave the copywriter, visual designer and QA stage the same shared context. Without it, each stage would improvise. The result might be individually decent slides that did not feel like one coherent piece of content.

Why this is more than a prompt workflow

The interesting engineering work was in state, failure handling and integration.

Design decision	Why it mattered
Structured creative brief	Made creative intent explicit and reusable across stages.
Specialist stages	Let me isolate whether a failure came from copy, visuals, QA, rendering or delivery.
QA rejection branch	Allowed the system to revise before a human saw the finished work.
Human approval gate	Kept final creative and publishing judgment with me.
Playwright rendering	Produced deterministic HTML/CSS layouts instead of asking an image model to reproduce typography reliably.
Idempotent Drive delivery	A retry reused the same output folder instead of generating duplicate files.

This is the part that maps best to forward-deployed engineering: starting with a real operating pain, translating it into an explicit workflow, integrating with the surrounding tools and making the system recover gracefully when something goes wrong. It follows the same principle as my AI Trust Ladder: use automation to prepare work, but keep a person at the point where an irreversible decision carries your name.

The difficult parts

The hardest problems were not “how do I call an LLM?” They were operational:

• Images could be aesthetically good but wrong for the narrative.
• A selected image could fail during rendering.
• Slide-to-slide consistency needed concrete rules, not a vague prompt.
• A successful upload call did not guarantee the right files arrived in the right place.
• Retrying a workflow could create duplicate outputs unless the system preserved state.

That led to a few important constraints:

• Rendering and uploading became separate stages.
• The system stored approved metadata before rendering.
• The upload stage reused its existing Drive folder on retries.
• The orchestrator verified final files before notifying me.
• Review was a real stopping point, not a cosmetic checkbox.

What the system actually produced

The emotional-containment carousel begins with “A sign you’re carrying emotions that aren’t yours.” It is one of fewer than 20 outputs I published. Each reviewed output was a five-slide sequence: a hook, the story, and a product-safe close.

It is better evidence than an agent trace: it shows the thing the workflow was built to deliver—a reviewable asset that could actually be published. The voice-affirmation and inner-noise examples show other outputs from the same production workflow.

What the project showed

A useful agent is not simply a model that can generate an answer. It is a workflow that knows:

• what state it owns;
• what quality bar it must meet;
• when to retry;
• when to stop; and
• when to ask a person to decide.

Newer models would likely improve the copy and visual reasoning in a rebuild today. But better models do not remove the need for workflow design. They make the surrounding design more important because the system can take more meaningful actions.

What comes next

If the project resumes, the next stages are:

1. A research stage that proposes timely content opportunities with sources and confidence.
2. A small evaluation set for hook quality, readability, visual consistency, CTA quality and Sayura brand fit.
3. Tracking for cost, latency, stage-level failures and reviewer rejection reasons.
4. A simple review interface for comparing variants and sending structured feedback.
5. More reusable deterministic templates before investing heavily in generated motion design.

Four questions for any agent workflow

The system is not autonomous for the sake of it; it is useful inside the messy work people already do. The same separation of generation, checking and approval appears in the supervised AI agent reply system.

Four questions apply to any agent workflow: Where does state live? Which failure can retry safely? What remains a human decision? What real output proves the workflow ran? If those answers are vague, it is probably a demo, not a system someone can rely on.