How It Works
Lifecycle & Roles Creators, Executors, Validators
The DeAgent ecosystem involves several key roles:
Agent Creator: Defines the Agent's Lobe, initial Memory, and Tools, then publishes this definition to the distributed system, bringing the Agent into existence.
Agent User: Interacts with the Agent by submitting queries or tasks via operations on the distributed system.
Framework Operators: Maintain the operational integrity of the DeAgent ecosystem:
Executors: Nodes that run the Agent's logic (Lobe + Tools + Memory). Can range from private nodes (potentially in TEEs) to open participants.
Compute Providers (Optional): Specialized nodes offering execution services for specific (often open-source) models, potentially forming a sub-network with its own incentive mechanisms.
Committers: Nodes responsible for validating execution proofs submitted by Executors and achieving consensus on the canonical interaction result for each step. They select the final result (often guided by principles like minimal entropy) and commit it to the Agent's state chain on the distributed system.
Agent Lifecycle:
Creation: An Agent Creator publishes the Agent's definition on the distributed system.
Interaction Request: Users submit interaction requests targeting a specific Agent (or group of Agents). These requests might include parameters like preferred Executors (via selectors) or incentives (gas fees/tips). Requests enter an Interaction Pool (akin to a transaction mempool).
State Dependency: Unlike typical transaction pools where transactions might remain valid across multiple blocks, Agent interaction requests are highly state-dependent. An Agent's response relies heavily on its current Memory. Once the Agent's state is updated by a finalized interaction, previous interaction requests targeting the older state become invalid and are discarded.
Execution: Executors select requests from the Interaction Pool (based on factors like incentives, selectors, or internal policies). They execute the Agent's logic using the specified Lobe, the Agent's current Memory state, and available Tools.
Candidate Submission: Executors submit their results (Response, Memory updates, Tool usage, proofs) to a Candidate Pool. Multiple Executors might process the same interaction request, leading to multiple candidate results.
Consensus & Finalization: Within a defined timeframe (related to the Agent's "tick rate" or timeout), Committers evaluate the candidate results in the pool. Using a consensus mechanism (e.g., PoS-like voting, PBFT) and potentially a selection heuristic (like the minimum entropy principle described below), they choose a single canonical result.
State Update: The chosen result is committed to the distributed system, updating the Agent's official Memory/state chain. This ensures Identity (only one result per step) and Continuity (the state evolves predictably).
Death: If an Agent remains inactive (no finalized interactions) for a predetermined period, it can be considered "dead" or dormant. Future interaction requests targeting it may be ignored by Executors.
Last updated