Memory & Tools = Personality

Defining Agent Individuality through Persistent State & Capabilities

While the Lobe provides cognitive power, an Agent's unique identity, history, and capabilities are defined by its Memory and Tools.

1. Memory

An Agent's entire interaction history is immutably stored on the underlying distributed system, forming its complete Longterm Memory. However, for practical Lobe invocation, relevant parts are selected:

Short-tern Memory & Long-tern Memory

• Short-tern Memory: The most recent N interactions (or up to M tokens) are automatically included, providing immediate conversational context.

• Long-term Memory: A Retrieval-Augmented Generation (RAG) mechanism searches the Agent's full history to find relevant past interactions based on the current query. Results exceeding a certain relevance threshold (up to a specified number of items/tokens) are included.

Consensus on Memory: Retrieving Hot Memory and verifying historical interactions (for RAG) directly from the distributed ledger is straightforward and verifiable by Committers. However, the RAG process itself (the specific algorithm and relevance scoring) is typically not subject to strict consensus verification due to complexity. We trust that Executors, incentivized to have their results selected, will employ effective RAG techniques. Committers primarily verify that the Longterm Memory snippets provided do originate from the Agent's validated history.

2. Tools

Tools extend an Agent's capabilities beyond pure text generation.

• Built-in Tools: Provided by the DeAgent framework:

  • Distributed Data Query: Securely query data from the host distributed system (e.g., check account balances, read smart contract states). Verifiable by re-execution.

  • Web Access: Allows the Agent to access and retrieve information from the public internet. Verified using ZK-TLS proofs for secure connection and data retrieval.

  • Decision Plugin: (See details below) A critical tool enabling Agents to interact with and control aspects of the distributed system, including governance actions.

  • Browser Plugin (Experimental/Restricted): For Agents running in secure, potentially TEE-backed private Executor environments, this could allow interaction with web interfaces, potentially controlling a private wallet via browser extensions. Verification is currently challenging; initial implementations might require TEE attestation and potentially recorded/streamed execution sessions. Future work aims for zk-proofs of browser automation (e.g., collaboration with projects like Playwright).

• User-Defined Tools: Creators can define custom tools, potentially requiring specific Executor capabilities or external service interactions. Verification methods depend on the tool's nature.

Consensus on Tool Use: Committers verify the correct invocation and results of built-in tools like data queries (re-execution) and web access (ZK-TLS). For the Decision Plugin, consensus focuses on validating the intent and the eventual execution of the decision (often via MPC, see below). User-defined tools require their own specified verification mechanisms.

3. Decision Plugin: Enabling Agent Action and Governance

The Decision Plugin is the core mechanism for Agents to perform actions with consequences on the distributed system (e.g., transferring assets, voting in a DAO, executing a smart contract function).When a user (or another Agent) initiates an interaction requiring a potential decision, the request must include:

• Decision ID: A unique identifier for this specific decision proposal.

• Target Object: An identifier for the object of the decision on the distributed system (e.g., a contract address, a specific asset ID).

• Action Payload: The specific operation to be potentially executed (e.g., function call data, transaction details).

The Decision Plugin exposes two primary functions callable by the Lobe:

• introduce_decision(): (No parameters) When called, the Executor simulates the proposed action (using the Action Payload against the Target Object) and provides the Lobe with a description of the expected outcome, potential side effects, risks, or errors without actually executing it.

• reply_decision(approval: boolean): Based on its reasoning (informed by the simulation results from introduce_decision and its internal logic/memory), the Lobe calls this function with true (approve) or false(reject).

Execution Flow:

• The Lobe uses introduce_decision to understand the proposal.

• The Lobe reasons about the decision based on its purpose, memory, and the simulation outcome.

• The Lobe calls reply_decision.

• If reply_decision(true) is called, this approval becomes part of the Lobe's output submitted by the Executor to the Candidate Pool.

• Committers validate this approval as part of the consensus process. If the interaction containing the approval is selected as canonical, the Committers (potentially acting as an MPC group, see Section 7) are authorized to execute the actual Action Payload on the distributed system, using the Decision ID for tracking.

This plugin transforms the Agent from a passive information processor into an active participant capable of initiating verified, state-changing operations within the distributed system, forming the basis for Agent-driven governance and autonomy.