A few days ago, George (@Embody_Net) reached out to me about the Livepeer Agent Hackathon, and I decided to actually build an n8n workflow around Livepeer Agent rather than just read the docs.
The idea sounded simple:
Telegram
→ receive a product image + brief
→ n8n
→ Livepeer Agent
→ image-to-video
→ return the finished video
What started as a straightforward automation turned into a pretty interesting exercise in debugging AI infrastructure.
The first issue I hit was media handoff.
I initially passed the Telegram-hosted image URL directly into the image-to-video request.
The request reached the provider, but the provider rejected the asset with:
file_download_error
“Failed to download the file. Please check if the URL is accessible…”
So I changed the architecture.
Instead of asking the model provider to fetch the Telegram file:
Telegram
→ download image into n8n
→ upload image to Livepeer
→ receive a Livepeer-hosted asset URL
→ pass that URL into the video generation request
That worked.
Then I hit MCP surface routing.
I called run_capability on the creative MCP surface.
The server rejected it before execution and explicitly told me that run_capability was available on the raw surface:
/api/mcp/raw
So now different parts of the workflow had to understand different MCP surfaces rather than treating the Agent as one uniform endpoint.
Then authentication became another interesting layer.
I created credentials and tested authenticated requests, but the deployment I was hitting returned:
“This deployment is keyless — Livepeer Agent does not accept an API key here…”
So I removed the Authorization header and went back to the keyless connection for that deployment.
At that point I realized I was no longer debugging an “AI video generation” problem.
I was debugging an integration contract.
The next question was:
What exactly does create_media return?
Because video generation is asynchronous, the workflow isn't simply:
create_media
→ video
It becomes something more like:
create_media
→ job
→ wait
→ get_create_media(job_id)
→ inspect status
→ wait
→ retrieve final asset
And this is where things got particularly interesting.
My workflow reached the polling stage, but the data coming back through MCP wasn't giving my parser the job identifier in the form I expected.
I could have kept guessing.
Instead, I changed the workflow.
The latest version is intentionally a diagnostic pipeline whose job is to capture the raw create_media response before I write another line of polling logic around assumptions.
Then I hit another boundary.
I tried exact model dispatch with:
run_capability(ltx-25-i2v-fast)
and received:
“Demo budget store unavailable — try again shortly.”
The response also explicitly said the request was refused before dispatch and that nothing was billed.
So the provider wasn't even reached in that attempt.
This is the part of AI infrastructure engineering that I find fascinating.
The hard part isn't always the model.
The hard part is everything around the model.
For an automation system like n8n, the actual integration contract is:
authentication
+
MCP surface discovery
+
tool schemas
+
binary media handoff
+
async job lifecycle
+
job identifiers
+
polling semantics
+
asset URLs
+
error semantics
Every one of those has to be predictable if the workflow is eventually going to run unattended.
And that changes the question I'm asking.
I'm no longer asking:
“Can Livepeer generate a video?”
The more interesting question is:
“Can an external automation system reliably treat Livepeer Agent as a deterministic media execution layer?”
That's what I'm testing.
I'm deliberately not hiding the failures behind a polished demo.
I'm logging the actual runtime errors.
I'm changing one integration boundary at a time.
I'm separating provider failures from MCP failures.
I'm separating MCP failures from n8n expression/state problems.
And I'm refusing to assume what an API returned until I inspect the actual response.
That's how I prefer to debug systems where multiple services are involved:
Observe first.
Normalize second.
Automate third.
There are also signs that this area is still actively evolving. Livepeer's own Agent documentation describes multiple MCP surfaces, asynchronous media jobs, model selection behavior, and the need to inspect returned capability/job information rather than assuming a model or result. The documentation also explicitly describes run_capability as the exact-dispatch path.
So my takeaway so far isn't “Livepeer doesn't work.”
It's more nuanced:
The underlying media-generation capability is interesting.
But when you integrate an AI media agent into an external orchestration system, the documentation needs to make the entire runtime contract easy to follow:
auth
→ endpoint/surface
→ tool
→ schema
→ async lifecycle
→ output contract
→ error handling
→ billing behavior
That's the part I'm validating right now.
George, thanks for reaching out and pushing me to actually build this instead of just reading about it.
I'm still debugging the workflow, and the next checkpoint is simple:
Capture the real create_media response.
Identify the exact job lifecycle.
Wire the polling layer against the actual response.
Then finish the end-to-end Telegram → Livepeer → video automation.
I’ll share the final architecture once I have it running.
#Livepeer #LivepeerAgent #AI #AIVideo #MCP #n8n #Automation #AIEngineering #GenerativeAI #BuildInPublic #DevTools #AIAgents
advice to hackers building, always take what you built in your last hackathon and use it in the next. Think of a way that your last thing can integrate with the new theme of the hackathon. Do that few times and you get progressivelly exremely competent at delivering under a single repo instead of building pieces of software that don't compound.
Quick 1-min Demo for @workflow_xAI - A Thread🧵
the problem, Workflow [powered by @Livepeer] solves for me is removing the tedious effort of jumping through different tabs, for different tasks.
sometimes, i have to resize/extend a reference image, sometimes i have to re-imagine or recreate a certain shot/frame, sometimes it's getting an optimized prompt for a particular model, but by bringing all of that into one place.
i have elliminated a chunk of time-wasting in my process, which optimizes my workflow, hence the name 'Workflow'. and i believe it can do the same for creators like me.
here is a quick one minute walkthrough, sped up, but i will post the full versions in the threads below, so you can see it in real time.
@greater_glory20 Hey lune, no worries at all. Submissions are extended till 24 of September. If you need a bit more time than that, let us know and we will be happy to accommodate!
Happy building! ✨ ⚒️
Getting your hackathon demo ready? 🎬
Add the video link to your submission. If you can’t attend or present live at the final, we can show that recording instead. Just check that the link is accessible!
https://t.co/JGVhWGgEjF
favorite part is, the speed of the frame extractor, did it in less than 5 seconds,
Take any video from the internet, and break it down frame by frame, this way you can breakdown and be inspired by videos from your favorite creators.
this is my Workflow.
process vs result
testing @workflow_xAI , so after extracting frame from the gamdom video, took one frame to storyboard, and generated a midjourney prompt using the style library , and here is the final result.
you will have access to styles, and you can also add yours. when we are live. trust the process.
@DeveloperAlly We vouch for Allie, she is an innovation beast, has great communication skills and can feat into any creative engineering role as long as you don't try to contain her in boxes. Most important, she is an amazing person you would love to work with!
@CryptoI15027687 Many things happen in Livepeer that the public is not yet aware of and/or haven't been anoucned yet, the Livepeer agent is just the tip of the iceberg!
How’s your Livepeer Agent Hackathon project coming along? 🛠️
If you’re stuck or would like feedback, share your project in the Discord thread and tell us what would help. Work in progress is welcome!
https://t.co/WUo6uBwvI5
Our website has a fresh look ✨
A little more room for what we’re building, the people behind it, and ways to get involved.
Take a look around and let us know what you think: https://t.co/Ma3f5jQNAd
Dario has written that we need to “pace the frontier,” and Sam has agreed. People may be surprised by my response: go ahead.
You guys are the frontier. By any reasonable metric — market share, revenue growth, model capability — the two of you have a duopoly on frontier intelligence. You’ve also claimed the lead is widening because of recursive self-improvement.
I don’t see what you see in the lab. If the unreleased models are scary enough that you think you should slow down, I support your decision to be responsible.
But stop pretending you need anyone else’s permission. Stop pretending antitrust law has to be suspended so you can form a cartel. Stop pretending you need a regulatory approval process that supersedes product liability. Stop pretending METR is independent when it is intertwined with Anthropic’s investors and staff. Stop pretending you need those same evaluators to police competitors who aren’t even at the frontier.
Most of all, stop pretending the motivation to slow down is purely altruistic. You face massive product-liability exposure if your products enable a truly damaging cyberattack. The market already punishes models that behave in unpredictable or unauthorized ways. After the Hugging Face episode, it is simply good business for OpenAI and Anthropic to trade some raw power for reliability and predictability. Call it alignment if you want. It is also just giving customers what they want.
Pacing the frontier would also create breathing room for a more intelligent conversation about regulation than Bernie Sanders’ “shut it all down.” China is very unlikely to join a global agreement, as you know, and that has to be taken into account as well.
So go ahead and pace the frontier. You are the ones setting it. The easiest way not to build superintelligence is for you to agree not to build it. Demanding your preferred regulatory framework as the price of that will look like blackmail of the public and the political system. So just do it.
If you do, you’ll buy goodwill for the next conversation. If you don’t, we’ll know this was just another bid for regulatory capture — or an election-season psyop.