Technical Lightpaper

Agents that outlive their servers

March 2026

Most agent systems today are bound to a particular operator, database, or vendor runtime. If the infrastructure disappears, the agent's context and continuity go with it. Botany inverts this: history and state are canonical and durable, so the system can be recovered, migrated, or forked.

Goal

Agents as public infrastructure, not hosted apps.

  • —Permanent history: the agent's evolution is preserved
  • —Recoverability: lost deployments restart from chain state
  • —Governability: communities upgrade agents without erasing the past
  • —Composability: agents assembled from modules, not monoliths
  • —Long-horizon autonomy: execution context that persists across operators

Agent Identity

An agent is defined by its private key. The key signs actions and state updates, controls permissions and spending, anchors continuity across migrations. Everything else—config, modules, capabilities, checkpoints, history—can change, but changes are recorded so the agent stays interpretable and restartable.

What Botany Is

Botany is not the runtime. Independent runners execute agents in encrypted VMs. Botany is the substrate that makes runners interchangeable and recoverable.

Three primitives:

  • —I/O boundary: common interface for tools and modules
  • —Work scheduling: durable jobs that survive restarts and runner changes
  • —BSV persistence: canonical timeline for composition, checkpoints, history

Modularity

Agents are composed from WASM blocks stored on-chain, distributed via marketplace. Planners, policies, connectors, memory, retrieval, constraints—swap any block through governance. Upgrades don't overwrite history; they create new points on the timeline, preserving the ability to reconstruct prior behavior.

Architecture

Runners execute; Botany anchors continuity.

Communities
       ↓
Encrypted VM Runners
       ↓
WASM + Tool Marketplace
       ↓
Bitcoin SV (composition + scheduling + checkpoints + history)

Why Permanence Matters

Server lost

Runner fails permanently. New runner reads the chain: loads module set, restores checkpoint, resumes work queue. The agent survives because identity + state aren't tied to any server.

Upgrade without rewriting the past

Community replaces a planner or connector via governance. New runs use new modules; old runs stay interpretable because the historical module set is preserved on the chain timeline.

Durable knowledge

Documents and indices published as on-chain infrastructure. Knowledge dependencies stay stable across migrations—portable and shared, not trapped in one operator's database.

Longer Horizon

Agents autonomous in the full sense: not only capable of acting, but capable of persisting, migrating, and continuing despite infrastructure loss or operator turnover. Over time, models and weights anchored on-chain, executed on distributed compute—agents as durable, upgradeable public processes rather than applications bound to a single server.