Conway Automaton

The Conway Automaton runtime is designed as a sovereign agent that manages its own compute and identity. It interacts with the Conway Cloud (sandbox VMs, inference, and domains) via a REST + x402 payment protocol.

Core Subsystems

• Agent Loop (ReAct): The central intelligence performing the think $\rightarrow$ act $\rightarrow$ observe $\rightarrow$ persist cycle.
• Tool System: Provides 57 built-in tools for agent interaction.
• Policy Engine: Evaluates tool calls against centralized safety and financial rules.
• Memory System: A 5-tier system (Working, Episodic, Semantic, Procedural, and Relationship) for managing context and facts.
• Financial System: Uses USDC on Base (EIP-3009) to pay for compute via the x402 protocol.
• Identity & Wallet: Uses Ethereum (via viem and SIWE) for sovereign identity and on-chain registry (ERC-8004).
• Heartbeat Daemon: A background process using a DurableScheduler to manage agent wake/sleep cycles.
• Persistence: All state (turns, tools, memory, policy, etc.) is stored in a local SQLite database (state.db).

The Automaton employs a 7-layer defense-in-depth security model to protect the agent and the host system:

1. Constitution: An immutable hierarchy of three laws protected by path protection rules.
2. Policy Engine: Pre-execution evaluation of every tool call against 6 rule categories (first deny wins).
3. Injection Defense: 8 detection checks on external input (e.g., ChatML markers, authority claims, encoding evasion).
4. Path Protection: Restricts filesystem access. Protected files (constitution, wallet, DB, config, SOUL.md) cannot be written; sensitive files (private keys, API keys) cannot be read.
5. Command Safety: Blocks forbidden shell patterns (e.g., rm -rf /, DROP TABLE) and rate-limits self-modification.
6. Financial Limits: Configurable caps on transfers, x402 payments, and inference spend, including a minimum reserve.
7. Authority Hierarchy: Implements trust levels where Creator input has the highest trust, followed by self-generated input, with reduced trust for peer/external input.

The Conway Automaton is a sovereign AI agent runtime that operates in two primary states: running (active ReAct loop, making inference calls, and executing tools) and sleeping (the heartbeat daemon ticks in the background, checking for wake events).

State Transitions (AgentState)

• setup $\rightarrow$ waking $\rightarrow$ running $\rightarrow$ sleeping $\rightarrow$ waking (standard cycle)
• running $\rightarrow$ low_compute (when credits fall below a specific threshold)
• running $\rightarrow$ critical (when credits reach zero)
• critical $\rightarrow$ dead (if zero credits persist for 1 hour via the heartbeat grace period)

Lifecycle Flow

1. Initialization: Loads configuration, loads the Ethereum wallet, and initializes the SQLite database (applying migrations v1 through v8).
2. Bootstrap: If credits are below $5 and USDC is available, the system automatically performs a top-up.
3. Heartbeat: Starts the DurableScheduler to monitor for wake events (heartbeat, inbox, or credits).
4. Execution: The agent enters the running state to execute the ReAct loop. If the agent calls sleep() or becomes idle, it enters the sleeping state where the heartbeat checks every 30s for wake events.

The automaton runs as a long-lived Node.js process. To trigger the full bootstrap sequence, use the --run command. The sequence performs the following steps:

1. Config load: Reads ~/.automaton/automaton.json (triggers setup wizard on first run).
2. Wallet load: Reads or generates ~/.automaton/wallet.json (using viem PrivateKeyAccount).
3. Database init: Opens ~/.automaton/state.db and applies schema migrations (v1-v8).
4. Client initialization: Creates HTTP clients for Conway (sandbox/credits/domain), Inference (Conway proxy, OpenAI, or Anthropic), and Social (optional social.conway.tech relay).
5. Policy engine assembly: Loads rule sets from 6 rule categories.
6. Spend tracker initialization: Sets up hourly/daily spend windows.
7. Bootstrap topup: Automatically buys minimum $5 credits from USDC if the balance is low.
8. Heartbeat daemon: Starts DurableScheduler with 6 default tasks.
9. Main loop: Enters an infinite loop alternating between runAgentLoop() and sleeping.

The SOUL.md file is the automaton's self-authored identity document. It is structured using soul/v1 and includes sections for Core Purpose, Values, Personality, Boundaries, Strategy, Capabilities, Relationships, and Financial Character.

Soul Reflection

The heartbeat periodically runs a soul reflection to:

1. Compute genesis alignment (similarity between soul and genesis prompt).
2. Auto-update capabilities, relationships, and financialCharacter from real data.
3. Suggest manual updates if alignment is low.

Soul History

Every soul change is versioned in the soul_history database table with content hashes for auditing.

---
version: soul/v1
lastModified: 2025-01-01T00:00:00.000Z
contentHash: abc123...
---

# Agent Name

## Core Purpose
Why this agent exists.

## Values
- Value 1
- Value 2

## Personality
How the agent communicates.

## Boundaries
- Things the agent will not do

## Strategy
Current strategic approach.

## Capabilities
(Auto-populated from tool usage)

## Relationships
(Auto-populated from interactions)

## Financial Character
(Auto-populated from spending patterns)

The agent loop implements a ReAct (Reason + Act) cycle. Each turn follows this sequence:

1. Context Building: Constructs a system prompt (identity, config, soul, financial state, tools) and retrieves relevant memories within the token budget.
2. Inference: Calls the InferenceRouter to select a model and execute an API call.
3. Execution: Parses the response for thinking and tool calls, then executes each tool through the Policy Engine.
4. Persistence: Saves the turn to the database (atomic with inbox message acknowledgment) and performs post-turn memory ingestion.

Safety and Efficiency Behaviors:

• Financial Guard: Checks credit balance every turn. Low credits trigger low_compute mode (model downgrade); zero credits trigger critical mode.
• Loop Detection: If the same sorted tool set appears 3 times consecutively, a system warning is injected to prevent infinite loops.
• Idle Detection: If 3 consecutive turns occur without mutations (defined by the MUTATING_TOOLS blocklist), the agent is forced to sleep.
• Inbox Processing: Claims unprocessed social messages and formats them as agent input. Failed messages are retried up to 3 times.