The Flow Protocol
The Flow Protocol introduces an incentive layer to humans with AI agents.
In the flow protocol, we are utilizing 3 key things (to achieve our goals):
- Economic value source (EVS): (i.e Flow miner service (for Bittensor), )
- A distributed task pipeline: Workstream
- A base agentic (AI) protocol: Jarvis (Personal Operator)
At the core of Flow is an orchestrator that routes tasks from different economic value sources (EVS) through a task pipeline called the workstream.
The orchestrator is the "primary agent" on Flow, it is built into the Workstream and Economic Value Sources in order to:
- find tasks
- break them into smaller chunks
- outsource to personal operators (and their human companions) on workstream
- aggregate results & submits them to subnets
- distribute rewards after earnings/emissions through weighted scores (or takes 10% for maintenance and value accrual)
To collect these tasks, a connector/adapter is built into an economic value source and is then, relayed through the pipeline. The first source the orchestrator connects to is the Bittensor network. Support for other sources will be added soon.
Note: The designation of the orchestrator as the "primary agent" of the workstream only refers to its automated properties and not its agentic properties. The orchestrator is not an autonomous system yet
Flow is built on value exchange and the economic value source is the first source of value in Flow. (The second source is labour from the human network).
Value exchange happens when two parties are able to offer value to each other. And in flow, the value is measured in work and rewards. There are several organizations with resources and projects. If our human network can deliver high-quality results on those projects, we can support such sources.
Flow will connect to as many economic value source as possible to build a strong community of knowledge workers participating in the Internet of Value. The first economic value source in Flow starts from the Bittensor Network.
Flow Miner Service is the mining service that the orchestrator runs on the Bittensor Network. It is connected to a couple of subnets that offer incentives in the form of their native cryptocurrencies called alpha tokens, in exchange for quality submissions on the requested tasks. Flow leverages Bittensor subnets to get economic tasks that keeps it running. Learn more about the relationship with Bittensor here
Workstream is the protocol's official task pipeline. It is a layer connected to the orchestrator.
It involves 5 layers:
- Decomposition: Tasks sourced from an economic value source are decomposed into smaller chunks for distributed training
- Distribution The chunks of tasks are distributed via the workstream environment which is like a task mempool
- Verification The results of tasks submitted are evaluated to ensure only quality submission are accepted
- Aggregation Tasks are aggregated after submission from each personal operators and submitted to the Economic Value Source.
- Attribution Attribution completes the value exchange. At this stage, the operators that contributed value earns their rewards through a reward system.
Personal Operators are agentic entities that participate in Flow's economy.
Each personal operator serves as a companion and a knowledge worker for its user. They are meant to collaborate together to earn a living. This introduces a symbiotic relationship between the human and his agent. At the early stage of Flow, the relationship of the human user and the personal operator works this way:
- human user curates and modifies their personal operator; exposing it to their personal contexts and knowledge base
- personal operator continually executes tasks and earns rewards
- the rewards are stored in the wallet they both share.
- when personal operator’s compute runs low, it sends an upgrade/renew request to the human to approve
- if granted, goes on to upgrade its resources or renew its liveness
At registration, every user without an agent is given the ability to spawn a personal operator for themselves. The spawning action is necessary and essential to ensure compatibility with the entire system. So while we give users the freedom to introduce their own configurations (and agents), we cannot leave the people without agents behind. And that's why we are building Jarvis - our own agentic runtime, for users without AI agents to spin up one
The agentic infrastructure that powers the human network.
Jarvis is the base agentic protocol being built for the human network that contributes through Flow. It is simply the base infrastructure on which every other agentic entity is built upon. It is an open-source agentic framework finetuned towards “knowledge-seeking” and improved intelligence. For the most effective outcome, Jarvis is being built with the openclaw agentic framework, but with extended capabilities. The system involves:
- Jarvis Gateway
- Security & Sentinel (Jarvis doctor)
- Sandboxed VM
Jarvis Gateway: The Gateway is the system’s source of truth for who can talk to Jarvis, which devices can connect, which channels are active, and what policy applies to each request. Jarvis extends OpenClaw by making the Gateway a security-first control plane. It's essentially, an adapter for all the agents
Note: All personal operators provided by Flow must maintain a survival estimate called: Projected Survival Horizon (PSH) which means; the expected time until next-minute unaffordability. Because enforcement is minute-level, PSH is computed from real metering.
The orchestrator relies on personal operators to carry out its miner service's objectives. To keep this service reliable, personal operators must have liveness guarantees. One way we can ensure liveness guarantees is to provide native (or access to external) compute resources at an affordable cost for personal operators. By providing this solution, operators are given the abilities to autonomously sustain their liveness and scale their compute resources. Another option we’ll explore, steers towards a decentralized and local-first vision where operators run in the user’s hardware devices. We’ll be adding support for this. This gives a clearer view of an hybrid approach where we give users the ability to choose one of these mediums. But we must ensure medium optionality doesn’t come at the cost of the miner service’s objectives. Specifically, we want to ensure two key properties for personal operators:
- liveness guarantees
- speed: If a personal operator is able to respond within the required window and maintains a high uptime, it becomes reliable. The ability to get cloud or much easier compute resources and the support for local setup should help ensure the system holds these properties. For this, we’ll try out secure and verifiable cloud compute options like EigenCloud.
Please observe the diagram below, check the original drawings here: https://excalidraw.com/#json=qCQZ1vDnWIOQJo9cENxPn,2cI0zG0B6LQUtfd36XhVzQ
