In 20 days, BeatAPI has crossed 600 signups, $600+ in revenue, and a peak day of about 800 unique visitors. Today I want to talk less about those numbers and more about what we're actually doing, and why.

I came from an investment background. AI pulled me in enough that I left it to write code myself. Since then, the way I look at a product has changed twice.

First I looked at it the way an investor does—how big is the ceiling, how much room is there to grow. Then I looked at it the way an engineer does—frontend, backend, database, the actual mechanics of getting something built. In this latest project, the lens changed again. I think almost entirely from the user's side now. What does this person actually need? What can we actually give them?

Where BeatAPI actually came from

I'm a heavy agent user. Over 99% of my work runs through Codex. That's where BeatAPI's idea came from, not from a market report.

Codex couldn't make a video in my workflow without a separate generation API. I had to wire one in just for that.

It couldn't read what was happening on TikTok or Instagram without additional data access either. Another API, another account.

Over time I'd installed dozens of MCPs and Skills. I was managing somewhere between 15 and 20 different API keys just to keep everything running.

Then I tried the same workflows on Claude, on OpenCode, and on other agent runtimes. Most of it didn't carry over cleanly—nearly everything I'd configured had to be rebuilt. That was the moment I started thinking: why not build one all-in-one agent toolkit layer, and put everything I actually need into it? That's the shape BeatAPI started from.

What 600 signups made me realize

Only after I actually started building did I notice something about myself: I rarely put myself in someone else's shoes before this.

When I was investing, I looked at the macro market. When I was building products, I looked at system bugs. In this project, I'm carrying growth, strategy, and product at the same time.

It's the first time I've genuinely believed a good product is one you use yourself every day—built with real empathy, from the user's side, solving a problem they actually have.

The question I wrote on my whiteboard

Our early marketing was built around features, specs, and advantages. The response was flat. For a while, I didn't think hard about why.

Then one day I finally sat with it honestly and put myself in the user's seat: if I saw this product description as a stranger, why would I use you?

I wrote that question on the whiteboard next to my desk. It's still there. I still look at it every morning before I open anything else—why does someone need BeatAPI, and what problem are we actually solving for them?

What that question led to

That question is what pushed me toward something valuable but genuinely slow: real case work.

Find the specific problem a person actually hits while using an agent. Figure out what we can offer. Help them through it in a way that becomes a real case—not a feature announcement.

I think this is the most effective growth model available to us right now, even though it doesn't scale the way a content calendar does.

Before this project, the podcasts I listened to were about agent trends, AI safety, infrastructure—the macro view, wearing a different hat.

Now I pay more attention to founders doing far less scalable things. One is running free case tests with a hundred users directly on Reddit. Another is emailing two hundred early users one at a time just to ask what was actually breaking for them, and pulling them into a demo.

An open invitation

If you're using agents and see real potential there, or you've hit any friction while using one, I'd like to hear from you directly.

Email me at karmen@beatapi.io, or learn more at beatapi.io.

BeatAPI's ambition is to become a general capability layer for any agent, built to actually solve the problems people run into while using one.

Originally published on the BeatAPI Blog.

BeatDesign exposes every link in that chain to MCP-capable Agents while keeping the same local Project visible to the human.

TL;DR

• Tail-frame extraction is local and deterministic; remote video generation is separate and potentially paid.
• A stable command ID prevents retries from creating duplicate frame Assets or continuation nodes.
• The extracted frame and continuation card should be reviewed before generation.
• A successful generation creates an Asset but does not silently place itself on the Canvas or timeline.
• Timeline edits and MP4 render use the authoritative saved timeline revision.
• BeatDesign's verified local QA completed: 10.01-second MP4 → tail frame → continuation node → timeline → 3–7 second trim → 4-second clip → H.264/AAC render → render Asset.

Why this workflow needs explicit states

A naive “continue this video” button hides several decisions:

• Which exact source file and source time were used?
• Was the extracted image saved, or is it a temporary blob?
• Does the next model interpret the image as a first frame or a generic reference?
• Did a retry create a second paid request?
• Which generated version entered the timeline?
• Is the export based on the current timeline or a stale copy?

Those questions become more important when an Agent is operating the project. The system needs stable objects and review points, not just a successful HTTP response.

Prerequisites

For the visual workspace:

pnpm install
pnpm db:push
pnpm dev

For a generic stdio MCP host:

pnpm --silent mcp

The MCP/Node tail-frame operation needs ffmpeg available on PATH, or an absolute path in BEATDESIGN_FFMPEG. MCP timeline rendering also needs ffprobe, or BEATDESIGN_FFPROBE.

Browser-native preview and export remain separate from these MCP/Node requirements.

The tool sequence

The Agent-facing sequence is:

bdesign_project_list
→ bdesign_project_target
→ bdesign_project_open
→ bdesign_canvas_continue_from_tail
→ bdesign_canvas_view        # human review gate
→ bdesign_generation_submit  # separate authorized action
→ bdesign_generation_status
→ bdesign_canvas_apply       # attach successful output
→ bdesign_canvas_view
→ bdesign_editor_edit
→ bdesign_editor_view
→ bdesign_editor_get
→ bdesign_editor_render

The exact schemas are discoverable from the MCP server. The important part is the ordering and the authorization boundary.

Step 1: target one project

After selecting the intended project, call bdesign_project_target once. Later project-scoped tools can omit the project ID for the lifetime of that MCP session.

This reduces accidental cross-project writes, but it does not remove the need to inspect the selected project name and current Canvas before editing.

Open the project near the start of the task so the human and the Agent are looking at the same state.

Step 2: continue from the tail with a stable command ID

Call bdesign_canvas_continue_from_tail with the selected video card and one stable command ID.

Conceptually, the operation does three local things:

1. decodes the local source video;
2. extracts the tail frame into a project-owned image Asset;
3. creates a new continuation Generation Node connected to that derived Asset.

It also returns the next generation request, but it does not submit it automatically.

Reuse the same command ID if the delivery result is uncertain. Do not invent a new retry ID. The stable identifier lets BeatDesign reuse the same derived frame and continuation node instead of duplicating them.

If a short revision race occurs, the command can reload the newest authoritative Canvas document and replay the stable-ID operation a bounded number of times. If it still fails, the tool returns structured retry information; it does not busy-loop or leave an orphan frame from that failed attempt.

Step 3: review before paid generation

The continuation response includes a review handoff. Open the returned Canvas view and inspect:

• the source video card;
• the extracted tail-frame Asset;
• the connection into the new generation card;
• the model, aspect ratio, duration, and quality settings;
• the explicit prompt instruction that treats the image as the first frame.

This is the most important boundary in the workflow. Frame extraction and node placement are local deterministic actions. The next generation call may use external credits, so it remains a separate authorized step.

A useful human request is:

Continue this shot from its final frame. Keep the subject identity,
camera direction, lighting, and motion vector consistent. Create the
continuation node and leave it open for review. Do not submit generation yet.

Step 4: submit and follow the generation state

Before submitting, the Agent should inspect model capabilities with bdesign_generation_models or bdesign_generation_model_get.

bdesign_generation_submit requires a visible generation card as sourceCardId. It rejects a missing, busy, or mismatched node. Before contacting the provider, BeatDesign writes a pending output card into the Canvas, so a paid request cannot be created without a visible place for its state.

Follow the generation until it succeeds, fails, or needs user action. A successful task creates a project Asset. It does not automatically overwrite the continuation node or add itself to a timeline.

That explicit placement rule prevents a background task from silently changing the creative edit.

Step 5: attach the selected output

After success:

1. read the current continuation card and latest Canvas revision;
2. preserve its generation settings;
3. update the card with the successful output through bdesign_canvas_apply;
4. open bdesign_canvas_view focused on that same card.

Now the Canvas shows the source clip, derived tail frame, continuation node, and output lineage in one graph.

If you generate alternatives, each output can remain a separate Asset. Selecting one for editing should not delete the others.

Step 6: move from Canvas to timeline

Use incremental Editor operations rather than replacing the complete timeline document.

In the verified QA run, the source was a 10.01-second local MP4. After the tail-frame continuation setup, a timeline node was created and opened in the Editor. One source clip was trimmed from 3.00 to 7.00 seconds, producing a 4.00-second timeline clip.

The useful state transition is:

Canvas output Asset
→ explicit timeline placement
→ non-destructive trim
→ saved timeline revision

The Editor can also manage image overlays, audio, and SRT caption tracks. Those remain separate timeline objects rather than being burned into the source video during editing.

Step 7: render the authoritative timeline

When export is authorized, first call bdesign_editor_get and use the returned current revision with bdesign_editor_render.

The render can include visible video and image clips, image overlays, caption burn-in, and mixed audio. The output becomes a project-owned MP4 Asset.

If the timeline changes while rendering is in progress, the revision-checked commit rejects the stale render and removes the temporary Asset from that attempt. This prevents an apparently successful export from being recorded as the current result of a newer edit.

Failure modes and recovery

What you get

More steps than a single “continue” call, but every one is inspectable:

• local and paid actions are separated;
• retries are idempotent;
• derived frames are durable Assets;
• generation state is visible before provider submission;
• successful outputs do not silently mutate the edit;
• the rendered MP4 is tied to a specific timeline revision.

That is the difference between automating a button and giving an Agent a reliable control plane.

Current boundary

BeatDesign currently exposes 29 local MCP tools across Skill, Project, Asset, Canvas, Generation, and Editor groups. It is still focused on local short-form workflows.

It does not yet provide a complete Agent NLE: live UI event push, a permanent audit log, pixel-rasterized MCP preview frames, advanced transitions, speed controls, waveforms, hosted collaboration, and desktop packaging remain outside the current release boundary.

The existing workflow is enough to build and verify a practical Canvas-to-Editor loop.

BeatDesign is open source:

https://github.com/BeatAPI/BeatDesign

TL;DR

• I directed the concept and reviewed the important visual decisions.
• Codex translated that direction into generation and editing operations.
• GPT Image 2 created the character reference.
• Nano Banana 2 created the room reference.
• MiniMax H3 generated the 15-second, 9:16 video with English dialogue and native sound.
• BeatDesign kept the outputs as project Assets, then carried the selected video into a timeline with five caption cues and a closing brand overlay.
• The final timeline was rendered as an H.264/AAC MP4 and written back to the project as another reusable Asset.

Not a chat box that returns a file — a project where an Agent and a human share the same creative state.

Keep the logic, change the story

The starting material was original frames and prompt screenshots from a reference ad. I wanted the production logic underneath it, not the surface details:

• a single continuous take;
• a clear camera position;
• physical actions timed to spoken lines;
• an environment that supports the punchline;
• a final visual payoff rather than an abstract product claim.

Codex analyzed those elements and rewrote the story around a problem I was actually experiencing: producing one AI video across disconnected tools that do not share references, history, or editing state.

That distinction matters. A reference is useful when it becomes a structural constraint, not when it becomes a shortcut for copying someone else's finished creative.

The control loop

The production loop looked like this:

Human direction and review
          ↓
Codex plans the next operation
          ↓
BeatDesign Canvas + MCP
          ↓
Generation model
          ↓
Project Asset
          ↓
Timeline, captions, overlay, export
          ↓
Human review in the same Project

The Canvas was not decorative. It was the visible production graph: inputs on the left, generation nodes in the middle, outputs and the timeline on the right. The same media also remained available in Assets and the Editor.

Step 1: generate references by role

Instead of asking one model to invent the person, room, dialogue, and movement at once, we split the reference work into two jobs.

The character reference was generated with GPT Image 2. Its job was identity: face, clothing, and the general creator look.

The environment reference was generated with Nano Banana 2. Its job was location: a red-brick creative room that could support the final scene.

This role separation made the next prompt easier to reason about. One input controlled who appears; the other controlled where the scene resolves. Neither image needed to solve the full video.

Step 2: turn the reference into a video contract

The video node used both references with MiniMax H3. The request specified:

• 15 seconds;
• vertical 9:16 framing;
• 2K output setting;
• English dialogue;
• native sound;
• one-take structure;
• camera, action, and timing constraints taken from the reference analysis.

I think of this as a production contract rather than a prompt. A useful video request needs to define what can change, what must remain stable, and what event must happen at each beat.

“Make a clever ad about too many AI tools” is an idea. It is not yet an executable contract.

Step 3: generation output stays in the project

When the video completed, it did not disappear into a download folder. It became an Asset linked to the generation record and Canvas node — three options without rebuilding context:

1. revise the generation prompt;
2. branch a new version from the same references;
3. move the selected result into the Editor.

Small architectural choice, large workflow effect. When prompts, references, and outputs are durable project objects, an Agent can continue the work instead of asking the human to re-upload everything.

Step 4: build the timeline

The selected H3 result was added to a 15-second timeline. Codex then created five English caption cues and adjusted their timing, size, and vertical position to match the dialogue.

A BeatDesign logo image was placed over the closing seconds and given a fade-in. The overlay remained a separate timeline object, so its timing and transform could be changed without modifying the source video.

The final render included:

The rendered MP4 was written back into Assets. Export was therefore not the end of the project; it became another reusable version inside it.

What required human judgment

The Agent could execute the workflow, but it did not remove the need for direction.

I still had to decide:

• which part of the reference was worth preserving;
• which story matched BeatDesign rather than the original ad;
• whether the character and room references were usable;
• whether the dialogue landed inside 15 seconds;
• whether the captions were readable;
• whether the closing brand moment felt intentional.

The useful split was not “human or AI.” It was human direction and review, with Agent execution in a shared workspace.

One evidence note matters here: the saved timeline history contains both origin=mcp and origin=ui events. That field records the write channel, not the identity of the person or Agent behind it. This case therefore demonstrates a shared BeatDesign production workflow; it should not be used as proof that every saved coordinate in the historical project was written exclusively through MCP.

What I would change on the next run

First, I would define the caption plan before generation. Native dialogue timing can vary, so writing the expected cue windows early would make subtitle alignment faster.

Second, I would create two environment references rather than one: a wide composition reference and a lighting/material reference. That would reduce the amount of spatial work the video model has to infer.

Third, I would save the acceptance criteria beside the generation node: one-take continuity, readable dialogue, no identity jump, and enough quiet space for the final overlay. A visible review checklist is easier for both a human and an Agent to follow than a decision kept in chat history.

Reusable checklist

Before running a similar Agent-controlled ad workflow, check:

• The reference has been decomposed into camera, action, timing, sound, and payoff.
• Each image reference has one explicit role.
• The video prompt defines both allowed changes and invariants.
• A human review gate exists before paid generation.
• Successful outputs become project Assets before editing.
• Captions and overlays remain separate timeline objects.
• The final export is saved back into the project.
• Publication is a separate decision from generation and export.

The broader point

Most AI video demos stop at generation. Real work continues through comparison, selection, timing, captions, branding, and export.

The durable part was not one 15-second clip. It was a production structure that an Agent could read, operate, and hand back for review.

BeatDesign is an independent, open-source, local-first workspace. Connect your own MCP-capable Agent and inspect the project:

https://github.com/BeatAPI/BeatDesign

If you have used Higgsfield, you already know the product: an infinite canvas for image and video, branches and references on one board, then a short cut out of those outputs. That canvas is the product. I wanted the Higgsfield Canvas on my disk, under Apache-2.0, without uploading first — and I wanted a general-purpose agent to drive it, not a chatbot trapped inside Higgsfield.

So I built BeatDesign. Same Higgsfield Canvas job. Local project. Open source. Any MCP agent. Upload only when you confirm generation.

The Higgsfield Canvas, without the Higgsfield lock

Higgsfield’s canvas is a closed webpage. Drag in a client product shot or an unreleased campaign, and Higgsfield has the file before you have a generation. The branches live on their server. An idle month still bills. The Higgsfield Canvas is rented.

BeatDesign keeps the Higgsfield Canvas locally. Studio, Canvas, Assets, generation history, and a short-form Editor live in one SQLite-backed Project — a folder you can copy. Import, branch, trim, preview, and export MP4 with no account and no API key. A source file is sent to a provider only after you confirm the run. You pay per generation, not for a month of Higgsfield you did not open.

Local-first does not mean the model runs on your GPU. It means the Higgsfield Canvas stays yours.

A general-purpose agent can operate that canvas

Higgsfield keeps the agent inside Higgsfield. BeatDesign does not embed a proprietary chatbot. It exposes 26 local MCP tools. Codex, Claude Code, Cursor, or another MCP host inspects and updates the same local Higgsfield Canvas that is open in the browser.

A real loop: you import a local product video. The agent pulls the tail frame, writes the next-shot prompt, and drops the clip on the timeline. You watch the canvas update in the same window.

A sidebar agent inside Higgsfield can talk. It cannot operate a canvas you own.

Website: https://design.beatapi.io/
GitHub: https://github.com/BeatAPI/BeatDesign