← All posts
AI SearchCreative Strategy

How to Design an AI Agent Workflow for Creative Production

A practical seven-layer blueprint for building creative-production agent workflows that preserve control over context, spend, approvals, recovery and delivery.

Harsh

Harsh

Cofounder at AdviblyUpdated

Pastel seven-layer creative machine turning source cards into one delivered package.

An AI agent workflow should not give a model unrestricted control over a campaign. It should give the model room to reason where the work is uncertain, while keeping identity, permissions, spend, state changes, approval and delivery explicit.

For creative production, the most reliable design is a seven-layer system: job contract, context, capabilities, control flow, state and artifacts, controls, and completion. That structure turns “make a campaign” into a run an operator can inspect, pause, recover and verify.

The practical rule is simple: use the least agentic architecture that can handle the uncertainty. Let the model interpret a brief, compare concepts and diagnose failures. Use deterministic rules for everything that must remain repeatable or safe.

Key Takeaways

  • Give each run a bounded job contract with observable acceptance criteria.
  • Keep model reasoning inside deterministic boundaries for permissions, spend, approvals, state, and delivery.
  • Treat retrievable artifacts, versioned approvals, and delivery receipts as completion evidence.

An agent is not the same as a workflow

The terms are often collapsed, but the distinction changes how you build the system.

A workflow follows predefined routes. Code decides which stage comes next and how outputs move between stages. An agent can assess the current state, choose an action, use a tool, inspect the result and adjust its approach.

Anthropic draws this line directly: workflows use predefined routes, while agents dynamically direct their own process and tool use. Its engineering guidance also recommends starting with simple, composable patterns rather than adding autonomy by default (Anthropic, “Building Effective AI Agents”). OpenAI describes an agent around three elements: a model that manages execution, tools that let it gather information or act, and instructions and guardrails that define its behavior (OpenAI, “A Practical Guide to Building Agents”).

A production system can, and usually should, contain both. The workflow provides the rails. The agent handles the decisions that cannot be reduced to a stable rule.

For example, “export every approved static in the required aspect ratios” is a workflow step. “Choose the concept that best expresses the offer without making an unsupported claim” needs interpretation. Putting both decisions inside one unconstrained agent makes the system harder to predict. Hard-coding both makes the creative work brittle.

The seven-layer production blueprint

The hardest part of an AI agent workflow is not choosing a model. It is defining what the system is allowed to know, change and call complete. These seven layers make those boundaries visible.

An AI agent workflow cutaway with a branching reasoning chamber surrounded by locked context, permissions, persistent state, retry, approval, and delivery modules.

Layer

Question it must answer

Minimum production requirement

1. Job contract

What outcome is this run responsible for?

Owner, audience, outputs, constraints, deadline and acceptance criteria

2. Context

What is true, and what applies only to this campaign?

Separate canonical brand truth from run-specific direction

3. Capabilities

What can the system read, create or change?

Named tools, permissions, expected inputs and returned results

4. Control flow

Which decisions are fixed, and which require judgment?

Deterministic stages with bounded reasoning inside them

5. State and artifacts

What happened, and what can be resumed?

Stable run identity, unit-level status, versions and retrievable outputs

6. Controls

Which consequences require approval or escalation?

Spend limits, approval gates, timeouts and bounded retries

7. Completion

What evidence proves the job is finished?

Required deliverables, delivery receipts and unresolved-risk record

1. Start with a job contract, not an open-ended request

A usable job contract names the actor, desired outcome, constraints, deadline, destinations and acceptance criteria. For a product launch, that might mean two static ads, one carousel and one short video for a defined audience, using only approved product claims and staying within a fixed generation budget.

Acceptance criteria should be observable. “Make it engaging” gives the system no reliable finish line. “Use the approved offer, preserve the product interface, fit the channel dimensions and route the final set to a named approver” can be checked.

The contract also limits scope. If the run is responsible for producing approved assets, it should not quietly rewrite brand positioning, buy extra credits or publish the campaign unless those actions are explicitly included.

2. Separate durable context from campaign direction

Creative production uses at least two kinds of context:

  • Canonical context: product facts, approved claims, logos, colors, fonts, audience definitions and durable brand guidance.
  • Run context: this campaign’s offer, channel, theme, references, deadline and temporary creative direction.

Do not let temporary campaign direction silently overwrite durable brand truth. A holiday campaign may use a playful visual treatment; that does not make “playful” the permanent brand standard. The system should compare the run brief with canonical context, surface conflicts and ask for a decision when the two cannot both be satisfied.

This separation also improves recovery. A failed run can be restarted from the same approved inputs without contaminating future work.

3. Treat tools as explicit capabilities, not assumed magic

Each capability should have a clear job: read brand context, retrieve a product asset, generate an image, create a video, revise an output, check available credits or deliver an approved asset.

Before execution, confirm the live tool surface and its permissions. Documentation can be stale, and tool descriptions are not proof that a specific action will behave as expected. The Model Context Protocol specification also cautions that tool annotations should be treated as untrusted unless the server itself is trusted (MCP specification, “Tools”).

MCP can standardize how an agent discovers and calls tools. It does not, by itself, supply your application’s durable state, retry policy, approval model or recovery logic. Those remain orchestration responsibilities.

4. Put deterministic control around bounded reasoning

Draw the run as a state machine before deciding where an agent belongs:

Brief accepted → context checked → concepts proposed → concept approved → assets generated → assets reviewed → destination approved → delivered

Then mark the decisions that genuinely benefit from reasoning:

  • interpreting an incomplete brief;
  • finding conflicts between the offer and approved product truth;
  • proposing distinct concepts;
  • choosing an appropriate creative format;
  • diagnosing why a generated asset failed review;
  • deciding whether a revision is likely to fix that failure.

Keep high-consequence transitions deterministic. The system should not improvise whether approval is required before paid generation, persistent context changes or publication. Anthropic’s research on trustworthy agents describes plan review and tool permissions as ways to preserve human control without forcing approval for every low-risk action (Anthropic, “Trustworthy Agents in Practice”).

The useful boundary follows consequence, not tool count. Reading approved brand context may be automatic. Spending beyond a limit or publishing to a public account should not be.

5. Persist state at the smallest useful unit

Creative jobs are often asynchronous and partially successful. A video may still be rendering while two statics are complete. One carousel slide may need revision while the rest are approved.

Store state for each unit, not only for the campaign as a whole. At minimum, keep:

  • a stable run identity;
  • the approved input version;
  • each step’s status;
  • generation and delivery identifiers;
  • retrievable source and final files;
  • the approval attached to each consequential transition;
  • the error class and retry count for failed units.

This makes selective recovery possible. If one video fails, retry that video. Do not regenerate the approved statics and spend the budget twice. If a worker stops while a render is pending, resume status checks using the saved generation identifier rather than submitting another render.

6. Gate consequences and bound retries

Approval before every read creates a human-operated queue wearing an agent costume. No approval before spend or publication creates unnecessary risk.

Use a small number of meaningful gates:

  1. Direction gate: approve the concept and copy hierarchy before expensive production fans out.
  2. Spend gate: approve the estimated paid generation work and enforce a ceiling.
  3. Truth gate: check claims, product representation and required disclosures before final delivery.
  4. Destination gate: approve where, when and with what accompanying copy the assets will be published or exported.

Retries need rules too. Classify the failure first. A temporary service error may justify retrying the same request. A rejected claim, impossible aspect ratio or weak concept requires a changed input or human decision. OpenAI’s agent guidance recommends human intervention when failure thresholds are exceeded or actions are high risk; guardrails complement rather than replace authentication and authorization (OpenAI).

A sensible recovery policy limits attempts per unit, preserves successful siblings and escalates repeated failures with the exact error and current state.

7. Define completion as evidence, not a confident sentence

“Done” should be a contract the system can verify. For a creative campaign, completion may require:

  • every required format exists and can be retrieved;
  • factual and technical checks have passed;
  • the approved version is the version delivered;
  • the destination returned a delivery receipt;
  • failed or omitted units are named;
  • remaining risk is visible to the owner.

A conversational status update is not completion evidence. Neither is a plan, a generated concept or an asset that exists somewhere but cannot be retrieved. The finish line belongs in the job contract before the run starts.

A worked product-to-campaign run

Consider a launch campaign that needs two statics, one carousel and one short video.

1. Bind the run. Record the brand, product, audience, approved offer, channels, formats, budget and acceptance criteria. Keep the campaign brief separate from durable brand context.

2. Check context. Read the approved product and brand information. Produce a short conflict report: missing facts, contradictory direction and any claim that lacks approval. Stop only for conflicts that materially affect the work.

3. Propose concepts cheaply. Create three concept cards with the angle, copy hierarchy, visual mechanism, intended format and known risk. Do not start full production yet.

4. Approve direction. A human selects one concept and resolves the flagged claims. This is the cheapest point to reject a weak direction.

5. Prepare production. Build the static layouts, carousel sequence and video storyboard. Check product fidelity, text hierarchy, aspect ratios and continuity. Estimate paid generation work before the system fans out.

6. Generate by unit. Produce independent assets in parallel only after direction and spend are approved. Save the identifier and status of each job. A failure in one unit must not reset successful siblings.

7. Review and recover. Run factual, brand, format and channel checks. Classify failures, revise the relevant input and retry only within the agreed limit. Escalate anything that requires a new claim, budget or direction.

8. Approve destination. The owner confirms the final copy, destination and timing. This gate is separate from creative approval because a correct asset can still be sent to the wrong place.

9. Prove completion. Confirm that the approved files were delivered, record the returned receipts and list unresolved exceptions. Archive run-specific state without changing canonical brand truth.

This architecture is deliberately uneven. The system spends the most control on the expensive and irreversible transitions, not on every model decision.

Design recovery before the first failure

Failure

Weak response

Production response

The agent returns a plan but no assets

Accept the status message

Require the named deliverables and delivery evidence

Campaign direction leaks into brand memory

Keep using the updated context

Restore canonical context and isolate run-specific direction

A documented tool is unavailable

Invent an equivalent call

Inspect the live capabilities and stop or reroute explicitly

A status check times out

Submit the paid job again

Check the saved job identifier before retrying

One clip fails

Restart the campaign

Retry only the failed child unit

The same revision fails repeatedly

Continue until it works

Change the input or escalate at the retry threshold

Operators approve dozens of harmless reads

Add more approval dialogs

Aggregate approval around direction, spend and destination

An asset exists but cannot be retrieved

Mark the run complete

Require a retrievable final asset and delivery receipt

Recovery is part of the architecture, not an exception handler added later. If the system cannot answer “what completed, what failed and what can resume?”, it does not have production-grade state.

When a script or human-led process is better

The strongest alternative to an agent workflow is often a deterministic script. Choose it when inputs, transformations and outputs are stable: resize approved images, export fixed variants, rename assets or move approved files to a known destination. A script is easier to test and cheaper to operate because it does not need to interpret each step.

Choose a human-led creative process when the strategy itself is unresolved, the campaign carries sensitive reputational judgment or the team has not agreed on product truth. An agent should not manufacture clarity that the business does not have.

Use an agent workflow when the job repeats but each run contains variable context, creative choices or recoverable tool failures. Even then, keep deterministic execution wherever judgment adds no value.

Where Advibly fits

Advibly is relevant to the capability and context layers of this blueprint. Its documented product flow turns websites, app listings, stores, screenshots and brand assets into reusable brand context, then uses that context to create images, videos, carousels and campaign assets. It can be accessed through its workspace, MCP tools and installable creative skills (Advibly; Advibly Skills).

That makes Advibly a practical creative surface inside a broader AI agent workflow: the operator can preserve product context, call format-specific generation capabilities and retrieve creative outputs without treating a single model as the whole system.

The boundary matters. Advibly is an AI creative generator, not a general-purpose workflow engine or an autonomous marketing department. Its documented capabilities do not prove that every orchestration handoff, retry or publication action has been tested for your environment. The operator still owns the goal, approved product truth, spend boundary, review and final publication decision.

Start by writing the seven layers for one bounded campaign. If the job contract, state model and completion evidence are clear, connect the required creative capabilities through Advibly skills and MCP. Add autonomy only where the run contains a decision worth delegating.

Sources

Bound the creative run

Let the agent reason, keep control explicit

Define the job, context, tools, state, approvals, retries, and completion evidence before production starts.