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