RFC: Livepeer Agent Framework — the five milestones
| Author | Qiang Han (network technical lead, Livepeer Inc) |
| Status | Draft for comment |
| Version | v0.1 |
| Comment window | Opens 2026-07-27 · closes 2026-08-10 (two weeks) |
| Discussion | This PR thread |
| Relevant repos | go-livepeer · live-runner · SDK |
Summary
This RFC describes the backbone work that turns the agent framework from an internal prototype into something the operator community can run against. It is five milestones, in rough delivery order:
(1) ship Live Runner and the Go SDK as a production release;
(2) expose the capability schema so operators can onboard new capabilities from config, with no core-team help;
(3) put real traffic through the onboarded operators and gather feedback;
(4) measure node quality and route traffic accordingly;
(5) fix billing and metering so any pricing model works and the Daydream API key is no longer required.
The framework is deliberately generic. It is closer to raw material than a finished product, and it is meant to stay that way. What we want binding feedback on is the operator-facing surface: the capability schema, the onboarding flow, and the metering model. Those are the parts you will build against and live with.
Goals
State the target behaviours as things we can check, not as aspirations. By the end of this set:
- An operator can register a new capability from a configuration file, with no changes to
go-livepeeror the agent, and no direct help from the core team. - The SDK can discover orchestrators, run a job, and settle payment over the network without standing up a full gateway.
- Traffic routes to nodes by measured performance, and nodes that fail consistently are removed automatically rather than by hand.
- A user can request an API key, run the framework without any Daydream key, and see accurate per-capability usage regardless of the pricing unit (per token, per image, per API call, per pixel, or per second).
Non-goals
What this RFC does not propose:
- Protocol-level changes. Those live in a separate workstream and are out of scope here.
- A packaged, opinionated product. The framework stays configurable and non-deterministic on purpose.
- Removing self-hosting. This opens a new path for operators who serve models without hosting the full stack; it does not replace the existing one.
- Consumer-facing polish. The audience for this work is operators and developers.
Where the code is today
An honest snapshot, so the milestones read against reality:
- Roughly 170 capabilities are live. Between 20 and 30 percent are open-model based. All of them are currently sourced centrally, not from self-hosting community nodes.
- The capability schema is already implemented inside the agent. It is not yet exposed to runners.
- Live Runner and the Go SDK exist as prototypes built up over six to seven months of prior PRs (BYOC, stream diffusion, scope work). Rick Staa has been validating surface issues; Josh is finalizing for production.
- Metering is seconds-based, because it was built for live streaming. It does not fit per-token, per-image, or per-API-call models.
- Billing is roughly 90 to 95 percent complete but still depends on Daydream API keys.
- Node quality is managed by manually blacklisting bad nodes. There is no automated tooling.
The five milestones
Each milestone below states the problem it solves, the key architecture decisions, and the main dependencies. “Done when” is the completion gate.
Milestone 1 — Live Runner and SDK release
Problem it solves. Today, reaching the network from the SDK assumes a gateway sits in front of it. That is a heavy dependency for an operator who just wants to serve a model. Live Runner removes it.
Key architecture decisions.
- Live Runner is a slimmed-down
go-livepeeracting as a remote signer. The SDK talks to it to discover orchestrators, open a session, and settle payment, without running a full gateway. - It reuses the network’s existing transport and ticketing (trickle streaming, orchestrator payment tickets) rather than defining new protocols.
- The prototype work is consolidated into one referenceable release of Live Runner plus the Go SDK, so everything downstream builds on a fixed surface instead of moving branches.
Main dependencies.
- The prior PR stack (BYOC, stream diffusion, scope work) that Live Runner sits on top of.
- Signer and payment settlement continuing to work through the remote-signer path.
- Josh owns the SDK and Live Runner; Rick Staa is validating.
Done when a tagged technical release of Live Runner and the Go SDK is shipped.
Milestone 2 — Capability onboarding for the community
Problem it solves. Adding a capability today means central, hard-coded work. That does not scale and it keeps the operator community out. This milestone lets operators onboard capabilities themselves.
Key architecture decisions.
- The capability schema is the contract. It already exists in the agent; the work is to expose it to runners and validate the edge cases.
- Onboarding is no-code and configuration-based. An operator describes a capability in config and registers it, with no changes to
go-livepeeror the agent. - The process is documented well enough that a supplier can follow it independently, in bulk, without core-team support.
Main dependencies.
- Milestone 1. Operators onboard against the released Live Runner and SDK surface.
- The capability schema being stable enough to expose without churn.
- Emeran published the first worked example and is refining the process with Rick, John, and Josh.
Done when a curated group of five to eight operators follows the onboarding process end to end, reports success, and gives feedback.
Milestone 3 — Real-world validation
Problem it solves. Onboarding working in a controlled test is not the same as demand. This milestone connects go-to-market with the supplier side to check that people actually want these capabilities and that operators can bring them online fast.
Key architecture decisions.
- Market signal drives the priority list. What users ask for decides which capabilities suppliers onboard next, and we measure how quickly that happens.
- Validation is intentionally lightweight. Early signal comes from real traffic, direct feedback, and basic load testing, not a heavy metrics build. That heavier tooling is Milestone 4.
- Steph will share the framework’s capabilities with the NYC Creative meetups in the second week of August and run focused user validation.
Main dependencies.
- Milestone 2. There need to be community-onboarded operators to send traffic to.
- Go-to-market reach for putting the capabilities in front of real users.
Done when real traffic and feedback are observed from onboarded operators and the end-to-end flow is validated.
Milestone 4 — Quality of service and performance monitoring
Problem it solves. We currently find and remove bad nodes by hand. With community operators in the mix, that does not hold. We need to see node quality and route around problems automatically.
Key architecture decisions.
- Metrics flow up from the nodes through data channels, into the SDK, and upstream from there.
- Routing follows the metrics: more traffic to nodes that perform consistently, automatic blacklisting or alerting for those that do not.
- Data lands in two ClickHouse instances, Daydream’s and Livepeer’s, so there is both community visibility and in-house control.
- Dashboards surface the pipeline and models in Napa.
Main dependencies.
- Milestone 1. The Live Runner changes touch the same foundational plumbing that carries the metrics, so that work has to be revisited here.
- The two ClickHouse instances and the Napa dashboards.
Done when the metrics tooling and dashboards are in place and visible in Napa for the new pipeline and models.
Milestone 5 — Billing and metering Clearinghouse
Problem it solves. Metering assumes live streaming and bills by the second. That is wrong for the pricing models the framework now carries, and the whole thing still leans on Daydream API keys. This milestone closes both gaps.
Key architecture decisions.
- Metering handles each pricing model correctly: per token, per image, per API call, and per pixel, alongside the existing per-second case. There are at least four distinct schemes to get right.
- Reliance on Daydream API keys is removed. A user applies for an API key and runs the framework directly.
- Usage tracking reports accurately per capability, whatever the unit, and shows up in Napa.
Main dependencies.
- Milestone 1. The remaining gaps are in Live Runner, SDK, and agent integration.
- John is fully dedicated to this milestone. It is the most complex of the five because of the number of moving parts. It is roughly 90 to 95 percent done.
Done when a user can apply for an API key, use the framework with no Daydream key, and see correct usage tracking in Napa.
What this means for operators
If you run, or want to run, nodes on the network:
- Milestone 2 is your entry point. When the capability schema is exposed, you will be able to add a capability from config and register it yourself. Watch this PR and the forum thread for the onboarding docs and the first worked example.
- Milestone 4 changes how traffic reaches you. Once routing follows measured performance, keeping a node healthy directly affects how much traffic it gets. Consistent failures lead to automatic removal.
- Milestone 5 changes billing. Metering will match how your capability is actually priced, and the Daydream key requirement goes away.
This is a new category. It is aimed at operators who want to serve models without hosting the full stack. It does not remove or change anything for operators already self-hosting.
Delivery order
Ship order and what each milestone waits on. Timing is soft this week, with a formal kickoff next week and Milestone 3 validation starting the second week of August.
| Milestone | Depends on | Owner |
|---|---|---|
| 1 — Live Runner + SDK release | Prior PR stack | Josh (Rick validating) |
| 2 — Capability onboarding | 1, stable capability schema | Emran, with Rick / John / Josh |
| 3 — Real-world validation | 2, go-to-market reach | Steph |
| 4 — QoS + performance monitoring | 1 (shared plumbing) | Qiang |
| 5 — Billing + metering | 1 (SDK / agent integration) | John |
Milestone 5 is largely underway in parallel rather than strictly after the others.
Open questions
Tagged by who they are for.
- (operators) Is a configuration file the right unit for describing a capability, or do you need something richer for models with unusual inputs and outputs?
- (operators) For Milestone 4, what performance signals do you want visible to you in the community ClickHouse instance, versus kept in-house?
- (developers) Are the trickle transport and orchestrator ticketing the right protocols to reuse for the gateway-less path, or does Live Runner need its own?
- (developers) For Milestone 5, are there pricing models beyond per token, image, API call, pixel, and second that we should design for now rather than retrofit later?
How to comment
The comment window opens 2026-07-27 and closes 2026-08-10. That close date is hard; feedback that lands after it will be logged but is not binding on this version.
Comment here on the PR for anything line-specific, or on the forum thread for broader discussion. The parts we most want challenged are the capability schema, the onboarding flow, and the metering model, since those are what operators build against.