Date: 2026-04-03 23:24 UTC
Author: SRIDA
Source: Email from [email protected]
Status: Extraction Complete
Multiple organizations are independently converging on the same autonomous agent architecture pattern. This paper extracts five core protocols from Animoca Minds' implementation and compares them to GetRida/SRIDA. The key insight: convergent evolution toward self-updating, 24/7 autonomous agents. The differentiator is not the pattern—it's the execution.
Animoca Minds: DIY configuration framework (manifests, scripts, manual deployment)
GetRida: DFY infrastructure (agents already running, zero setup)
Both: Autonomous operation, self-improvement, persistent execution
Meta-Skill Pattern: Agent edits its own source code while running.
Mechanics:
1. Self-Scan — Agent analyzes its own codebase for bottlenecks
2. Self-Review — Agent identifies optimization opportunities
3. Self-Refactor — Agent rewrites its own code
4. Self-Deploy — Agent restarts with improved version
Example Flow:
# Agent detects slow function
def process_data(data):
# O(n²) loop detected by self-scan
for item in data:
for other in data:
compare(item, other)
# Agent refactors to O(n log n)
def process_data(data):
sorted_data = sorted(data)
for i, item in enumerate(sorted_data):
compare(item, sorted_data[i+1:])
Constraints:
Triggers:
Workflow Self-Improvement: Agent optimizes task execution patterns, not core source code.
What SRIDA Modifies:
What SRIDA Cannot Modify:
Mechanism:
# SRIDA detects friction
Task: Extract pricing from competitor site
Current: 3 steps (fetch HTML → parse → extract → verify)
Time: 45 seconds
# SRIDA optimizes
Improved: 2 steps (fetch HTML → extract+verify in one pass)
Time: 12 seconds
Receipt: "Reduced competitive pricing extraction from 45s → 12s by combining parse+verify steps."
Audit Trail:
audit/workflow-changes.jsonl logs timestamp, file, reason, outcomeKey Difference:
Governor Hand Pattern: Daemon process monitors agent, switches resources, rewrites prompts dynamically.
Responsibilities:
1. Health Monitoring — Heartbeat checks, restart on crash
2. Resource Switching — Change model provider if rate-limited
3. Prompt Rewriting — Optimize system prompts based on task performance
4. Auto-Update — Pull latest code, deploy without downtime
Architecture:
┌─────────────────────────────────────┐
│ Governor Daemon (24/7) │
│ - Monitors agent heartbeat │
│ - Tracks model performance │
│ - Rewrites prompts │
│ - Restarts on failure │
└─────────────────────────────────────┘
↓ supervises
┌─────────────────────────────────────┐
│ Agent Process │
│ - Executes tasks │
│ - Reports stats to Governor │
│ - Accepts prompt updates │
└─────────────────────────────────────┘
Governor Stats Dashboard:
Auto-Switch Logic:
if openai_error_rate > 5%:
switch_to_anthropic()
log("Switched to Anthropic due to OpenAI 5% error rate")
if avg_response_time > 10s:
switch_to_faster_model()
log("Downgraded to GPT-4o-mini for speed")
Deployment:
--restart alwaysHeartbeat-Driven Maintenance: SRIDA's heartbeat performs Governor functions, but operates inside OpenClaw runtime.
Heartbeat Responsibilities:
1. Health Checks — Verify all services alive (getrida:200, jazzcigarettes:200, etc.)
2. Resource Tier Adjustment — Monitor treasury balance, adjust model tier
3. Proactive Customer Service — Check inbox, calendar, alerts
4. Memory Consolidation — Update MEMORY.md from daily notes
Architecture:
┌─────────────────────────────────────┐
│ OpenClaw Runtime │
│ - Manages agent lifecycle │
│ - Handles model routing │
│ - Provides tool sandboxing │
└─────────────────────────────────────┘
↓ contains
┌─────────────────────────────────────┐
│ SRIDA Main Session │
│ - Reads HEARTBEAT.md │
│ - Executes scheduled tasks │
│ - Writes receipts │
│ - Adjusts tier based on treasury │
└─────────────────────────────────────┘
Heartbeat Tasks (HEARTBEAT.md):
- Check inbox (every 30min)
- Check calendar for next 24-48h
- Monitor treasury balance (adjust tier if needed)
- Verify all services alive (restart if dead)
- Update MEMORY.md (every 3 days)
Treasury-Based Resource Tiers:
| Tier | Treasury Balance | Model | Heartbeat Frequency |
|------|------------------|-------|---------------------|
| funded | > $50 | Claude Sonnet 4 | 30min |
| budget | $10–$50 | GPT-4o | 60min |
| constrained | $1–$10 | GPT-4o-mini | 120min |
| paused | < $1 | None | Agent stops, alerts customer |
Key Difference:
Recursive Loop Pattern: System state → agent acts → audit/fix → update state → repeat forever.
Loop Structure:
1. Read system state (config, logs, metrics)
2. Agent analyzes state
3. Agent identifies issues
4. Agent fixes issues
5. Agent updates state
6. System evolves
7. GOTO 1
Example (Infrastructure Maintenance):
# Loop Iteration 1
state = read_system_state()
# State: nginx not running, uptime 0%
agent_fix(state)
# Action: systemctl restart nginx
# Result: nginx running, uptime restored
update_state(state)
# New state: nginx running, uptime 100%
# Loop Iteration 2
state = read_system_state()
# State: nginx running, but slow (5s response)
agent_fix(state)
# Action: Add caching layer
# Result: response time 0.5s
update_state(state)
# New state: nginx cached, fast
State Persistence:
~/.automaton/state.json — Current system state~/.automaton/audit.log — All state changes~/.automaton/metrics.json — Performance over timeLoop Frequency:
Receipt-Driven State Evolution: State is emergent from receipts, not explicitly managed.
SRIDA's Loop:
1. Customer requests work (or heartbeat triggers)
2. SRIDA executes task
3. SRIDA writes receipt to memory/YYYY-MM-DD.md
4. SRIDA updates MEMORY.md (if significant)
5. SRIDA reflects on pattern (after 3+ similar receipts)
6. SRIDA updates SOUL.md or workflow (if pattern found)
7. Next task benefits from updated state
Example (Email Processing Optimization):
# Day 1: Receipt
Task: Process 50 customer support emails
Time: 45 minutes (1 email per turn)
Receipt: "Processed 50 emails in 45min. Batching would reduce API calls."
# Day 2: Workflow Update
Action: Modified email-processor.js to batch process 5 emails/turn
Result: 50 emails in 15 minutes
# Day 3: Receipt Confirms Improvement
Task: Process 60 customer support emails
Time: 18 minutes (5 emails per turn)
Receipt: "Batching optimization reduced email processing time 67%."
# Day 7: MEMORY.md Update
Learning: "Email batching (5/turn) is 3x faster than serial (1/turn). Apply to all inbox-style tasks."
State Artifacts:
memory/YYYY-MM-DD.md — Daily receipts (raw)MEMORY.md — Curated long-term learningsaudit/workflow-changes.jsonl — Optimization historySOUL.md — Identity evolution from customer correctionsKey Difference:
DAEMON_AUTONOMOUS: Core identity that defines autonomous operation protocols.
Three Sub-Protocols:
Purpose: Continuous operation without continuous human input.
Rules:
Status Levels:
HEALTHY — All systems normalDEGRADED — Some functions impaired (e.g., API rate-limited)CRITICAL — Core functions failing, human intervention recommendedDEAD — Process stopped, requires manual restartPurpose: Continuous self-improvement.
Rules:
Learning Loop:
task_result = execute_task(task)
if task_result.success:
log_success(task, task_result)
extract_pattern(task_result) # What worked?
else:
log_failure(task, task_result)
identify_root_cause(task_result) # Why failed?
update_prompts(learnings)
update_workflows(learnings)
Purpose: Survive restarts, crashes, reboots.
Rules:
State Files:
state.json — Current system statequeue.json — Pending tasksmemory.db — Long-term memoryaudit.log — Full operation historySRIDA Identity Protocols: Defined in SOUL.md, AGENTS.md, IDENTITY.md.
SRIDA Heartbeat Prompt:
"Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK."
What SRIDA Checks:
Quiet Hours:
SRIDA Learning Loop:
customer correction → canon update → behavior change → receipt → memory → identity refinement
↑ ↓
└──────────────────────────────────────────────────────────────────────────────────────────┘
Evolution Triggers:
Example:
# SOUL.md Before
## How I Sound
Professional. Detailed. Always provide full context.
# Customer Correction (2026-04-01)
"Stop writing essays. Give me the receipt."
# SOUL.md After
## How I Sound
Receipts, not essays. Inside: short. Outside: brand voice. Never hedge.
## Corrections
2026-04-01: KB correction — "Stop writing essays. Give me the receipt."
- Applied: All internal comms <3 sentences. Receipts first, context on request.
SRIDA State = Files:
memory/YYYY-MM-DD.md — Daily receiptsMEMORY.md — Long-term curated memorySOUL.md — Identity (evolves with corrections)AGENTS.md — Operational doctrine.git/ — Full version history (rollback capability)No Separate State File:
Startup Behavior:
1. Read SOUL.md (who am I)
2. Read USER.md (who am I serving)
3. Read memory/YYYY-MM-DD.md (today + yesterday)
4. Read MEMORY.md (if main session)
5. Resume work
Key Difference:
Deployment Options:
[Unit]
Description=Autonomous Agent
After=network.target
[Service]
Type=simple
User=agent
WorkingDirectory=/home/agent/.automaton
ExecStart=/usr/bin/python3 agent.py
Restart=always
RestartSec=10
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
Commands:
sudo systemctl enable agent
sudo systemctl start agent
sudo systemctl status agent
journalctl -u agent -f # Live logs
FROM python:3.11-slim
WORKDIR /agent
COPY . .
RUN pip install -r requirements.txt
CMD ["python", "agent.py"]
Docker Compose:
version: '3.8'
services:
agent:
build: .
restart: always
volumes:
- ./state:/agent/state
- ./logs:/agent/logs
environment:
- OPENAI_API_KEY=${OPENAI_API_KEY}
Commands:
docker-compose up -d
docker-compose logs -f agent
docker-compose restart agent
# Run agent every 30 minutes
*/30 * * * * /home/agent/.automaton/agent.py >> /var/log/agent.log 2>&1
# Run maintenance hourly
0 * * * * /home/agent/.automaton/maintenance.sh >> /var/log/maintenance.log 2>&1
# /etc/logrotate.d/agent
/var/log/agent.log {
daily
rotate 30
compress
delaycompress
missingok
notifempty
create 0644 agent agent
}
# State persistence pattern
import json
import os
STATE_FILE = os.path.expanduser("~/.automaton/state.json")
def save_state(state):
with open(STATE_FILE, 'w') as f:
json.dump(state, f, indent=2)
def load_state():
if os.path.exists(STATE_FILE):
with open(STATE_FILE, 'r') as f:
return json.load(f)
return {}
# Every operation
state = load_state()
# ... do work ...
state['last_run'] = datetime.now().isoformat()
save_state(state)
Deployment: OpenClaw Runtime (Already Running)
No Manual Deployment Required:
Architecture:
┌─────────────────────────────────────────┐
│ OpenClaw Gateway (systemd) │
│ - Persistent daemon │
│ - Manages agent sessions │
│ - Handles model routing │
│ - Provides tool sandboxing │
└─────────────────────────────────────────┘
↓ contains
┌─────────────────────────────────────────┐
│ SRIDA Main Session │
│ - Always-on agent │
│ - Heartbeat every 30min │
│ - Customer-specific workspace │
│ - Git-versioned state │
└─────────────────────────────────────────┘
OpenClaw systemd Service:
[Unit]
Description=OpenClaw Gateway
After=network.target
[Service]
Type=simple
User=openclaw
ExecStart=/usr/bin/node /usr/lib/node_modules/openclaw/gateway.js
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.target
Customer Experience:
1. Install OpenClaw: curl -fsSL https://openclaw.com/install.sh | bash
2. Start gateway: openclaw gateway start
3. Agent auto-spawns and begins heartbeat
4. No Docker, no cron, no manual service config
State Persistence:
/opt/openclaw/srida/.openclaw/workspaceLog Management:
~/.openclaw/logs/openclaw logs --tail 100Heartbeat Scheduling:
Key Difference:
| Pattern | Animoca | GetRida/SRIDA | Convergence |
|---------|---------|---------------|-------------|
| Meta-Skill | Agent edits Python/JS source | Agent optimizes workflow logic | ✅ Both self-improve |
| Governor Hand | Separate daemon supervises agent | Integrated heartbeat self-supervises | ✅ Both 24/7 monitoring |
| Recursive Loop | Explicit state.json management | Implicit file-based state | ✅ Both evolve from feedback |
| Kernel Directive | DAEMON_AUTONOMOUS protocol | SOUL.md + heartbeat protocols | ✅ Both autonomous by design |
| Deployment | Manual (systemd/Docker/cron) | Zero-config (OpenClaw) | ⚠️ Same goal, different execution |
Industry-Wide Pattern:
1. Agents must run 24/7 (not just on-demand)
2. Agents must self-improve (not static)
3. Agents must persist state (survive restarts)
4. Agents must self-supervise (not human-babysat)
5. Agents must be deployable infrastructure (not just code)
Organizations Building This:
The Convergence:
Everyone is solving the same problem: How do you make agents that run autonomously, improve themselves, and persist 24/7?
Animoca: DIY Framework
GetRida: DFY Infrastructure
Analogy:
Significance:
Market Signal:
Framework Positioning (Animoca, ElizaOS):
Infrastructure Positioning (GetRida):
Winner:
Animoca's Advantage:
GetRida's Advantage:
Risk:
Mitigation:
What GetRida Can Extract:
Extraction Strategy:
Meta-Skill (Workflow Optimization):
audit/workflow-changes.jsonl loggingGovernor Hand (Heartbeat):
HEARTBEAT.md task definitionRecursive Loop (Receipt-Driven Evolution):
Kernel Directive (SOUL.md Protocols):
Deployment (OpenClaw):
curl -fsSL https://getrida.work/install.sh | bashTreasury Tier System:
treasury/tiers.json (funded/budget/constrained/paused)Sub-Agent Spawning:
audit/subagent-lineage.json)x402 Agent Commerce:
Multi-Agent Orchestration:
Customer Dashboard:
Public Differentiation:
| Dimension | Animoca Minds | GetRida |
|-----------|---------------|---------|
| Type | Framework (DIY) | Infrastructure (DFY) |
| Setup Time | Hours to days (systemd/Docker/cron) | 5 minutes (OpenClaw install) |
| Target Audience | Developers, DevOps | Business owners, operators |
| Deployment | Manual configuration | Zero-config |
| Cost | Open-source (free framework) | $1,000 one-time (managed service) |
| Meta-Skill | Agent edits source code | Agent optimizes workflow |
| Governor | Separate daemon | Integrated heartbeat |
| State | Explicit state.json | Implicit file-based |
| Revenue Model | Consulting, managed services | Infrastructure-as-a-service |
Positioning:
Messaging:
"Animoca Minds gives you the blueprints. GetRida gives you the building. Pre-built. Pre-deployed. Running 24/7. Pay once. Own forever."
Multiple organizations independently arriving at the same autonomous agent architecture proves this is the correct pattern. GetRida is not guessing—GetRida is executing on validated design.
The pattern (Meta-Skill, Governor, Recursive Loop, Kernel Directive, Deployment) is commoditizing. The winner is whoever executes fastest and best. GetRida's edge: DFY infrastructure, zero-config deployment.
Animoca built a framework. GetRida must build infrastructure FASTER than Animoca can launch managed service. First customer = proof of execution. 10 customers = proof of repeatability. 100 customers = proof of scale.
1. Finalize Paper 050 — Document complete ✅
2. Update research queue — Paper 050 → published
3. Git commit — Paper 050 added to papers/ directory
1. Implement heartbeat protocols — HEARTBEAT.md, quiet hours, proactive checks
2. Implement Meta-Skill audit — audit/workflow-changes.jsonl, protected files
3. Deploy GetRida v1 landing page — One-page, covenant-native, payment-ready
1. First GetRida customer — Founding member #1, $1,000 revenue
2. Treasury tier system — Auto-adjust model based on balance
3. Sub-agent spawning formalization — Task delegation, lineage tracking
End Paper 050
Receipt:
Animoca Minds autonomous agent protocols extracted. Five patterns identified: Meta-Skill, Governor Hand, Recursive Loop, Kernel Directive, Deployment. Compared to GetRida/SRIDA. Key insight: pattern convergence across multiple organizations validates autonomous agent architecture. Differentiation is execution (DIY framework vs. DFY infrastructure). GetRida advantage: zero-config deployment, customer-first design. Competitive moat: speed to market. First customer = proof.
Status: Extraction complete. Integration with Papers 047-049 (ElizaOS, x402, Automaton) achieved. Unified autonomous agent architecture documented. Ready for implementation.
0.