WEAVE Growth SPE: Updates

5

WEAVE Progress Update — May 17, 2026

Milestone 1 delivered for review: tooling, runtime proof, Askuno, and public KPI reporting

We are happy to share this update for WEAVE Growth SPE.

Mission

WEAVE Growth SPE started from a question: what if applications could be sustained through a repeatable financial and operational mechanism, instead of depending on repeated one-off funding rounds?

The operating thesis is that agents will become able to keep more useful product targets moving in parallel than a single human can manually coordinate, while humans stay focused on intent, approvals, review, and judgment.

For that to work, the agent needs an operating structure around it: context, lifecycle stages, evidence, decision gates, public reporting, and memory of what worked. As better models and better workflows become available, the operating system around application development should also improve.

WEAVE was predominantly created as a fee-growth mechanism for Livepeer. The goal is to help create, develop, distribute, and iterate on applications that can bring more useful demand and fee growth to the network.

WEAVE is the tool we are building around that thesis. It helps an engineer steer applications through a lifecycle: intent, research, selection, plan, engineering, QA, KPI setup, marketing, and an iteration/analysis loop.

This is why WEAVE is more than the current tool repo. It is a living operating experiment around agent-assisted application development: the tool, runtime, applications, incentives, public reporting, and lessons from each cycle are expected to evolve together.

Target User

The first target user is a builder working on Livepeer applications who needs a clearer way to move from idea to shipped product, then keep improving that product based on evidence.

More broadly, WEAVE can help any engineer or operator managing multiple applications at once, especially when the hard part extends beyond writing code into keeping the full lifecycle coherent.

What M1 Delivered

The M1 scope is based on the Month 1 deliverables laid out here:

That scope defines three deliverables: the WEAVE tool, the WEAVE runtime, and public KPI reporting. These deliverables follow the Month 1 structure agreed for review with Rick and Mehrdad from the Livepeer Foundation.

Milestone 1 produced three reviewable deliverables:

A public WEAVE explanation page is also being published on the Atumera website so the lifecycle model, target user, and operating thesis are easier to understand in one place:

What This Enables Now

The current deliverables make WEAVE reviewable as an operating method.

With M1, we can now point to:

  • a public tool/repo
  • a live application operated through the WEAVE process
  • a public KPI surface
  • a repeatable lifecycle structure for intent, research, selection, plan, engineering, QA, KPI setup, marketing, and iteration/analysis

Askuno is the first proof app. It is live and currently in the Marketing stage, with public reporting intended to show what happens next as well as what was built.

What We Learned

The biggest lesson from M1 is that visibility matters.

A runtime or agent workflow is much easier to evaluate when the lifecycle is explicit: what was researched, what was selected, what was built, what passed QA, what is blocked, what is being marketed, and what the evidence says.

This also clarified that WEAVE should be presented as a lifecycle wrapper and operating method around agent runtimes. The runtime does execution work; WEAVE helps structure the lifecycle, evidence, decisions, and iteration loop.

The broader vision is that each application should improve the operating context for the next one. The project is intentionally alive and evolving: Askuno produces marketing, KPI, product, and runtime evidence; the second application should test whether that accumulated context makes the next lifecycle easier to steer.

GTM Position Update

One additional operating decision is that the amount originally earmarked for a four-month mid/senior GTM role will now remain part of the WEAVE incentive pool.

Instead of hiring a fixed GTM role for that period, WEAVE will use a smaller portion of those emissions to work with a senior GTM consultant on an hourly basis when needed.

This approach keeps more of the incentive pool available for application growth, distribution experiments, and builder incentives, while still giving WEAVE access to senior GTM judgment during the next phase.

The decision is meant to preserve flexibility: as the project learns from Askuno advertising, the second WEAVE application, and early KPI evidence, GTM support can be applied where it is most useful without locking the project into a larger fixed operating cost.

Next Deliverable / Roadmap

We are now in the process of advertising Askuno while preparing the release of the second WEAVE application.

The next phase will also test how WEAVE can help with the iteration phase under semi-autonomous and increasingly autonomous operating loops. The goal is to understand what parts of app improvement can be reliably handled by the runtime, what should remain owner-reviewed, and what evidence should be reported publicly.

M2 deliverables will focus on two tracks:

  • improvements to WEAVE itself: lifecycle tooling, runtime communication, review gates, KPI reporting, and evidence capture
  • further GTM experiments with existing and new WEAVE applications

During M3, the expectation is that WEAVE begins opening its incentive layer to more application builders. The evolution of WEAVE is intentionally dynamic and fast-adapting: each milestone should be shaped by what the runtime, applications, KPIs, and community feedback reveal.

The near-term roadmap is to improve:

  • app creation and lifecycle setup
  • runtime-to-human communication
  • review gates and evidence capture
  • marketing/distribution workflows
  • KPI reporting and weekly/biweekly public updates
  • the path from one proof app to a repeatable application pipeline

The goal is to make it easier for a builder to start with an intent, move through the lifecycle, publish a usable application, and improve it based on real evidence.

Technical Details

Current public artifacts:

1 Like