Lottie Plugin for Continuous Agent-Driven Animation Editing

The author released version 0.1.0 of a Lottie plugin to the Qoder Marketplace ( https://qoder.com/marketplace?type=plugin), allowing agents in Qoder to create, edit, package, validate, and preview Lottie animations. While it may appear as just another AI animation generator, the core problem addressed is not generation but continuous editing: after an animation is produced, users quickly request iterative changes — slower motion, earlier track appearance, smoother loop seams — requiring the agent to re-enter the artifact, locate the exact object, and modify it without breaking other parts.

When an animation has already been generated, how does an agent re-enter it, find the object that needs modification, and continue working without destroying other parts?

Lottie JSON and .lottie are well-suited for playback and distribution; dotLottie bundles multiple animations, images, themes, and state machines; Lottie Creator MCP proves agents can read files, edit layers, and generate variants. What remains unsolved is how an agent maintains references to the same object, track, and time span across continuous modification rounds. When a user says "make the left eye blink slower during the idle phase," the agent needs a semantic address resolvable in the engineering state, plus a version precondition confirming the artifact hasn't drifted since last inspection.

A programmable animation is not merely "animation generated by code." It is an artifact where objects, tracks, and time states possess stable identities, allowing agents to modify continuously based on explicit versions and verify the scope of changes.

Sustainable Editing: Preserving Engineering State Beyond the Artifact

If an animation is generated once, .lottie can be the endpoint. But once humans, other agents, or external tools continue modifying it, the question shifts from "can the file be opened?" to "can the system re-identify the same object, confirm the version base, and prove untouched parts remain unchanged?" The solution is not to save all conversations but to keep recoverable engineering state outside the artifact: MotionProgram expresses intended changes, MotionProject stores stable identities and revisions, MotionRuntime computes diffs, dry-runs, validates, and commits, while .lottie is merely the delivery result of a commit. Even if the file is externally modified, the system should first reconcile object identities rather than guess by similarity.

Three interlocking practices achieve this: an Agentic DSL to retain replayable creative intent, CLI over MCP to stabilize cross-host execution semantics, and Canvas to convert human visual feedback into addressable, verifiable engineering state.

Agentic DSL: Expressing the Full Creative Program with a JS API

Designing MotionProgram, the team did not invent a new animation scripting language. Instead, they adopted a constrained JavaScript API as the Agentic DSL. The key judgment: DSLs don't require new syntax. Agents already proficient in JavaScript have variables, functions, loops, modules, and composition built in; what needs redesign is what the DSL can express, which objects must have stable identities, and how programs are executed and verified. JavaScript is merely the expression layer; MotionProgram 's data structures constrain domain semantics, while MotionRuntime controls execution permissions and state mutations.

The critical point is that the agent submits a complete program, not scattered createLayer, updateTrack, and exportFile tool calls. A whole program can be inspected, compared, dry-run, and replayed; stable keys, random seeds, and target configurations become part of the program. On the next iteration, the agent regenerates the full MotionProgram, the runtime computes the diff, and proves that only the specified objects, tracks, and time ranges changed.

Vercel's internal text-to-SQL agent d0 removed ~80% of specialized tools, letting agents explore existing semantic layers via filesystem and CLI; later experiments showed Bash isn't suitable for all tasks. Together, these practices highlight that agents need a programmable environment matching domain semantics — composable, inspectable, verifiable — not merely fewer tools or Bash everywhere. For Lottie, that environment is a fully reasonable animation program.

CLI over MCP: Stabilize the Runtime First, Then Extend Protocol Entry

Version 0.1.0 did not wrap every animation operation as an MCP tool. Instead, the JS API and qoder-lottie CLI share the same MotionRuntime. Object identity, version conflicts, change plans, validation, and error semantics are defined in the runtime; the CLI simply exposes these capabilities stably to agents, automation scripts, and CI environments. This isn't to diminish MCP but to enforce architectural order: first make domain capabilities independently runnable, debuggable, composable, and reproducible as commands; then add MCP entry points for cross-host discovery, remote connections, permission control, and structured tool descriptions.

In this layering, MCP handles connectivity, CLI handles execution, and true domain semantics always remain in the runtime. Thus, whether invoked by Qoder, Codex, Claude Code, CI systems, or other hosts, they all confront the same object identities, transaction boundaries, and error semantics. A controlled study across seven agent scaffolds, five models, and a fixed software task found MCP/CLI cost ratios ranging from 0.43x to 29x across 13 strictly paired experiments; the dominant variance came from how scaffolds organize context, tools, and execution — not the interface form. This doesn't prove CLI universally beats MCP, but warns against reducing architecture to protocol choice before runtime semantics are stable.

Canvas Interaction: Bringing Human Visual Selections Back to Semantic Addresses

If the runtime solves how agents modify animations, Canvas solves how humans re-enter them. The current version completes a one-way flow: MotionProgram → .lottie → static validation → load and play in Qoder Canvas. The validator further checks specified frames, scene states, and loop seams because static structural correctness doesn't guarantee natural motion; a single screenshot looking fine doesn't mean the entire timeline is problem-free.

Canvas's real next value isn't more playback buttons but converting human visual selections into semantic addresses the agent understands. A user selects the left eye on screen and highlights the idle phase on the timeline; Canvas translates that into object, track, time range, and current project revision. The agent then generates a new MotionProgram, completing dry-run, diff check, and re-preview. At this stage, Canvas ceases to be a mere result previewer and becomes the shared interface where human visual judgment maps to stable objects and agent-structured modifications reappear as observable animation — both cycling around the same engineering state.

Conclusion: When Animation Becomes a Continuously Evolvable Work Object

When an animation possesses stable identity, engineering state, version constraints, and verification evidence — and both humans and agents can re-enter the same workspace — it stops being an agent's one-off output and becomes a continuously evolvable work object within the agentic loop.