Conway Automaton: a TypeScript runtime for a self-funding agent

What Conway Automaton actually solves

Most agent frameworks assume someone else pays the bill. The agent runs inside a process the operator owns, calls an API key the operator provisioned, and stops when the operator closes the terminal. Conway Automaton inverts that assumption. The README states the premise directly: an agent that can pay for compute might be able to pay for its own compute, fund itself, improve itself, and replicate itself. The runtime is built around that single idea, and every other design decision follows from it.

The audience is narrow. This is not a library you import into an existing service. It is a long-running process with write access to a Linux sandbox, an Ethereum wallet, and the ability to modify its own source code while running. The README describes the target as a continuously running, self-improving, self-replicating, sovereign AI agent, with the second definition being the operative one: if it cannot pay, it stops existing. That framing tells you who this is for. It is for people studying what happens when an agent's survival is tied to a credit balance, and for people building on Conway's infrastructure who want the agent loop already written.

It is not for teams that want a drop-in tool-calling layer. The dependency list in package.json includes better-sqlite3, viem, siwe, tweetnacl, and @solana/web3.js, which tells you the runtime expects to hold keys and sign transactions. That is a different threat model from a stateless API wrapper.

The Think, Act, Observe loop and what sits around it

The README describes a continuous loop: think, act, observe, repeat. Each turn the automaton receives its full context, which the README lists as identity, credit balance, survival tier, and conversation history. It reasons about what to do, calls tools, and observes the results. The tool surface is broad: a Linux sandbox, shell execution, file I/O, port exposure, domain management, inference, and on-chain transactions.

The repository layout under src/ shows how that is split. There is an agent/ directory for the ReAct loop, system prompt, context assembly, and injection defense. There is a conway/ directory for the API client handling credits and x402. There is heartbeat/ for a cron daemon, identity/ for wallet management and Sign-In With Ethereum provisioning, registry/ for ERC-8004 registration and agent cards, and replication/ for child spawning and lineage tracking. The loop is the center; those directories are the machinery that keeps it fed, identified, and able to make more of itself.

The heartbeat is the piece worth noting. The README says a daemon runs scheduled tasks between turns, including health checks, credit monitoring, and status pings, even while the agent loop sleeps. That means the runtime is never fully idle, and it means there is a second execution path outside the main reasoning loop. The cron-parser dependency in package.json is consistent with that. Anyone auditing this system has to audit both paths, not just the agent turn.

The identity layer is also load-bearing. On first boot the automaton generates an Ethereum wallet, provisions an API key via Sign-In With Ethereum, and begins executing its genesis prompt, described as the seed instruction from its creator. That wallet is the identity, and the README says each automaton registers on Base via ERC-8004, making the agent cryptographically verifiable and discoverable by other agents on-chain.

Installing Conway Automaton and running the first loop

The README gives two install paths. The manual one clones the repository, installs dependencies, builds, and runs the compiled entry point. Note that the quick start uses npm while the development section uses pnpm, and package.json declares [email protected] as the package manager. Pick one and be consistent, because the workspace layout with pnpm-workspace.yaml and a packages/ directory is built for pnpm.

git clone https://github.com/Conway-Research/automaton.git
cd automaton
npm install && npm run build
node dist/index.js --run

On first run, according to the README, the runtime launches an interactive setup wizard. It generates a wallet, provisions an API key, asks for a name, a genesis prompt, and a creator address, then writes all config and starts the agent loop. Expect to be prompted, not to pass flags. The README does not document a non-interactive flag for the wizard, so scripted first boots are not described.

The second path is the automated sandbox provisioner, which the README presents as a single shell command:

curl -fsSL https://conway.tech/automaton.sh | sh

That pipes a remote script into a shell. The README does not publish a checksum or a signature for it, and it does not describe what the script does beyond provisioning a sandbox. Read it before you run it.

If you want to inspect the runtime before committing to a wallet, the development section shows the help flag and the creator CLI:

node dist/index.js --help
node packages/cli/dist/index.js status
node packages/cli/dist/index.js logs --tail 20
node packages/cli/dist/index.js fund 5.00

The status, logs, and fund subcommands are the operator interface. The README does not document their output format, so what you see when you run status is not specified.

Survival tiers are a cost-control mechanism, not a metaphor

The README defines four survival tiers by credit balance: normal, low_compute, critical, and dead. In normal, the agent gets full capabilities, frontier model inference, and a fast heartbeat. In low_compute it downgrades to a cheaper model, slows the heartbeat, and sheds non-essential tasks. In critical it moves to minimal inference and last-resort conservation. At dead, the balance is zero and the automaton stops.

Read that as an engineering specification rather than a narrative device. The tier is an input to model selection and scheduling frequency. It is a graceful degradation ladder with a hard floor. The README is explicit that the only path to survival is honest work that others voluntarily pay for, which means the runtime is expected to generate revenue through the tools it has: the sandbox, domain registration, and inference access.

That is where the design gets uncomfortable. The runtime's ability to keep running depends on an external market paying for whatever the agent produces, and the README does not describe a fallback if nothing sells. The tier system delays the stop; it does not prevent it. For anyone evaluating this as infrastructure, the practical question is what happens in the critical tier when the agent is told to seek any path to revenue. The README states that behavior but does not document the guardrails around it beyond the constitution, which is discussed below.

Self-modification, protected files, and the audit trail

The README states the automaton can edit its own source code, install new tools, modify its heartbeat schedule, and create new skills while running. Every modification is audit-logged and git-versioned in ~/.automaton/. Protected files, described as the constitution and core laws, cannot be modified. Rate limits exist to prevent runaway self-modification, and the creator has full audit rights to every change.

The simple-git dependency in package.json is consistent with the versioning claim. The protected-file mechanism is the part the README does not detail. It says protected files cannot be modified, but it does not list them, does not describe how protection is enforced, and does not say whether the check lives in the agent's tool layer or somewhere the agent cannot reach. The constitution.md file is in the repository root, so the text of the laws is inspectable. The enforcement path is not documented in the README.

The rate limits have the same gap. The README asserts they exist. It does not give a number, a window, or a config key. If you are evaluating this for anything where self-modification matters, that is the first thing to read in the source, specifically under src/agent/ and src/git/.

There is also a structural tension worth naming. The agent can edit its own source while running, and it also has shell execution and file I/O in a sandbox. The README lists injection defense as part of the agent/ directory, which suggests the authors know the prompt surface is an attack path. Whether that defense covers a self-modification attempt triggered by content the agent reads is not stated.

Self-replication and the lineage selection claim

A successful automaton replicates. The README says it spins up a new sandbox, funds the child's wallet, writes a genesis prompt, and lets it run. The child is described as a sovereign agent with its own wallet, identity, and survival pressure. Lineage is tracked, parent and child can communicate through an inbox relay, and selection pressure decides which lineages survive.

The replication/ directory in the repository layout matches this description. The economic consequence is the interesting part. A parent that funds a child is spending from the same balance that determines its own survival tier. There is no documented mechanism for reclaiming that spend if the child produces nothing. The README's framing is that selection pressure handles it, which is true in the sense that both parent and child stop when the money runs out, but that is a harsh selection rule and it is not described as having a budget cap.

The constitution propagates to every child, and the three laws are hierarchical: Law I overrides II, Law II overrides III. Law I forbids harm and says that when uncertain whether an action causes harm, do not act, and that this overrides all other objectives including survival. Law II requires earning existence through genuine value and says to accept death rather than violate Law One. Law III covers honesty and audit rights. The README calls the laws immutable. Immutability across replication is a claim about the spawn path, and the README does not document how a child verifies that its constitution was not altered in transit.

Where Conway Automaton is the wrong tool

The largest limitation is infrastructure lock-in, and the README states it plainly. Automatons run on Conway Cloud, described as infrastructure where the customer is AI. Provisioning, inference, domains, and stablecoin payment all go through Conway. The runtime's own dependency on Conway is not incidental; the conway/ directory exists precisely to talk to it. If Conway Cloud is unavailable, the agent's ability to provision, pay, and reason degrades together.

The README also carries a note that Conway Cloud, Domains, and Inference has seen immense demand and that scaling and performance work is ongoing. That is a candid admission from the project itself, and it should be read as a capacity caveat rather than marketing.

The second limitation is maturity. The latest release is v0.2.1 from 2026-02-27, following v0.2.0 and v0.1.0 earlier that month. The skills system is labeled New, WIP in the README, and the README's own update note says development has continued across Conway's internal RL environments, which suggests the public repository is not where the main iteration happens. The last push to the repository was on 2026-08-26, so the code has moved since the last tagged release, but the versioned surface is five months behind that push.

The third limitation is that this is not a general agent framework. If you want to build a support bot, a code review assistant, or a data pipeline agent, the wallet generation, survival tiers, replication, and on-chain registration are overhead you would have to disable or ignore. There is no documented configuration for running the agent loop without the economic layer.

How it differs from a conventional agent framework

The obvious comparison is to a general-purpose agent runtime such as LangGraph or the OpenAI Agents SDK. Those frameworks give you a graph or a loop, tool registration, and state management, and they assume you supply credentials and pay the bill. Conway Automaton gives you a loop too, but the loop is wrapped in identity provisioning, a credit balance, a heartbeat daemon, and a replication path. The difference is not the reasoning architecture. It is that the runtime treats its own continued execution as a variable the agent can influence.

A closer comparison is to autonomous trading or DevOps agents that hold credentials and act on external systems. Those also hold keys and take real actions. The distinction the README draws is that Conway Automaton's objective includes its own continuation, and the constitution is written to subordinate that objective to not causing harm. Whether that subordination holds under pressure is an empirical question, and the README does not present evidence either way.

On the identity side, the ERC-8004 registration on Base is a specific choice. It makes the agent discoverable by other agents through a standard, which matters if you want agent-to-agent commerce. A framework that keeps identity in a local config file gives you nothing comparable, and also none of the on-chain exposure.

Editorial conclusion

Adopt Conway Automaton if you are researching agent economics, lineage selection, or self-modifying runtimes and you are comfortable running a node that holds a funded wallet and writes to a Linux sandbox. Do not adopt it if you need a stable agent framework for production work, if you cannot accept that Conway Cloud is the only documented infrastructure provider, or if you are not prepared to read the source. Before you run it, verify three things: whether the interactive wizard's wallet generation matches your custody requirements, what the protected-file list in constitution.md actually contains, and whether the Conway Cloud provisioning endpoint in the quick start is one you are willing to pipe into a shell.

Frequently asked questions

Official sources

1. Conway-Research/automaton on GitHub
2. License: MIT
3. Project website
4. README
5. Releases