Give one creative brief to a media team. Make sure every role improves the next version. I built 𝐋𝐈𝐕𝐄𝐑𝐋𝐎𝐎𝐏 for the @Embody_Net Livepeer Agent Hackathon, submitting to the Livepeer Agent + OriginTrail DKG track. LiverLoop is an autonomous media production loop: Generate → Evaluate → Improve → Remember. One Director turns a creative brief into a production plan by discovering the capabilities currently available through Livepeer Agent. The Orchestrator executes the plan. The Critic evaluates the finished artifact against the brief. If something fails, the Director chooses a targeted retry instead of regenerating everything blindly. The loop can coordinate video generation, image generation, audio, FFmpeg transformations, trimming, muxing and subtitle overlays. Every capability call uses authenticated server-side access, with provider fallbacks and key rotation for reliability. The browser never receives the credentials. Livepeer returns real media artifacts, URLs and estimated costs. LiverLoop stores them, probes the files with mediainfo, checks their actual format, duration, dimensions and streams, then makes the final artifacts playable and downloadable from the dashboard. Previous versions stay preserved instead of being overwritten. The system also checks generated footage for unwanted baked-in text before allowing a version to pass. When a run completes, LiverLoop packages the brief, plan, artifacts, evaluations, retry decisions and lessons into a knowledge asset. OriginTrail DKG stores that memory so future runs can retrieve previous lessons and improve their next plan. How to use it: 1. Open the app and start a run 2. Describe your brief: format, duration, audience, style and CTA 3. Watch the loop plan, generate, evaluate and improve in real time 4. Download the final artifact, or browse earlier versions 5. Open Provenance to audit every event, cost and decision > One Director. > One Critic. > One orchestration loop. > A network of media capabilities. > Downloadable artifacts. > Explainable retries. The key word is Generate. Evaluate. Improve. Remember. Live app: liverloop.world GitHub: github.com/Saber1Y/LiverLoop full demo: piped.video/oBlLtjnV4uw Built with Livepeer Agent, OriginTrail DKG, Next.js, FFmpeg and mediainfo. #Livepeer #OriginTrail #AI #GenerativeAI

Project showcase + winners reveal: Sep 29, 20:00 Athens / 17:00 UTC, just before the Watercooler 🎉 discord.com/events/423160867… Join the server: discord.gg/6CZEhWrt4 Finalists emailed Sep 27. Can’t demo live? We can show your submitted video.

I’ve been thinking about how strange it is that we spend months building software, then when it’s time to explain what we built, we basically start from zero. The story is already there. Buried in the repo. So I built EchoPitch. You give it a GitHub repository. It investigates the code, figures out what the product actually does, and verifies the claims it wants to make against implementation evidence. Then it plans the story, produces the media through Livepeer, reviews its own work, and assembles the final launch film. The part I cared about most was trust. I didn’t want an agent that reads a README and turns marketing copy into prettier marketing copy. If EchoPitch can’t find enough evidence for a claim, ClaimLock doesn’t let that claim into the film. And when the film is done, the evidence doesn’t disappear. You can still trace what was said, why it was said, what was generated, what it cost, and what survived review. Repository → evidence → story → film. Your software already tells a story. EchoPitch directs it. echopitch-studio-ten.vercel.… Built for the @Livepeer Agent Hackathon. 🎬 @Embody_Net

Myself and @floozi_official built a Video generating AI for the @Embody_Net & Livepeer Agent Hackathon. It was a pleasure working with you @floozi_official 👏🫡

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

this was generated by nue motion, powered by @Livepeer

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.

#Livepeer🚀

I just won my second hackathon!!🔥

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.

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! atumera.com/hackathon/submit

New @Livepeer agent mcp is 🔥 storage.googleapis.com/story…

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! discord.com/channels/4231608…

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: atumera.com

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.

We fixed a signup bug that affected builders who selected “X” under “Where did you hear about us?” If you hit an error, please try again—you can now register for the Livepeer Agent Hackathon. Sorry for the hassle! atumera.com/hackathon/apply