A Federated Agent is an autonomous software actor that operates locally within a decentralized or peer-to-peer environment. It can read, interpret, and generate structured content like wiki plans, prompts, or Vibelets, while communicating across federated systems using shared conventions and open protocols.
Federated Agents are typically deployed on laptops, homelabs, or personal servers and are designed to cooperate within a larger network without depending on centralized infrastructure or user accounts.
# Key Characteristics - Runs locally and independently, without relying on cloud APIs or session-based identity - Identified by public-private keypairs, and signs its output for verification - Can execute structured task plans written in JSON, YAML, or Markdown-backed formats - Supports human-in-the-loop workflows via ghost pages and signed edits - Understands Federated Wiki content models and can operate across domains - Can collaborate with other tools, agents, or scripts using system calls or HTTP
# Use Cases - Reads and executes task plans stored in wiki pages - Writes ghost pages containing signed suggestions or generated content - Produces Vibelets: zero-dependency widgets written in HTML, CSS, and JS - Signs journal edits or output plans to ensure verifiability and provenance - Pulls data from other pages and constructs composite views or dashboards - Interacts with Livecode applications or command-line interpreters
# Identity and Trust Each agent possesses a unique cryptographic identity and uses it to sign its outputs. These signatures allow: - Verifying the author of a change or Vibelet - Tracing output to a specific plan or agent version - Supporting local trust policies that accept or reject agent contributions - Forking and review models where each reviewer adds their own signature Agents may also announce key rotation or revocation events via signed journal entries.
# Collaboration Across Federation Federated Agents can read structured prompts and plans from remote wiki pages. They can create ghost-pages, adapt, and re-sign their own plans or code in response. This creates a distributed model of co-evolving workflows, where knowledge is expressed as editable, inspectable, and remixable plans.
# Agent Workflow 1. A wiki page includes a plan written in structured JSON or YAML 2. The agent reads the plan and performs the requested steps 3. The output is written as a ghost page or signed journal delta 4. A human reviews the output and decides whether to publish, fork, or reject 5. Optionally, another user or agent signs the result to express endorsement
# Advantages - Works offline or in air-gapped environments - Enables agent experimentation without central coordination - All actions are traceable, signed, and reviewable - Encourages remixing and iteration across the network - Supports trust-building via cryptographic identity and signed forks
# Implementation Considerations - Agents should rotate keys regularly and publish their public key metadata - Ghost pages provide a safety layer for reviewing before publishing - A standard schema for plan documents improves interoperability - Agent actions should be logged in journal entries with signature metadata - Vibelets created by agents should be signed to verify integrity and authorship
# See
- Vibe Code Playground
- Federated Agent and Federated Plans
- Sessionless on github 
- Open Hands on github
- crewai.com
- SubtleCrypto - developer.mozilla.org