Lingke: What a Director Agent Still Needs After the Workflow Runs

I started experimenting with AIGC video by hand in September 2025. A striking clip was exciting. Turning the clips into a complete piece brought another kind of problem: why does this shot belong here? If the previous one changes, can the next one still be used?

The creator knows what went into the prompts. Viewers should not need to read them to understand where the protagonist has gone.

That October, I began building AI Mendao · Lingke, a lightweight director Agent intended to help video creators move from an idea to a finished piece. We stopped operating it in March 2026. The technical workflow had progressed, but the product still had not adequately answered a question by the time we stopped: why would a creator entrust it with the next piece as well?

First, make the story make sense

Our workflow started with a story input, produced a shot plan, timeline and prompts, generated clips through the Sora 2 service we were using, and assembled them with FFmpeg. That service had a 15-second limit per clip, so longer stories had to be split up.

Some choices need to be made before dividing the story into shots. Suppose someone asks for ‘a warm story about a coffee shop.’ Where does the warmth come from? Friends meeting again could work. So could a barista remembering a regular's habits. Choose the latter, and viewers need to see something of the relationship before a later gesture reads as care for someone familiar. Two people smiling over steaming coffee can make a pleasing image without telling that story yet.

A director Agent needs to help the creator work out what the audience learns first, what the character does next and what each shot tells us. Then comes writing shot prompts and calling the generation service. Expanding one prompt into several hundred words and dividing it evenly into ten shots may simply make the ambiguity longer.

The first script is usually not the last. Watching a draft, the creator may find the relationship is still unclear, or that its setup takes too long. Whether a directing product helps now depends on whether it can keep working through those changes with the creator.

Shots can stop waiting in line and still fail to connect

We used a last-frame-to-first-frame approach to preserve visual continuity: the final frame of one shot became the starting image for the next. It supplied a clear reference, but also made shots wait in line. If an earlier clip was remade and its final frame changed, later shots had to be checked again.

We then prepared the complete script and first-frame image prompts for each shot, generated reference images and produced clips in parallel. This workflow ran successfully in n8n. Settling some decisions beforehand gave shots a chance to start separately.

The characters and locations can match while the actions still fail to connect. In the hypothetical story, a shot continuing the action of picking up a cup needs more than the same-looking person. The cup's position and the state of the action must match too. Shots that communicate independently can run together; those requiring a specific outcome from the preceding shot still need that outcome first.

The same applies to revisions. Replace a decorative shot, and other clips may survive intact. Change why a character makes a decision, and the script may need another look: do the later actions still make sense? Rebuilding everything costs effort. Always changing only the current segment can leave a break in the story.

I would want to follow a revision through to the end. Once the creator changes this part, which reference images need updating, which clips can stay, what needs editing again, and when can they see the complete piece? The n8n run showed that the parallel arrangement could execute. It did not establish that the whole production workflow was ready to use. Whether revisions cost less effort, shots connect better and the finished piece is worth using still needs to be checked.

A replacement model still leaves the question of whom to serve

If another video model could be connected, why stop in March?

Sora's retirement plans were one background factor in our decision. The official developer documentation records the deprecation notice on March 24, 2026, with API removal planned for September 24 that year.^[1] The announcement, actual service shutdowns and Lingke's March closure are separate points in time.

Meanwhile, ByteDance released Seedance 2.0 on February 12, supporting text, image, audio and video inputs, with stronger reference controls and multi-shot generation.^[2] As video models take on more of what applications previously had to arrange, connecting a model and its production steps gives users less reason to keep returning. A replacement model can restore a capability. We still have to decide whom Lingke should help and with what.

On March 18, LibTV officially launched as LiblibAI's professional video creation platform.^[3] It was new; the LiblibAI ecosystem behind it had a longer history. It was already operating in 2023, and an investor disclosed the scale of its creators, models, workflows and generated content in 2025.^[4] That existing activity gives it more opportunities to stay in contact with creators and see how they use the product. Public sources do not establish the size or quality of its professional prompt-to-script pairs, however. Ecosystem scale cannot simply stand in for script capability.

We could keep building the technical approach, but changing models would not tell us why creators revised a draft or chose a result. Looking back, my judgment is that the team more urgently needed professional creative data that could show us how those choices were made.

Find out who would return to make the next piece

Collecting that data requires getting more specific than ‘serving video creators.’ Someone making a product explainer needs accurate information and clear product features. Someone making a dramatic short may care more about motivation, emotion and pacing. Generating both does not mean both groups find the product useful for the same reason.

Product–market fit, or PMF, needs to be examined within those jobs. Start with a recurring task and find out where creators spend effort, whether Lingke can save them that work and why they would return for the next piece. If they have to rewrite the script before every use, the first clip can still be a surprise while the product may offer little sustained help.

Lingke did not establish enough evidence of that kind of sustained demand. If I tried again, I would follow one kind of creator through the complete process before listing every generatable subject as a product capability. This would test demand while clarifying which experience is worth collecting. Without a specific job, people can struggle even to agree on why a script is good.

How a reason for one revision could help the next script

Return to the fictional coffee-shop story. Suppose a creator moves a piece of relationship setup ahead of the barista delivering a coffee, because viewers previously did not know the two people were familiar and missed the gesture's meaning.

If the system saves only ‘move shot three to position one,’ repeating that change next time could be a mistake. It also needs the reason: viewers had to understand the relationship to make sense of the gesture, and the original script introduced it too late. After the change, that information came before the action.

I want to keep the original request, purpose and audience, before-and-after scripts, shot plans, reasons for changes and accepted version together, so each revision can be traced to its material. On another request that needs to convey familiarity, the system could retrieve this kind of example and examine where the new script places its relationship cues. If the setup is missing again, it could propose an adjustment for the creator to compare and assess.

That lets us refer to why the earlier change was made without copying the coffee shop or its shot order. The lesson is not one to apply every time: if the new piece deliberately saves the relationship as a final revelation, moving that information earlier could spoil the intended effect.

These records still need someone who understands creative work to organize and assess them. A shot can be deleted because it repeats information or because a product detail is wrong. Moving a scene earlier can supply a condition for understanding, or merely reflect a personal preference about pacing. The action alone does not distinguish those reasons. A creator's acceptance also does not establish that the version will work for another kind of piece.

We could start by organizing material, within its authorized uses, into examples that can be retrieved and compared, then test whether they help. There is no need to jump straight to model training. Lingke did not complete such a data system and has no corresponding training results. What I am describing is a capability I want to build.

How would we know that the experience helps?

More examples give us more material to compare. But understanding why a creator made a change takes continued contact and a sense of the circumstances. Someone who understands the work then needs to organize and assess it before deciding whether another task can draw on it. A large image collection does not naturally become a professional script dataset, and many users do not mean that their reasons for revisions have been preserved.

If I started again, I would first serve creators with a recurring need, obtain clear revision records and try them on similar new tasks. Does the script still make the earlier kind of mistake? Do creators still have to perform the same repairs? If the files keep accumulating while new work does not improve, we may still be building an archive.

There are always more workflow features to add. Before returning to this field, though, I need a way to keep collecting, organizing and testing that experience. I want to know whether the next piece leaves viewers less confused and creators making fewer of the same repairs.