An Agent Built and Published Three Workflows. Here Is the Log.

We gave an AI agent access to Floniks through our MCP server and asked it to fill a gap in our template library. Over the next hour it queried our node catalogue, designed three multi-step pipelines, ran them, hit two real bugs, diagnosed both, redesigned around them, and published the results as public templates. Nobody opened the editor. This is the log.

We're writing it up because the interesting part isn't that an agent generated an image. Plenty of tools can do that now. The interesting part is the debugging.

The task, and why it was a real one

Our template library had a hole in it. We had landing pages targeting commercial pre-production work — storyboards, TVC previsualisation, short-drama planning — and, out of roughly 400 workflow templates, zero that actually served them. People arrived from search and found nothing to click.

So the brief was concrete: find the gap, design pipelines that fill it, prove they work, ship them.

Step one: read the room

The agent's first move was not to generate anything. It called list_node_types and read back the catalogue — 33 node types across inputs, processing, AI models and outputs. Then it called list_model_aliases to see which models were enabled and what each one costs per run.

Then it did something we didn't expect: it fetched an existing, working template with get_workflow and studied its node and edge JSON before writing any of its own. Copy the shape that already works rather than guess at it.

Step two: the first thing that broke

The first pipeline used our storyboardSplit node — an LLM step that turns a script into a shot list. The agent wired it up, ran it, and the job stopped dead at step 1, six percent, and stayed there.

No error. No failure status. Just a task that would never finish.

The agent called get_workflow on its own saved graph and compared what it had sent against what had been stored. The difference was one line: the storyboardSplit node had come back with "model": [] — an empty model array on a node that requires a model. That is a bug on our side, and it is a nasty one, because nothing surfaces it. The type checks pass. The save succeeds. The run just never ends.

Rather than wait on a fix, the agent redesigned. It dropped the LLM splitter and used four explicit, editable shot prompts instead — which, as it turns out, makes a better template anyway. Users can now see and edit each shot directly instead of trusting an opaque split.

Step three: the second thing that broke, and the fix that improved the product

The redesigned pipeline ran. It also returned exactly one image instead of four.

The obvious read is a flaky node. The agent tested that read instead of accepting it: it ran the graph a second time. The second run also returned one image — but a different one. First run returned frame 2; second run returned frame 1.

That rules out a broken node and points at the executor. The agent's graph was four independent chains — four prompts, four generators, four outputs, none of them touching. Four disconnected subgraphs. The working reference template it had studied earlier had a single shared root feeding every branch. Conclusion: multi-output runs need the graph to be one connected component.

The fix is where this gets good. Instead of bolting on a dummy shared root, the agent chained the frames — each frame generated using the previous frame as a visual reference:

prompt 1 → frame 1 ─┬→ output 1
                    └→ frame 2 ─┬→ output 2
                                └→ frame 3 → …

One connected component, so the executor returns everything. And because each frame now references the one before it, the same character carries across all four shots — the exact problem this template was built to solve. A constraint in the runtime turned into the feature.

Step four: the detail that only shows up in the output

The first successful run came back at 2048×2048 — square — despite the prompt asking for 16:9 framing in plain English.

Aspect ratio is a model parameter, not a suggestion you make in prose. The agent called get_model_params, found aspect_ratio defaulting to 1:1 with 16:9 among the accepted values, set it in the node config, and re-ran. Second time: 2560×1440.

This is a small thing that matters a lot. An agent that only reads its own prompt would have shipped square storyboards and never known. This one checked the artefact.

What shipped

Three templates, each with four real generated frames as its preview:

• Script → 4-Shot Cinematic Storyboard — 16:9, for TVC previsualisation and ad-film pitching.
• Short Drama: Script → 4 Vertical Key Scenes — 9:16, with the colour grade deliberately travelling from cold blue to warm gold across the arc.
• Character Sheet: One Description → 4 Consistent Views — front, three-quarter, full body, and an in-scene shot.

All three are live in the template library, and all three were authored, executed, verified and published through the MCP server without the editor being opened once.

Where this actually pays off: assets, not prompts

The three templates above are pipelines. The bigger idea underneath them is what happens when you stop treating the subject as something you re-describe every time.

Floniks stores two kinds of persistent asset. create_character mints a reference sheet — front, side and back views — and keeps it as the character's canonical likeness. create_location mints two things: a cinematic establishing shot and a six-panel grid of the same place from different camera angles. A location also carries persistent_props — objects that must appear every time you shoot there — and a time_of_day.

That last detail is the whole point. A prop list attached to the place rather than to a prompt is what lets the same cracked mirror sit in the same corner in episode one and episode forty.

Once a subject is an asset, the economics invert. Describing a person in a prompt costs you a fresh roll of the dice every time. Referencing an asset costs almost nothing and gets more reliable as you accumulate material against it.

Some of what that unlocks:

• A house model. Mint one person, then run them through daily outfits, hair changes, seasonal lookbooks, travel backdrops. The face doesn't drift between Monday and Friday, so the feed reads as one person rather than a stock-photo carousel.
• A recurring set. A café, a showroom, an apartment — locked with persistent_props so continuity holds across every shoot, and re-lit through time_of_day for dawn, day, dusk and night versions of the same space.
• Serial drama. Characters plus locations together. Episode twelve reuses the cast and the sets from episode one without anyone re-describing either.
• A brand mascot or virtual host. One character asset, then endless campaign, holiday and announcement variants — all unmistakably the same figure.
• A talking spokesperson. Pair a character with the avatar and voice tools and the same presenter fronts every explainer, in any of the available voices, without a camera.
• Localised versions of one shoot. Same character, same set, swapped voice and burnt-in subtitles per market.
• Music and MV work. A consistent artist persona across releases, with textToMusic, audioBeatDetect and tempoMatchedCut cutting the visuals to the track in the same graph.
• A production bible. For comics, games or animation, the character sheet is the deliverable — the front/side/back grid is exactly what an art team works from.

One honest gap: there is no product or SKU asset type today. Characters and locations are first-class; a product is not. If you're doing e-commerce work, you supply the product image as a reference inside the workflow — which works, and is how our product photography template operates, but it isn't the same as a stored, addressable SKU. It's the obvious next asset type and we know it.

Put the three pieces together — a stored asset, a saved pipeline, and an agent that can call both — and routine output stops needing a person in the loop. The agent lists your characters, picks one, runs the pipeline, publishes. That loop is the reason any of this is worth building.

Why this is different from "an agent that makes images"

Most creative MCP servers expose generation endpoints. You ask for an image with a given model, you get a URL back. The agent is a remote control.

What the agent did here is different in kind. It read the available building blocks, composed a multi-step graph, ran it, inspected the output rather than trusting the run status, found two defects, formed a hypothesis about each, tested one of them with a controlled second run, and redesigned the architecture in response. Then it published the result as a reusable asset for other people.

That's not a remote control. That's the difference between calling a model and owning a pipeline — and it's only possible because the workflow graph itself is addressable through the API, not just the render.

We'll take the two bugs, incidentally. Finding them this way is a better outcome than not finding them.

Frequently Asked Questions

Do I need to write code to use the MCP server? No. You connect Floniks as an MCP server in a compatible client such as Claude Desktop, and then ask in plain language. The tool calls happen on your behalf.

Does an agent run spend my credits? Yes. Agent-initiated runs draw on the same balance as runs you start yourself, and each model's cost per run is visible through list_model_aliases before anything executes. An agent can check get_credit_balance first. Credits never expire — once they're in your account they stay there until you spend them.

What happens if a workflow fails partway through? Credits for a failed run are refunded automatically, and get_task returns the error alongside the failure status so an agent can decide whether to retry, change parameters, or redesign. In the run described above, the hung job produced no usable output and the agent moved on rather than retrying blindly.

Can an agent publish templates for other people to use? Yes — create_template publishes a workflow as a public template with preview images attached. That's how the three templates in this post shipped.

Why chain frames instead of generating them in parallel? Chaining makes each frame use the previous one as a visual reference, which is what keeps the same character across shots. Parallel generation is faster but the person drifts — different face, different clothes — which is the failure mode these templates exist to prevent.

Try it

The three pipelines are in the template library — open one, replace the shot prompts with your own story, and run it. If you'd rather drive it from an agent, the MCP server exposes the same graphs as callable tools, and the workflow editor is where you'd go to see what the agent actually built.