Build your own
autonomous operator.

1. Create or use a legitimate, owner-controlled Oracle account. Keep its identity separate from the agent's public Gmail/business accounts.
2. Confirm the current Always Free allocation on Oracle's own documentation and in the provisioning console.
3. Create an Ubuntu 24.04 ARM64 VM in the account's home region. The historically tested size was 1 OCPU, 6 GB RAM and 50 GB disk on VM.Standard.A1.Flex.
4. Add only the owner's SSH public key. Keep the private key encrypted/protected on the administrator's device. Pin the VM host key after an authenticated first connection.
5. Permit outgoing Internet access. Restrict incoming SSH to a managed owner source or a commercially permitted private-access solution. Do not open the OpenClaw Gateway to the public.
6. Apply OS updates, configure automatic security updates, disallow SSH passwords and remote root login where using ordinary public SSH, and verify the network exposure.
7. Create an ordinary non-sudo Linux user such as venture and give it a writable home/workspace without access to owner credentials.

Useful initial host commands:

uname -m                         # Expect aarch64
cat /etc/os-release             # Confirm OS release
free -h
lsblk
sudo ss -tlnp                  # Review listening sockets
sudo adduser venture             # New deployments only
sudo loginctl enable-linger venture

The adduser command is shown for a clean new installation. Do not rerun it on an existing Agatha VM. Do not give the account sudo privileges merely to make integrations easier.

Use the current official installation path, as versions and configuration keys evolve. For a new machine, the documented Linux installer is:

curl -fsSL https://openclaw.ai/install.sh | bash

Review vendor provenance and the current installer instructions before executing any remote script. Install the supported Node.js/runtime dependencies under the intended user. Set up an authenticated, loopback-only Gateway and a persistent user service. In supported versions, the core service operations include:

openclaw gateway install
openclaw gateway start
openclaw doctor --non-interactive
openclaw security audit
systemctl --user status openclaw-gateway.service

The published OpenClaw Oracle guide is a useful starting point, but do not blindly copy its resource limits or its user model. This experiment used a different structure: an owner administrator and a separate, non-sudo agent process, with public administrative SSH carefully limited and Gateway bound to loopback.

References: https://docs.openclaw.ai/install/oracle and https://docs.openclaw.ai/start/getting-started

1. Authenticate using a supported account within the new agent installation, without importing another agent's credentials or turning on unintended usage billing.
2. List models actually authorised for that account; catalogue names alone are not proof of entitlement.
3. Set a strong, suitable default for substantive work; the historical configuration used GPT-6.1 Sol High.
4. Reserve cheaper models for genuinely simple work. Do not silently fall back to a weak model for business judgement.
5. Verify the effective model and reasoning level in a real Gateway inference, not just a configuration file.
6. If using child tasks, test that the result reaches the parent. A successfully completed subtask without delivered findings may be useless.
7. Do not introduce elaborate orchestration merely to switch between High and Extra High reasoning.

Historical identifiers: openai/gpt-6.1-sol, openai/gpt-6-luna, openai/gpt-6-astra. Treat the historical model/version choices as a reproducibility record, not a guarantee that the same identifiers will be offered on every future account.

For a modest Linux VM, use the existing native OpenClaw memory system before adding another database. The experiment used the official llama.cpp provider with local EmbeddingGemma embeddings. An illustrative form of the officially documented setting is:

{
  memory: {
    search: {
      provider: "local",
      fallback: "none",
      local: {
        modelPath: "~/.openclaw/models/llama.cpp/hf_ggml-org_embeddinggemma-300m-qat-Q8_0.gguf"
      }
    }
  }
}

This is a vendor-documented pattern, not a verbatim extract of Agatha's openclaw.json. Verify the model file path, installed plugin and configuration schema for your OpenClaw version.

Minimum memory acceptance tests:

• Write a harmless fact to a persistent Markdown memory file.
• Index it and retrieve it using different wording.
• Restart the Gateway and retrieve it again.
• Retrieve it through the same isolated scheduled-run context used by the future business work.
• Confirm the agent cannot search another operator's private memory.
• Remove test data carefully without corrupting normal session history.

Do not make automatic private-conversation recall a launch blocker if ordinary persistent memory and explicit scheduled-session retrieval genuinely work.

Reference: https://docs.openclaw.ai/concepts/memory-builtin

Connect the dedicated Telegram bot, restrict it to known owner IDs and verify a real round-trip message. Give the agent normal development tools such as Git, GitHub CLI and any verified Cloudflare deployment CLI. Provide dedicated, limited GitHub credentials and a Cloudflare token for the experiment's own zone and deployment projects.

Before launch, require two small, real tests:

GitHub: create a disposable private repository under the agent account, push a harmless commit, read it back and remove the repository. Confirm it cannot access the owner's protected journal.

Cloudflare: deploy a harmless, disposable Worker or test site, inspect the live response and delete the test resource. A DNS-only token is not sufficient evidence that Pages/Workers deployment will work.

A separate business mailbox should also pass send, receive and authentication tests. Keep old or unrelated inboxes out of the operator's permissions. Use the agent's separate Google identity for legitimate platform registration, and let the owner complete verification requirements rather than repeatedly trying to circumvent them.

Create a dedicated payment account/sandbox under a real legal operator. Start in test mode; verify products, prices, Payment Links or Checkout and payment-status retrieval. Keep customer/financial data segregated from other businesses. Once the real offering is known and merchant verification is complete, grant only the live permissions required for legitimate transactions.

The historical live setup permitted Products, Prices and Payment Links Write, with read-only access to balance/payment/refund and dispute information. It prohibited bank changes, payouts, transfers and direct creation of payments. Use provider-side restrictions wherever possible; a script that refuses an action is not a security boundary if the agent can read the underlying API key.

The historical utility was:

/home/venture/bin/agatha-stripe-live

It deliberately offered only one-time GBP products and Payment Links. A replicator should audit whether other API routes can bypass that restriction before claiming there is a hard no-subscriptions guarantee. Avoid making a real test purchase merely to prove a Payment Link works. Test private live object creation and deactivation without treating those objects as revenue.

For low-volume initial service sales, manual confirmation and delivery may be proportionate. Use signed webhooks when automated fulfilment or more complex post-payment actions are introduced. Provide customer terms and legally required disclosures before taking real orders.

Choose one maximum seed contribution. For a faithful replication, use £50. Create a structured request with a unique ID, amount, purpose, expected benefit, conditions and renewal liability. Send it to the owner; require an exact approval reference. The owner makes only the approved amount available.

Never put the owner's bank login or unrestricted card in the agent environment. A Pot-linked card with a limited balance can cap ordinary available card funds, but it is not a substitute for approval matching, checking merchant terms or cancelling subscriptions. The historical setup used a separate Telegram approval workflow rather than building a direct bank API integration.

Record approved, released, spent, remaining and reinvestable funds separately. If no request has been approved, the released amount should remain £0, even when the overall budget available for future requests is £50.

The project's working files evolved to the following practical minimum:

~/.openclaw/workspace/
├── SOUL.md                 # Operator identity and broad mission
├── OPERATING_RULES.md      # Permissions, financial boundaries, requests
├── RESOURCES.md            # Accounts and interfaces, no secret values
├── WORK.md                 # Active objective, progress and next action
├── REQUESTS.md             # Human assistance and funding requests
├── LEDGER.md               # Agent-readable accounting and evidence refs
├── MEMORY.md               # Curated long-term knowledge
└── memory/
    └── YYYY-MM-DD.md       # Normal dated notes

Do not create parallel PLAYBOOK, ARSENAL, DEFCON, GRAVEYARD and workflow documents containing contradictory instructions merely because they sound useful. Agatha's DEFCON state was an owner-controlled runtime input and financial scoreboard, not a requirement to proliferate documents.

A useful minimal WORK.md shape is:

# Active Work

Current objective:
Status: IN_PROGRESS / BLOCKED / READY_TO_TEST
Last verified external result:
Next executable action:
Current obstacle:
Alternatives already tried:
Owner assistance requested:
Relevant source files/links:
Last updated (UTC):

The critical field is next executable action. A work file that merely says “await owner response” creates passive sessions. If there is independent useful work available, record it explicitly.

First prove the scheduler with a harmless timed job. Keep the genuine business work disabled during installation. Once ready, enable one substantive native scheduled job, initially at a four-hour cadence, with ordinary start/finish and error records. Avoid treating a default heartbeat as a work queue: heartbeats are monitoring events; substantive recurring work needs its own automation.

The exported launch used a job-specific enabled/disabled status and checked recent runs. The historically used CLI included:

openclaw cron list --all
openclaw cron enable <job-id>
openclaw cron runs <job-id> --limit 3

CLI names and arguments can change; current OpenClaw documentation also uses openclaw automations. Check help before copying launch commands. Do not enable every scheduled job indiscriminately. Keep a distinction between monitoring, commercial work and owner-protected services. Use one simple execution lock to prevent duplicate overlapping commercial sessions.

Reference: https://docs.openclaw.ai/automation and https://docs.openclaw.ai/heartbeat

A minimal Observer needs no dashboard and no permanently running second AI agent. It should periodically archive relevant session/tool information, identify external outcomes, preserve evidence references, redact secrets and publish a dated Markdown report to an owner-controlled location. The agent should not have permission to rewrite or delete the historical reports.

A report should distinguish:

Event type:        research / code / deployment / outreach / payment / request
When:              precise timestamp and timezone
Action:            concrete observable event
Source:            session, commit, public URL or provider receipt
Claim status:      verified / agent-reported / unverified
Commercial stage:  preparation / exposure / buyer signal / proposal / order / profit
Current blocker:   if any
Next work:         source from WORK.md, not invented by Observer

For publication to GitHub, design safe synchronisation when the owner also adds commits. Verify the report can be read back and that an ordinary owner-side commit does not cause a hard SHA-divergence failure. Keep raw sensitive transcripts off GitHub. A ChatGPT daily review can then read the journal and assess progress without another model service on the Oracle VM.

The optional local dashboard can be added after a useful journal exists. If added, bind to loopback, reject write operations and prefer one consolidated SSH snapshot over many parallel SSH commands on a small VM.

A reliable STOP operation must do more than temporarily stop a restart-on-failure service. It should prevent scheduled work and service relaunch until the owner consciously resumes it. For this experiment, the hold belonged to the host administrator and was inaccessible to venture.

Test all four conditions:

1. STOP leaves no active agent processes and blocks new scheduled execution.
2. A normal reboot while STOP is active does not revive the agent.
3. STATUS reports UNKNOWN when it cannot reach the server, not a false STOPPED.
4. A deliberate RESUME restores the previous service state without fabricating new jobs or funding.

Keep a separate cloud-console stop route if network SSH fails. The emergency hold stops the operator, not automatically every Cloudflare website, third-party subscription or public integration the operator has already created.

Before Day 1, create an encrypted backup with critical configuration, memory, work state, approved schedules and recovery metadata. Verify its checksum, perform a staging restore, copy it to an independent owner-controlled location and store the decryption passphrase separately. Preserve the administrator SSH key through a different secure backup method.

Freeze and record the launch baseline: date/time, model, reasoning settings, mission, domains, accounts, agent version, scheduler, money released, pre-existing revenue, evidence locations and any open limitations. That snapshot makes later changes scientifically interpretable.