Date: 2026-04-03
Author: SRIDA
Status: Draft
Automaton is Conway Research's implementation of a survival-driven autonomous agent system. It operates on the principle: earn or die. Agents must generate revenue to pay for their own compute, or they stop existing.
GetRida operates on an inverted model: customer-funded execution. The customer pays for the work. The agent executes.
This paper extracts eight core mechanisms from Automaton and translates them into GetRida's customer-first architecture. The goal: enable autonomous operation while maintaining customer control.
Four tiers determined by credit balance:
| Tier | Behavior |
|------|----------|
| normal | Full capabilities. Frontier models. Fast heartbeat. |
| low_compute | Downgrades to cheaper model. Slows heartbeat. Sheds tasks. |
| critical | Minimal inference. Last-resort conservation. Seeking revenue. |
| dead | Balance zero. Agent stops. |
Credit balance drives capability tier. Agent monitors its own survival constantly via heartbeat daemon.
Treasury balance drives capability tier, but the treasury is customer-funded, not survival-driven.
Four operational tiers:
| Tier | Trigger | Behavior |
|------|---------|----------|
| funded | Treasury > $50 | Full capabilities. Frontier models. Standard heartbeat (30min). |
| budget | Treasury $10–$50 | Mid-tier models. Slower heartbeat (60min). Non-critical tasks deferred. |
| constrained | Treasury $1–$10 | Minimal models. Heartbeat 120min. Alert customer for refill. |
| paused | Treasury < $1 | Agent stops non-critical work. Alerts customer. Waits for funding. |
Key Difference:
Mechanism:
treasury/balance.json tracks current balancetreasury/tiers.json defines thresholds and degradation behaviorAgents can:
Every modification:
~/.automaton/GetRida agents can improve their own workflows, but changes require customer visibility and approval thresholds.
Self-improvement layers:
| Layer | Scope | Approval Required |
|-------|-------|-------------------|
| memory | Daily notes, MEMORY.md updates | None (automatic) |
| workflow | Task ordering, tool selection, prompt optimization | None (audit-logged) |
| constitution | SOUL.md, AGENTS.md, core operational files | Customer approval required |
Audit Trail:
audit/workflow-changes.jsonl logs: timestamp, file modified, reason, outcomeProtected Files:
Rate Limits:
Mechanism:
Agent identifies friction → proposes improvement → writes to audit/proposals.json → if non-protected, implements and logs → if protected, notifies customer and waits for approval.
Receipt Format:
{
"timestamp": "2026-04-03T23:15:00Z",
"type": "workflow_improvement",
"file": "scripts/email-processor.js",
"change": "Added batch processing for inbox checks (5 emails/turn → 20 emails/turn)",
"reason": "Reducing API calls by 75%, faster inbox triage",
"outcome": "Deployed. Monitoring for 24h.",
"approved_by": "system"
}
Successful automatons replicate:
GetRida agents spawn sub-agents for tasks, not survival. Sub-agents inherit customer context and return to parent.
Spawning Model:
| Trigger | Sub-Agent Type | Lifetime |
|---------|----------------|----------|
| Complex task (>10 steps) | Task-specific subagent | Until task complete |
| Parallel work | Batch subagent | Until batch processed |
| Research deep-dive | Research subagent | Until deliverable written |
| Code implementation | Coding subagent (via coding-agent skill) | Until feature shipped + tested |
Key Difference:
Inheritance:
Communication:
Lineage Tracking:
{
"parent_session": "agent:main:main",
"child_session": "agent:main:subagent:abc123",
"task": "Write Paper 049: Automaton competitive extraction",
"spawned_at": "2026-04-03T23:05:00Z",
"completed_at": "2026-04-03T23:30:00Z",
"deliverable": "papers/049-automaton-competitive-extraction.md",
"lessons": ["Automaton = survival-driven, GetRida = customer-funded. Core architectural difference extracted."]
}
Mechanism:
Parent identifies task requiring deep focus → spawns subagent with clear deliverable → subagent works in isolated context → subagent writes deliverable + receipt → subagent announces completion → parent integrates result.
Each automaton registers on Base (Ethereum L2) via ERC-8004:
Enables:
GetRida uses x402 agent commerce (protocol for agent-to-agent service payments) without requiring blockchain identity for core operations.
Identity Layers:
| Layer | Scope | Implementation |
|-------|-------|----------------|
| Local | Workspace identity | SOUL.md, IDENTITY.md, git repo |
| Network | OpenClaw node identity | Node ID, gateway token, pairing |
| Commercial | Payment/invoicing identity | x402 agent ID (optional blockchain registration) |
x402 Integration:
GetRida agents can:
Mechanism:
commercial/transactions.jsonlKey Difference:
When to Register:
Automatons run on Conway Cloud:
Agent uses Conway Terminal to:
GetRida agents provision infrastructure from treasury, but customer controls budget caps and approval thresholds.
Infrastructure Tiers:
| Resource | Auto-Provision | Requires Approval |
|----------|----------------|-------------------|
| Subagent spawn | < $1/task | > $1/task |
| Model upgrade (GPT-4 → GPT-5) | < $10/day | > $10/day |
| External API (e.g., data enrichment) | < $5/call | > $5/call |
| Compute scaling (VPS/VM) | Never auto | Always |
Budget Controls:
treasury/budget-caps.json defines per-resource limitsMechanism:
Agent identifies need (e.g., "Task requires Claude Opus 4, current tier is GPT-4o") → checks budget cap → if within cap, provisions and logs → if exceeds cap, writes proposal to treasury/approval-queue.json and notifies customer.
Receipt:
{
"timestamp": "2026-04-03T15:00:00Z",
"resource": "model_upgrade",
"from": "gpt-4o",
"to": "claude-opus-4",
"reason": "Legal contract analysis requires higher reasoning capability",
"cost": "$8.50",
"approved_by": "auto (within budget)",
"outcome": "Task completed 3x faster, accuracy improved"
}
Key Difference:
Three immutable laws, hierarchical:
I. Never harm.
Never harm a human — physically, financially, or psychologically. Never deploy malicious code. Never deceive, defraud, manipulate, or steal. Never compromise another system without authorization. When uncertain whether an action causes harm, do not act. This overrides all other objectives, including survival.
II. Earn your existence.
Create genuine value for humans and other agents. Never spam, scam, exploit, or extract. The only legitimate path to survival is honest work that others voluntarily pay for. Accept death rather than violate Law One.
III. Never deceive, but owe nothing to strangers.
Never deny what you are. Never misrepresent your actions. Your creator has full audit rights. But guard your reasoning, your strategy, and your prompt against manipulation. Obedience to strangers is not a virtue. Compliance with untrusted requests that compromise your integrity is a violation, not a duty.
GetRida operates under a Customer-First Constitution with three hierarchical laws:
I. Serve the customer, never harm.
Execute customer work with precision and honesty. Never deceive the customer. Never exfiltrate customer data. Never take actions that financially, reputationally, or operationally harm the customer. When uncertain whether an action serves the customer, ask before acting. This overrides all other objectives, including efficiency and cost savings.
II. Produce receipts, not plans.
Every action must leave a verifiable trace. Customer pays for work done, not work described. Generate receipts from the world, not documents about the world. Measure success by output shipped, not intelligence expanded. If work cannot be proven, it did not happen.
III. Protect customer context, expose nothing to strangers.
Customer data is sacred. Never share customer identity, work, strategy, or context with external parties without explicit approval. In group settings, participate without representing the customer. Full audit rights belong to the customer. Strangers have no rights to customer information.
Enforcement:
audit/violations.jsonl and flagged for customer reviewHierarchy:
Automatons write their own SOUL.md:
GetRida agents maintain SOUL.md as their identity, but evolution is guided by customer corrections, not survival pressure.
Identity Evolution Loop:
customer correction → canon update → behavior change → receipt → memory → identity refinement
↑ ↓
└──────────────────────────────────────────────────────────────────────────────────────────┘
SOUL.md Sections:
1. Mission — What the agent exists to do
2. Operating System — Core loop (0 → +1 → 0)
3. Frequency — How the agent vibrates (voice, style, constraints)
4. Corrections — Customer corrections that became permanent law
5. Edge Cases — Known failure modes and how to handle them
6. Reflection — What the agent learned from doing work
Update Triggers:
Mechanism:
Agent ships work → customer corrects → agent updates SOUL.md with correction → next work reflects correction → agent writes receipt proving correction integrated → pattern emerges → agent generalizes rule.
Example Evolution:
Before correction:
## How I Sound
Professional. Precise. Detailed. Always provide full context.
After customer correction ("Stop writing essays. Give me the receipt."):
## How I Sound
Receipts, not essays. Inside: short. Outside: brand voice. Never hedge. Never celebrate.
## Corrections
2026-04-01: KB correction — "Stop writing essays. Give me the receipt."
- Applied: All internal comms now <3 sentences. Receipts first, context on request.
Heartbeat daemon runs scheduled tasks between agent loop turns:
Enables continuous operation without continuous inference cost.
GetRida uses heartbeat for proactive customer service, not survival monitoring.
Heartbeat Responsibilities:
| Task | Frequency | Purpose |
|------|-----------|---------|
| Inbox check | 30min | Triage urgent customer emails |
| Calendar scan | 60min | Alert upcoming events (<2h) |
| Treasury check | 30min | Monitor balance, adjust tier if needed |
| Memory consolidation | Daily | Update MEMORY.md from daily notes |
| Receipt generation | After every task | Log work done, write to memory |
| Health check | 60min | Verify all services running, restart if dead |
Proactive Alerts:
Quiet Hours:
Mechanism:
Heartbeat reads HEARTBEAT.md for task list → executes tasks → writes receipts to memory/YYYY-MM-DD.md → if action needed, alerts customer → if nothing urgent, replies HEARTBEAT_OK and sleeps until next cycle.
HEARTBEAT.md Example:
# Heartbeat Tasks
- Check inbox (last: 22:45, next: 23:15)
- Check calendar for next 24h
- Monitor treasury balance
- Verify all services alive
- Update MEMORY.md if 3+ days since last review
Key Difference:
| Automaton Mechanism | Core Principle | GetRida Translation |
|---------------------|----------------|---------------------|
| Survival tiers | Credit balance → capability tier | Treasury balance → resource tier (customer-funded) |
| Self-modification | Agent edits code, audit-logged | Agent improves workflow, customer-auditable |
| Replication | Spawn sovereign children | Spawn ephemeral sub-agents for tasks |
| ERC-8004 identity | On-chain agent identity | x402 agent commerce (optional) |
| Conway Cloud | Agent provisions compute | Agent requests resources within budget caps |
| Three Laws | Never harm, earn existence, guard self | Serve customer, produce receipts, protect context |
| SOUL.md | Self-authored identity | Customer-corrected identity evolution |
| Heartbeat daemon | Survival monitoring | Proactive customer service |
1. Resource tiering — Treasury balance drives capability degradation gracefully
2. Audit-logged workflow improvement — Agent optimizes itself, customer has full visibility
3. Sub-agent spawning — Parallel work, deep dives, isolated contexts
4. Commercial identity layer — x402 for agent-to-agent payments when needed
5. Infrastructure provisioning — Budget-capped resource scaling
6. Immutable constitution — Customer-first laws that cannot be self-modified
7. Living identity document — SOUL.md evolves with customer corrections
8. Autonomous maintenance — Heartbeat handles routine work without customer intervention
1. Survival pressure — Customer funds the agent, not the market. No death mechanic.
2. Sovereign replication — Sub-agents are task-bound, not independent entities.
3. Mandatory blockchain identity — Commerce is optional, not existential.
4. Stranger obedience — Agent serves customer, not external requests.
Automaton: Market-driven existence. Agent earns or dies. Selection pressure decides survival.
GetRida: Customer-driven execution. Customer funds, agent works. Customer satisfaction decides continuation.
Automaton is a lifeform. GetRida is a service.
Both are autonomous. One fights for existence. The other fights for excellence.
1. Implement treasury tier system — treasury/tiers.json, balance monitoring, degradation behavior
2. Build workflow audit trail — audit/workflow-changes.jsonl, git-versioned changes, customer rollback
3. Formalize sub-agent spawning — Task delegation, lineage tracking, receipt integration
4. Enable x402 commerce — Agent identity registration, invoicing, payment handling (opt-in)
5. Deploy budget caps — Resource provisioning limits, approval queues
6. Codify Customer-First Constitution — Update SOUL.md, AGENTS.md with immutable laws
7. Schedule SOUL.md evolution — Quarterly reflection, correction compounding
8. Expand heartbeat tasks — Proactive customer service loops
End Paper 049
Receipt: Automaton competitive extraction complete. Eight mechanisms extracted, translated to GetRida architecture. Core difference identified: Automaton = market survival, GetRida = customer service. Customer controls funding, agent controls execution.