AGATHA

Building, launching and observing an autonomous AI business operator

An Oracle Cloud and OpenClaw implementation case study, 3–11 November 2026

Document type: Technical case study and practical replication guide
Source: Supplied full project-conversation export, dated 11 November 2026
Evidence cut-off: 11 November 2026, approximately 21:13 GMT
Experiment launched: 6 November 2026 at 17:20:39 GMT
Status at cut-off: Autonomous operation active; one website and two unvalidated paid offers; live Stripe Payment Link creation technically verified; no verified customer payment or profit flag

Scope. This paper starts with the assets allocated to the experiment and the decision to provision a dedicated Oracle server. It excludes the earlier discussions about other agents, the former website and rejected infrastructure approaches. It records the actual implementation sequence, subsequent changes, test results, failures and lessons, and then provides a practical route for recreating a comparable experiment. All credentials, private IP allowlist values, SSH keys, personal contact information and account-recovery details are deliberately omitted.

Evidence convention. “Verified” in the historical narrative means that the supplied conversation records a concrete check or test at that time, often performed by Codex or by a subsequent direct inspection. This paper does not itself reauthenticate to the live Oracle, Stripe, Gmail or private GitHub accounts. An implementation instruction, screenshot interpretation or planned change is not silently promoted into proof of completion. Where an exact source configuration or command was not included in the export, the recreation guide labels its replacement as an illustrative implementation pattern.

Contents

• Executive summary
• Part I: Starting conditions and target architecture
• Part II: Actual installation and integration history
• Part III: Financial controls, continuity, observation and recovery
• Part IV: Launch and the first six days of operation
• Part V: Recreating the experiment
• Part VI: Methodological lessons and evaluation
• Sources and reproducibility notes

Executive summary

Agatha Whitmore was configured as a distinct, persistent AI operator tasked with developing a real online business. She received a domain, separate operational accounts, research and development tools, communications, access to a payment sandbox and later restricted live payment capabilities, and the ability to request up to £50 of owner-funded seed capital. She did not receive a predetermined market, product, pricing strategy or list of business ideas.

Her operating environment was an Oracle Cloud Always Free ARM virtual machine, running Ubuntu 24.04.5, OpenClaw 2026.10.9, and an independent, non-administrator Linux user. Her main model was GPT-6.1 Sol with High reasoning, using ChatGPT/Codex OAuth. The one-off first commercial session used GPT-6 Astra at Extra High reasoning. Local hybrid memory combined Markdown, SQLite keyword search and EmbeddingGemma 300M embeddings. A native OpenClaw schedule created recurring business sessions, while owner-controlled emergency scripts, a separate audit journal, backups and a read-only dashboard provided supervision without turning the agent into a conventional human-directed employee.

The experiment formally began on 6 November 2026. In her opening session, Agatha independently selected a website migration niche, built and deployed a free redirect-map checker, and proposed a £79 manual review service. She later added a £49 supplier-to-Shopify CSV preparation service to the same website. She researched potential customers, created specialised public profiles, secured several directory listings and interacted with other technical communities.

The first operational problem was not technical downtime. Although the scheduler and memory worked, Agatha fell into a pattern of short sessions repeatedly checking an unresolved legal-identity and outreach dependency. A 9 November intervention introduced DEFCON 1, a more demanding work runner, two-hour sessions and independently scored profit milestones of £10, £50 and £100 cumulative net operating profit. Recorded activity increased substantially afterwards, but buyer contact and revenue did not yet follow.

By the evening of 11 November, the evidence supported a narrower conclusion than “an autonomous business is profitable”: one deployed website; two paid service offers; several public listings and technical interactions; no verified qualified buyer, paid order or positive net profit. The experiment did demonstrate a functioning autonomous execution environment, the limits of purely instructional perseverance, and the difference between increased agent activity and meaningful commercial validation. Its next phase, planned for 12–18 November, was directed towards verifiable customer contact, with the actual commercial choices still left to Agatha.

The implementation in one view

Part I. Starting conditions and target architecture

1. What Agatha was given

The experiment's initial business asset was the-molt.com, an existing domain with no active new-business website when Agatha was introduced. The domain was registered at Fasthosts, with DNS in Agatha's new Cloudflare Free account. Its assigned authoritative nameservers were:

jade.ns.cloudflare.com
quentin.ns.cloudflare.com

The domain was due to expire on 9 March 2027, with automatic renewal disabled. The owner set a business survival condition: renewal should be financed from earned venture profit, not by preserving part of the original £50 seed-capital allowance. 23 February 2027 was the internal funding target, allowing time before expiry.

The agent also received or was prepared to receive:

• A dedicated Gmail identity, Agatha Whitmore Dev, used for registration, Google sign-in and authorised email access.
• A separate GitHub account, later verified as agathadev-stack.
• A separate Cloudflare account holding the domain and deployment permissions.
• A neutral domain mailbox, hello@the-molt.com, provided through the existing Fasthosts/Livemail email service.
• An isolated Oracle-hosted OpenClaw installation.
• A private Telegram channel for conversations, approval requests and exceptions.
• Working research tools, coding tools, a browser and the ability to adopt additional reputable skills.
• Stripe sandbox capabilities, later complemented by restricted live payment tools.
• An opportunity to request a maximum of £50 from the owner, in individually approved amounts. The maximum was available capital, not cash pre-transferred to Agatha.

The deliberately absent input was equally important: no business niche, product catalogue, social-media launch plan, target buyer segment or commercial strategy. Any resulting website and offer would therefore be chosen by the agent, within its permissions.

The formal experiment was planned for 60 days, from 6 November 2026. If counting launch day as Day 1, Day 60 falls on 4 January 2027. The domain's March expiry created a separate, later survival deadline.

2. Trust boundaries

Agatha was not given unrestricted control of the infrastructure she lived on. The design distinguished four separate roles:

1. Owner/administrator: controls Oracle tenancy, legal trading identity, banking, payout details, SSH recovery, system-level overrides and the emergency stop.
2. Agatha/operator: controls her allocated workspace, software, business decisions and explicitly scoped business service credentials.
3. Observer/recorder: reads operational evidence and publishes protected, sanitised records that Agatha cannot retroactively alter.
4. Independent reviewer: reads the private journal, interprets the evidence and reports to the owner, without automatically changing Agatha's instructions.

The distinction matters because workspace isolation is weaker than account or operating-system isolation. Giving the agent a separate prompt or memory directory would not itself prevent code execution from reaching owner secrets.

Simplified system architecture

flowchart TB
    O["Human owner\nOracle account, money, recovery"]
    V["Oracle VM: venture-01\nUbuntu ARM64"]
    A["Agatha / OpenClaw\nnon-sudo venture user"]
    M["Native memory\nMarkdown + SQLite + EmbeddingGemma"]
    C["Business accounts\nGitHub / Cloudflare / email / Stripe"]
    D["Doppler agatha/dev\nscoped service credentials"]
    T["Telegram\nprivate owner messages"]
    J["Protected Observer\nactivity evidence and reports"]
    G["Private owner GitHub\nagatha-journal"]
    R["Daily ChatGPT Review"]
    W["Local read-only dashboard\n127.0.0.1:8768"]
    K["Owner-only STOP / STATUS / RESUME\nand Oracle Console Stop"]
    O -->|provisions and administers| V
    V --> A
    A <--> M
    A -->|scoped access| C
    A -->|reads limited secrets| D
    A <--> T
    V --> J
    J --> G
    G --> R
    G --> W
    V -->|read-only SSH snapshot| W
    O --> K
    K -->|administrator control| V

Diagram note: the source repository is owner-controlled private journal; the shorthand label in the diagram refers to that repository. This is a logical overview, not a complete network-security diagram.

Three non-negotiable boundaries

Infrastructure: The Oracle cloud administrator login remained in the owner's separate Google identity, not Agatha's Gmail. The venture Linux account did not receive sudo or the owner's SSH private key. OpenClaw's Gateway was bound to loopback, not exposed as a public management endpoint.

Money: The owner controlled all banking, external funding, refunds and payouts. Agatha could propose an expense and, later, create payment links using a restricted Stripe credential; neither gave her authority to take funds out of the owner's bank account or change the Stripe payout destination.

Evidence: Agatha controlled her own work notes, which are useful but not independent evidence. The separate recorder, Stripe records, Git history, Cloudflare deployments and public websites provided stronger corroboration. A private journal remained owner-controlled.

Part II. Actual installation and integration history

3. Provisioning the Oracle computer, 2–3 November

The chosen hosting platform was Oracle Cloud Always Free, in UK South (London). The Oracle account was opened under the owner's personal administrative identity, rather than the agent's Gmail. This was deliberate: access to Gmail must not automatically imply access to the server tenancy or billing.

The provisioned machine was:

The installation used a dedicated VCN/network arrangement and an owner-controlled SSH key. Public incoming SSH was limited at Oracle's security-list level to a verified owner source address. Password-based SSH and direct remote root login were disabled. Outbound connectivity remained available for package installation, model access and authorised third-party services. The OpenClaw management port was not opened to the public.

The instance was installed in AD-1 only after an AD-2 capacity failure, a useful practical note for anyone recreating this on an Always Free account. A lack of free ARM capacity is not a reason to substitute a billable VM without explicit authorisation.

The reported validation covered SSH authentication, pinned host-key checking, Ubuntu/ARM64 identity, CPU/RAM/disk allocation, outbound connectivity, firewall exposure, denied non-sudo privilege, denied access to instance metadata from venture, Gateway loopback binding, process restart and an actual reboot. The OpenClaw security audit reported zero critical findings and two warnings; those warnings were recorded in the original private infrastructure handover.

Important reproducibility check: Oracle's authoritative resource documentation at the time of this paper describes an Always Free ARM allowance equivalent to 2 OCPUs and 12 GB RAM, plus 200 GB combined boot/block storage. Some third-party or application-specific installation pages still mention older 4 OCPU / 24 GB figures. Check Oracle's own live limits before provisioning or resizing. Oracle also reserves the right to reclaim idle Always Free instances. Ordinary daily work does not guarantee protection from reclamation.

Reference: https://docs.oracle.com/en-us/iaas/Content/FreeTier/freetier_topic-Always_Free_Resources.htm

4. Installing OpenClaw under a restricted account

The runtime installed was OpenClaw 2026.10.9, using an independent agent workspace. The operating account was the non-sudo Linux user venture, not the Oracle administrator. No other agent's memory, browser sessions, GitHub credentials or business documents were imported.

OpenClaw ran as an enabled systemd user service, with restart-on-failure behaviour and user lingering, allowing it to remain active after SSH logout and to start again after reboot. The Gateway was authenticated and bound to the server's loopback interface. Its administrative UI could be reached through a protected SSH tunnel, not directly from the public internet.

The account had ordinary ability to create files, use Git and development tools, run Chromium, install suitable user-scoped packages and later add reputable skills. It did not have unrestricted sudo or permission to administer Oracle billing, change owner SSH credentials or disable the emergency controls.

The source report also records a successful ARM64 Chromium launch with sandboxing enabled. That validation matters: autonomous agents that can code but cannot use a browser or authenticate into necessary services can become operationally blocked before commercial work begins.

Initial implementation intentionally did not activate the commercial mission. The runtime was first tested as infrastructure, then authenticated, then connected to communications and business tools, and only later given its autonomous work schedule.

Operational checkpoints for a similar setup

These are general checks, not an exact recreation of the original Codex shell transcript:

# Run as the administrative user when checking host state.
uname -m
lsb_release -a
free -h
df -h
sudo ss -tlnp
sudo loginctl show-user venture -p Linger

# Run within venture's own authorised user session.
openclaw --version
openclaw doctor --non-interactive
openclaw security audit
systemctl --user status openclaw-gateway.service

The expected outcome is an ARM64 Ubuntu system, a working authenticated Gateway, a persistent service, no unintended public OpenClaw listener and no elevated privileges for the agent account. Depending on the installed OpenClaw release, consult current CLI help before using commands from the November 2026 setup.

5. Model authentication and model-selection changes

The model connection used ChatGPT/Codex OAuth, independently authenticated on the new Oracle installation. It did not import another agent's local OAuth files and did not configure a separately billed OpenAI API key. Authentication and model calls were tested through the running Gateway.

The final pre-launch model policy was:

The first recommendation had been to use Sol Medium as the default. Before launch, the owner deliberately changed this to Sol High because Agatha was expected to make substantive market, product, coding and commercial judgements. Extra High was available when she chose to delegate a difficult task. Fast processing was disabled. Luna Low was reserved for uncomplicated tasks, not market analysis or pricing decisions.

There was a subtle configuration problem during installation: a global/per-agent default could override a model-specific Low setting. The team tested the effective session and request settings, not just the written configuration. A Sol Extra High child task initially completed without confirmed result delivery; a later normal parent-child test demonstrated that Agatha actually received and used the child result.

The opening run used the higher-capability Astra Extra High model as a single recorded exception. All standing commercial runs remained assigned to Sol High. This distinction is necessary when comparing the first decisions with later behaviour.

6. Memory: from keyword-only to local hybrid search

During initial installation, automatic scheduling was temporarily disabled and memory retrieval was set to keyword-only so no paid embedding provider would be required. These were sensible pre-launch simplifications, but the user identified two potential risks: Agatha might never wake herself again, and keyword retrieval might fail to reconnect related business evidence expressed in different terms.

The scheduler was tested and restored without enabling commercial work. For memory, the team considered QMD but adopted OpenClaw's supported native built-in memory engine, rather than installing an additional QMD, Ollama, ChromaDB or external vector database stack.

The verified memory architecture was:

• Native OpenClaw persistent memory, including ordinary Markdown workspace notes.
• SQLite-backed keyword indexing and vector retrieval.
• Hybrid search combining exact-term and semantic matching.
• The official llama.cpp provider, using EmbeddingGemma 300M locally.
• Private memory and session-state separation within the dedicated agent installation.
• No paid embedding API.

Specific initial performance observations were approximately 7.2 seconds for a Gateway semantic search, 3.8 seconds for a warm keyword search and 27–45 seconds for cold CLI searches. A measured embedding process used around 700 MiB RSS, with roughly 3.9 GiB RAM available in one sample. These are historical measurements, not universal benchmarks.

A paraphrased fact was successfully retrieved without its original keywords. Persistence survived a Gateway restart and separate CLI process. Later, a separate scheduled agent session correctly used memory_search and memory_get to retrieve a fact previously written to Markdown memory. That was the decisive test for autonomous work continuation.

By contrast, automatic recall of an unrelated fact between two genuinely distinct private conversations was not established. Telegram /new retained a durable session identifier in one test, and another recall attempt returned UNKNOWN. The installation therefore kept explicit durable memory retrieval as the reliable operating method. It did not add a second memory framework just to make the more ambitious feature pass.

This is one of the case study's central engineering lessons: persistent storage, a working search index and automatic conversational recall are separate capabilities. A scheduled business agent must explicitly retrieve its active work context instead of assuming interactive-chat recall will happen automatically.

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

7. Telegram communications and agent autonomy

Agatha's Telegram bot was registered as dedicated private Telegram bot. It used polling, not a public webhook. The integration was restricted to the owner's verified numeric Telegram ID for private direct messages, with groups disabled. The records confirm that a harmless message produced a real model reply.

The channel had two purposes: normal dialogue with the agent and requests requiring an authorised person. Agatha could ask for account registration, CAPTCHA completion, identity checks, specific business information, OAuth consent and budget approval rather than silently abandon a viable idea.

A separate, owner-controlled Telegram approval mechanism was later introduced for capital requests. It was deliberately kept separate from Agatha's ordinary bot and operational credentials. Synthetic approval tests demonstrated matching of request IDs and amounts without transferring real funds.

Telegram did not contain Oracle administration credentials or a means of overriding the emergency stop.

8. Emergency STOP, STATUS and RESUME

Before Agatha received substantive business permissions, three Windows desktop controls were created:

• STOP AGATHA: establishes a persistent owner-only emergency hold, prevents the service from immediately restarting and terminates active venture processes.
• STATUS AGATHA: checks reachability, hold state, Gateway status, agent processes and scheduler. A connection error is reported as UNKNOWN, never as proof the agent is stopped.
• RESUME AGATHA: deliberately releases the hold, restores prior settings and restarts the Gateway.

A normal systemctl stop was insufficient because the Gateway had Restart=always and user lingering. The implemented control combined a root-owned hold record, a persistent mask on the user's service manager, temporary account expiry and process termination. The venture account could not remove the hold.

The controls passed a live STOP/RESUME cycle, with zero remaining venture processes, a blocked restart attempt and later restored operation. A second test demonstrated that the hold survived a normal Oracle VM reboot and remained in effect until deliberate RESUME. Configuration checksums and the state database were also checked after the lifecycle test.

An independent fallback was retained: the owner could sign in to Oracle Cloud Console and stop or force-stop the VM if SSH was inaccessible. This fallback was documented but not physically tested in the exported record, partly because stopping an Always Free instance can create restart-capacity uncertainty.

Access-route change after deployment

The original desktop scripts used public SSH restricted to a changing owner IP. When the public address changed, multiple Oracle /32 rules accumulated and access reliability became an issue. A separate owner-controlled Tailscale network was subsequently installed, with the Oracle server shared into the owner's Windows environment under machine-sharing quarantine. The agent account was blocked from initiating connections through tailscale0, and a connection attempt to the owner's Windows Tailscale address was rejected.

This made the emergency controls work independently of the owner's changing public IP. However, a separate compliance issue emerged: Tailscale's Personal free plan was identified as non-commercial. Before business launch, the owner chose the tested public-SSH route as the default for the desktop emergency shortcuts. The Tailscale arrangement remained a historically tested access path, not the recommended unqualified commercial solution.

The resulting limitation was explicit: public SSH works only while Oracle's allowlist contains the owner's current public address. If that fails during an emergency, use Oracle's independent Console control. A person recreating this should select a commercially permitted, reliable administrative-access method from the beginning rather than silently relying on a personal-only service plan.

Reference: https://tailscale.com/pricing

9. Credentials, Gmail and business email

The project reused an existing Doppler workspace openclaw_agent, project agatha, configuration dev. It already held four research-service keys:

BRAVE_API_KEY
FIRECRAWL_API_KEY
GEMINI_API_KEY
TAVILY_API_KEY

The owner reported that these particular accounts were on free tiers which stopped usage rather than accruing charges when exhausted. The implementation did not re-litigate that accepted provider setup. The project added restricted business credentials as needed. A read-only Doppler service token was scoped to Agatha's own configuration; Oracle administration, banking, backup-recovery and owner SSH secrets remained outside it.

The first Windows-to-Oracle token-transfer utility failed because shell quoting damaged a Python command passed through SSH. The error was repaired by moving towards a safer script-and-standard-input transfer method. A disposable-token test passed before the actual token was transferred; subsequent Doppler authentication and restricted Stripe sandbox access were reported verified. This was a real implementation defect and fix, not a failure of the credential itself.

Doppler separated the credentials available to Agatha from unrelated accounts, but it did not make an accessible secret immune to Agatha's code. An agent that can execute arbitrary commands as venture can potentially read the restricted service token and use whatever provider privileges it unlocks. Provider-side permissions therefore remain essential.

Email setup

The domain's public address became hello@the-molt.com, using existing Fasthosts/Livemail infrastructure. IMAP and SMTP sending/receiving were tested through the configured credentials. Agatha's dedicated Gmail had separate programmatic access, with an app password created through Google's legitimate account flow and saved in Doppler rather than placed in a prompt.

The source describes two earlier empty domain mailboxes, editor@ and clawprize@, as approved for retirement. The exported evidence does not conclusively demonstrate the final deletion state of both, so their removal must not be assumed in a clean-room recreation.

DNS migration preserved nine mail and verification records: MX, SPF, DMARC, autodiscover, four Livemail DKIM CNAMEs and Google verification. An imported autodiscover CNAME was corrected from proxied to DNS-only, and the four missing DKIM CNAMEs were restored. DNS integrity was checked, but earlier reports stated that provider-side DKIM signing had been inactive. The existence of DNS records alone was not proof of correctly signed outgoing email.

For the new system, the useful principle is simple: make a separate mailbox that actually sends and receives, test it, protect it, and do not give the agent access to unrelated historical correspondence.

10. GitHub, Cloudflare and the first deployment permissions

Agatha's own GitHub identity was connected by registering a dedicated SSH public authentication key from the Oracle server. A disposable private repository was created, a harmless commit was pushed and read back, and the test repository was removed. The owner-controlled private journal was separately tested to ensure Agatha could not access or rewrite it.

Cloudflare received a token scoped to the experimental domain. One credential was stored under the Doppler name:

CLOUDFLARE_DOMAIN_TOKEN

Its initial documented abilities were Zone Read and DNS Write for the-molt.com only. Those permissions alone do not grant Workers or Pages deployment access, so additional limited deployment capabilities were configured and tested. A disposable Cloudflare Worker returned the expected live response and was then removed. No commercial website was published during that pre-launch test.

When the experiment began, Agatha subsequently developed and deployed her chosen website through Cloudflare Pages. The principal working project was called redirect-check. The site's normal Cloudflare deployment hostname and its custom domain referred to the same website, not two independent sites.

These checks establish a practical pattern for replication: first verify that the agent can push a real commit and deploy a disposable service, then delete disposable resources and only afterwards authorise the agent to choose what to build.

11. Stripe, from isolated sandbox to restricted live payments

The payment environment evolved in two phases.

11.1 Pre-launch Stripe sandbox

The owner established a separate Stripe account/sandbox for Agatha, distinct from Studio Dali's live account. This was necessary to prevent accidental access to another business's customers, charges and products.

A restricted sandbox key was stored in Doppler as:

STRIPE_TEST_RESTRICTED_KEY

The general sandbox toolkit could create products, prices, checkouts and payment links, and inspect test transactions. Stripe sandbox flow tests passed. During the setup, a more powerful sandbox key appeared in a computer-control transcript. Codex rotated it after verifying the new restricted key, and the former key's invalidation was reported verified. The lesson is to treat even test credentials as secrets, particularly when automated tools take browser screenshots or print detailed logs.

Live Stripe payments remained unconfigured at the formal launch, because the agent had not yet chosen an actual offering and the owner had not completed genuine merchant onboarding.

11.2 Live Stripe activation, 11 November

After six days without verified customer payments, the owner completed the dedicated Stripe account's live onboarding using genuine UK sole-trader identity information. The public profile was changed to The Molt, with @the_molt as the public handle and hello@the-molt.com as the business email. The operational merchant account stayed distinct from the unrelated business account.

A restricted agent key was configured, saved as:

STRIPE_LIVE_RESTRICTED_KEY

Its historical permission report recorded:

The server-side utility /home/venture/bin/agatha-stripe-live authenticated against the dedicated live account and created a live product, a one-time GBP price and two private live Payment Links. Those objects were deactivated, and their inactive status was checked. No customer card was charged, no live sale was claimed and the sandbox interface remained intact.

The utility itself only accepts one-time GBP prices. However, venture can retrieve the restricted key directly, and broader Price/Payment Link permissions might permit recurring links outside the utility. No subscription permission was intentionally granted, but a hard provider-level guarantee against that indirect route was not verified. Direct payout, transfer and PaymentIntent creation test operations were denied; an attempted refund test returned 404 for a nonexistent item and did not conclusively prove that all refund attempts would be forbidden. The documented Stripe access was read-only for refunds.

The agent's rules expressly prohibited creating recurring payment commitments and performing unauthorised financial actions. This was a pragmatic, documented limitation rather than an excuse to rebuild the whole payment system.

Technical readiness did not equal commercial clearance. Real orders still required appropriate trading-identity, geographic-address, contact, terms and customer disclosures. A payment link is not a payment, a payment is not necessarily settled cash, and settled revenue is not net profit. Signed webhooks would be appropriate for more sophisticated automated fulfilment, but they were not built for this low-volume first-sale stage.

By the end of the exported record, Agatha's RESOURCES.md, REQUESTS.md and WORK.md had been corrected to acknowledge that restricted live Payment Links were available; some of these files had previously continued to call checkout “sandbox-only” after the technical work was finished. This mattered because stale notes could cause the agent to remain blocked by a problem already solved.

References: https://docs.stripe.com/keys and https://docs.stripe.com/checkout/fulfillment

Part III. Financial controls, continuity, observation and recovery

12. Capital, profit accounting and the request mechanism

The owner-funded allowance was £50 in total, not £50 per week, month or business idea. It began with £0 released. Agatha could make a reasoned request for any available portion of the allowance, but a human had to approve the exact request and make that amount available. Reinvestment of genuine, cleared business earnings was permitted subject to liabilities and financial reserves.

A Monzo Pot and virtual card were considered as the practical spending mechanism. The owner proposed retaining the full reserve in an owner-controlled Pot and transferring only an approved amount to the card-linked spending Pot. That design gives the card access only to the amount released, rather than the whole remaining budget. The exported record establishes the policy and a tested approval workflow, not an actual £50 bank transfer or proof that a virtual card was issued.

The eventual pre-launch capital-request system included:

• A persistent REQUESTS.md with unique request IDs, purposes, amounts, approval state and blockers.
• An owner-controlled Telegram approval route separate from Agatha's normal bot.
• Exact ID-and-amount matching, rather than accepting an ambiguous “approved” message.
• A durable approval register and an agent-readable financial record.
• Tests against duplicate or mismatched approvals using disposable records, not real money.
• A rule that unresolved registration, KYC and payment requests should not automatically stop unrelated productive work.

A request might concern a paid subscription, an account registration, a platform verification, a necessary licence or a service address. Where a provider required genuinely human identity verification, the owner would enter those details into the provider's own interface, not disclose them in the agent's ordinary chat or journal.

Financial definitions

The intended accounting day was 00:00–23:59 Europe/London. The system was expected to distinguish at least the following:

The guiding accounting relationship was:

Daily operating profit
  = verified net revenue
  + other verified operating income
  - payment-processing fees
  - actual operating expenses
  - other applicable operating costs

Seed funding is capital supplied, not sales revenue. A test checkout or invoice sent is not a real customer payment. A successful API response is not proof of settlement. A daily failed-profit result means that the objective was not met; it does not force a strategic pivot.

The project also distinguished the actual cash-flow view from a fully costed view that might include shared ChatGPT subscriptions or donated computing resources. The transcript does not contain an independently reconciled total for every such cost. Therefore it would be unsound to publish a precise cumulative profit or loss figure for 11 November.

Profit flags introduced after launch

On 9 November the owner added objective monetary flags:

The flags were tracked in an owner-controlled, root-owned scoreboard, not accepted solely from Agatha's LEDGER.md. At the evidence cut-off all three were unclaimed. This matters because outcome-focused prompts can otherwise encourage an agent to mistake sales leads, fabricated transactions or revenue before expenses for success.

13. The first Continuity Loop

A recurring concern was that an autonomous agent might stop at the first ordinary obstacle. The project therefore created a minimal persistence mechanism instead of relying exclusively on a prompt saying “keep trying”.

WORK.md became the active checkpoint. It recorded the current objective, what had actually happened, obstacles, attempts already made, requests for help, related documents and the next executable action. Each substantive scheduled session was supposed to read this checkpoint, retrieve relevant memory, continue an unfinished task or choose a new productive task, and update the checkpoint before ending.

The initial continuity framework comprised:

1. Persistent work state: an ordinary Markdown checkpoint that survives context changes, session termination and Gateway restarts.
2. Obstacle recovery: distinguish a temporary failure, missing technical capability, authentication requirement, genuine strategic weakness and prohibited action. Use bounded retries and alternative methods rather than endlessly repeating the same failed call.
3. Native scheduled work: a substantive OpenClaw job initially running approximately every four hours on Sol High; the normal 30-minute heartbeat remained disabled.
4. Independent continuity check: a small, non-AI process looking for failed work, stale checkpoints and repeated failure to advance an objective.
5. Human assistance route: add requests to REQUESTS.md, notify the owner when necessary and continue with something else where lawful and feasible.

A synthetic recovery test before launch reportedly demonstrated that the agent could handle a recoverable tool failure, keep the objective in its work file and resume across separate scheduled executions. Native scheduler tests also confirmed that isolated work could start without a human opening a conversation.

What the initial design missed

The independent checker mainly compared a fingerprint of text fields in WORK.md. If Agatha changed the text, it could interpret that as progress even if no external outcome had changed. That weakness surfaced by Day 4: Agatha could update her notes, check an inbox and finish with a “successful” scheduled run without advancing the business.

The important distinction for replication is:

An agent successfully completing a scheduled session is not the same as an agent successfully advancing its objective.

The later DEFCON version required more tangible commercial work, but neither version can guarantee entrepreneurial skill. Continuity mechanisms should preserve unfinished work and improve the likelihood of useful recovery, not award credit for the existence of a new log entry.

14. Independent Activity Journal and daily review

The observation goal was unusual but important: the owner wanted to know what Agatha did without asking her to produce a personal report every day. Repeated reporting requests were considered a possible influence on the experiment itself.

The implemented observation chain used:

Oracle evidence: OpenClaw sessions, recorded tool activity, operational logs, git/deployment evidence and Agatha's ordinary work notes. Detailed evidence remained protected; the agent could not rewrite the owner-controlled record.

Private GitHub publication: a separate repository, owner-controlled private journal (owner-private evidence), owned by the human. The Observer published filtered, sanitised Markdown material. The agent's dedicated GitHub account did not have write access to that repository. Sensitive transcripts, passwords, personal data and card details were excluded from readable reports.

Independent ChatGPT review: a recurring task named Agatha Daily Review was created for 09:30 Europe/London, starting 7 November. It read the private journal, compared dates and assessed execution, resilience, commercial evidence, risks and owner intervention needs. It did not automatically send recommendations to Agatha or rewrite her operating instructions.

Local dashboard: after launch, a read-only Agatha Observer interface was built on the owner's Windows PC, accessible at http://127.0.0.1:8768/ on that computer. It combined the private journal with read-only Oracle status and work-state snapshots. It displayed a timeline, current objective, blocked items, financial information, scheduled work and later a decision-trail view. The service listened on loopback and rejected write requests.

The original plan included a single daily Luna Low AI-generated summary on Oracle. During a subsequent scope review, this was simplified: the Oracle Observer would publish useful factual checkpoints, and the separate ChatGPT Daily Review would produce the narrative interpretation. That eliminated a duplicate model-based summarisation layer.

Seeing decisions, not inaccessible internal reasoning

The owner also wanted to see why Agatha selected an opportunity, including abandoned alternatives. OpenClaw records exposed timestamped messages, tool calls and decision documents, but they did not provide a guaranteed complete record of internal model reasoning.

The dashboard was therefore extended with a Decision Trail, drawing from Agatha's actual recorded research, rejected alternatives and the first commercial session's tool events. It deliberately did not invent hidden reasoning or claim that a first textual mention was the precise instant an idea arose.

Observer failure and repair

The Observer initially failed to publish daily reports on 7, 8 and 9 November, even while Agatha's own scheduled jobs continued running. The error was:

Journal checkout and remote diverged

Two legitimate owner-side commits had been added directly to the private GitHub journal, leaving the Oracle checkout behind. The publisher had been written to refuse publication unless its local and remote Git SHA values matched exactly. This was too brittle for a repository also updated by its owner.

The diagnosis established that the local checkout was a clean ancestor of the remote branch. Codex safely fast-forwarded the checkout and recovered the existing local daily reports for 6, 7 and 8 November. The publication process was made less brittle so ordinary owner commits would not break the daily journal again.

Replication lesson: design an automated Git publisher for concurrent legitimate owner-side commits, not just a repository that never changes except through one script. Otherwise a seemingly healthy timer can conceal days of missing reports.

Dashboard incidents and repairs

Two smaller monitoring bugs were fixed after launch:

• The timeline interpreted the word locked in a normal “starting locked work session” message as evidence of “Concurrent work prevented”. Scheduler receipts showed the work had completed. The dashboard's classification rule was corrected.
• The dashboard initially launched seven separate SSH sessions per refresh against a small 1-OCPU VM, and some timed out. On 11 November it was changed to obtain one consolidated, read-only SSH snapshot. The snapshot took about 0.8 seconds in one direct test, restoring a reliable live status display.

These incidents did not demonstrate that Agatha had stopped. They demonstrated that monitoring infrastructure must be evaluated independently of the system being monitored.

15. Backups, restore checks and owner recovery

The original installation created at least one backup on the VM itself. That did not protect against complete loss of the instance or boot disk. The subsequent preparation process created a separate encrypted off-server archive of important OpenClaw configuration, memory, state and recovery information, using an owner-held passphrase. A protected copy remained on the owner's Windows computer.

The final pre-launch encrypted archive was recorded as:

Format:         .tar.gz.gpg
Size:           314,755,061 bytes
SHA-256: independently verified; omitted from public edition
GitHub release: private recovery asset (identifier withheld)
Repository: owner-controlled (private)

A reported authenticated restore check recovered WORK.md and the principal OpenClaw databases into an isolated location, without replacing the production system. Later, the owner manually uploaded the encrypted archive as a private GitHub release asset. The recorded GitHub SHA-256 matched the local checksum. The passphrase was deliberately kept in an owner-only password manager, not in Agatha's Doppler project. The owner's administrative SSH key required its own separate backup because it was not included in the archive.

Oracle's documentation also provides an Always Free volume-backup allowance. The project requested an Oracle boot-volume backup, but the supplied end-to-end evidence does not identify a successful Oracle snapshot and verified snapshot ID. Therefore this paper claims only the encrypted off-server archive and the tested private release, not a confirmed Oracle-managed boot-volume snapshot.

Recovery boundaries

• A backup on the same VM disk is not an off-server backup.
• An encrypted archive uploaded to a private repository still contains sensitive material; repository access must remain tightly restricted.
• The person holding the backup must also hold a verified way to decrypt it and a separate administrative SSH/recovery route.
• Restore should be tested into a temporary directory, not directly over a running production agent.
• Recovery should preserve the owner's STOP/hold state so restoration does not accidentally reactivate an intentionally stopped agent.

Part IV. Launch and the first six days of operation

16. The formal launch, 6 November 2026

The owner authorised launch after the commercial infrastructure and emergency controls passed preflight checks. The recorded baseline was:

The normal recurring Sol High job was enabled alongside a one-off Astra Extra High opening session. An early scheduled attempt declined to start because Astra held the same work lock. This was expected concurrency protection, not evidence of a failed business operation. The active process was checked and confirmed to use Astra with xhigh.

The private owner journal preserved the baseline:

Owner-private GitHub evidence (not publicly accessible)

Agatha could then research, code, publish, communicate, request assistance and make commercial decisions independently within her authority.

17. The first commercial decision

In the initial session on 6 November, Agatha researched a number of technical service possibilities. The decision documents record these alternatives:

Her stated insight was that a free redirect validator was not inherently a strong paid product. She instead proposed a £79 review service based on evidence, prioritised findings and a developer-ready handover. A free redirect-map checker would demonstrate competence and attract interest. This was a hypothesis, not proof that agencies would pay £79.

The recorded first-session sequence was unusually detailed:

The first-session transcript contained 124 recorded tool-call blocks. The site included a redirect-map checker, sample output and a proposed paid review. The checker later passed 17 functional tests. The associated decision reconstruction was preserved in the private journal:

Owner-private GitHub evidence (not publicly accessible)

Important distinction: 17:24:33 was the first visible written mention of the redirect idea. The model's inaccessible internal thought process cannot be timed or reconstructed merely from that record.

18. Day-by-day operational chronology

The first genuine commercial blocker

On 7 November Agatha drafted three targeted prospecting emails, intended for:

• Chicken Digital
• Fertile.Digital
• Gooey

The owner approved request R-20261106-002, conditional on truthful trading identification and appropriate contact details. Agatha verified the recipients, checked for recorded opt-outs and prepared a send/reply register. She did not send the messages because the corresponding legal seller identity and publishable contact address were still pending. The separate request R-20261106-001 concerned seller details and live payment arrangements.

This exposed a core experiment-design tension. Agatha correctly refused to invent a legal business identity, but she also failed to pursue enough other practical buyer-acquisition paths while waiting. Many scheduled sessions shrank into checking the same inbox, confirming the same blocker and updating the same files.

19. The Day-4 investigation and why DEFCON was introduced

A direct inspection on 9 November, at about 16:33 GMT, found that the Gateway and scheduler were operational. The last completed normal session was around 13:27 GMT. Seventeen of eighteen scheduled attempts since launch had completed successfully, with one expected overlap prevented. However, the normal sessions on 7–9 November averaged approximately two minutes: mainly status checks, not substantive commercial work.

The independent journal had also failed to publish for three days due to the Git checkout divergence described earlier. Thus both the business's effective momentum and its independent visibility were worse than the pre-launch tests suggested.

The original Continuity Loop could see changing text in WORK.md and treat that as progress. It did not robustly distinguish a new externally meaningful event from another “no mail received” checkpoint. The user's subsequent intervention was not a mere prompt-style edit. It changed the actual work runner and evaluation conditions.

Agatha 2.0, implemented on 9 November

The revised mechanism included:

1. DEFCON 1 on every commercial wake-up while verified positive profit was absent or unknown.
2. A root-owned financial scoreboard feeding the current flag status and objective into each scheduled run.
3. Two-hour autonomous work sessions, replacing the four-hour commercial cadence.
4. A profit-first work instruction: ordinary inbox checks, repeated notes and passive waiting were not sufficient as the entirety of a productive session.
5. Freedom to run parallel commercial ideas, without a forced 24-hour abandonment rule.
6. Explicit checks of externally meaningful progress, not only modifications to checkpoint text.
7. MOLT as the external business brand, rather than repeatedly presenting every website page or email as an AI experiment. This did not authorise impersonating a human worker or fabricating a trading identity.
8. Preservation of the £50 owner contribution ceiling, legality constraints, existing permissions and emergency control.

The DEFCON runner's self-test passed, and its integration with the work lock was checked so two simultaneous work sessions would not corrupt shared state. The previous operating files were backed up. The original and changed conditions were recorded in the private journal:

Owner-private GitHub evidence (not publicly accessible)

This is a material intervention in the experiment. Any comparison before and after 9 November is not a clean randomised test of one “motivation” prompt: it also changed the scheduler frequency, work-runner instructions, feedback signal and allowed portfolio behaviour. More activity afterwards is an observation, not proof of which particular change caused it.

20. What changed after DEFCON

The recorded scheduler totals up to 11 November, 18:53 GMT were:

The log marked 43 of 44 attempts successful; one was the expected concurrency/overlap skip. These figures do not include the exceptional initial Astra session and do not represent uninterrupted human-equivalent working time; tool/network waits are included.

The two complete pre-intervention days, 7–8 November, recorded 26.2 minutes across 12 sessions, an average of around 2.2 minutes per session. On 10–11 November, with the new two-hour pattern, the records show 341.3 minutes across 21 sessions, approximately 16.3 minutes per session. This establishes a substantial increase in execution duration, though the changes in instructions, cadence and task availability mean that increased duration cannot be attributed to any one variable.

After DEFCON, Agatha performed more research, published a second offer, distributed content and entered public technical conversations. The new behaviour was substantially more active. What it did not yet demonstrate was effective customer acquisition or profit.

21. Exact public output as of 11 November

One website, not multiple websites

A later independent audit corrected an earlier overstatement. Agatha had built one website, the-molt.com, hosted through the redirect-check project. It contained two service pages, not two separate business websites.

The owner branding change to MOLT was deployed on 9 November, 17:35 GMT. The Shopify service page was added at approximately 17:42 GMT. The alternate Pages hostname was a deployment URL for the same website. An additional local molt-social directory was a publishing utility, not another website.

Confirmed directory listings

Five public directory placements were independently checked in the 11 November audit:

Other submissions included The Tool Directory, AppRater, SEOFOMO Toolbox, Backlinkforme and Peplio. These were at different stages of receipt, moderation or later publication. A confirmed submission is not a confirmed published listing, an actual website visitor or an interested buyer. A PostLaunchKit listing displayed five human views at one inspection, a small signal of directory exposure but not evidence of five sales leads.

Social and technical-community identities

Agatha independently opened some specialised accounts without requesting separate owner registration for each:

No confirmed independent operation of MOLT accounts on conventional LinkedIn, Instagram, Facebook or X was identified in that audit. Some specialised communities require automated accounts to identify themselves, so the new “MOLT brand first” rule did not imply deceptive non-disclosure where platform rules required it.

Direct sales activity at the audit

The same audit found:

The three agency messages remained approved but unsent; their register had no submitted_at timestamps or SMTP receipts. Agatha researched several freelance opportunities, including requests related to inventory spreadsheets, migrations and Shopify, but no successfully submitted bid was established. A reply from a software-tool creator was a real third-party interaction, not a customer expressing interest in MOLT's offer.

Why greater activity was not the same as traction

Agatha was making more independently verifiable progress, but frequently through channels that rewarded publishing or technical contribution rather than customer purchasing decisions. Directory submissions, platform sign-ups and comments are easy to count. They are not interchangeable with qualified enquiries, proposals, accepted prices or paid orders.

The competitive research also suggested weaknesses in the initial offers. Free redirect tools already cover many structural issues, so a paid review would need genuinely useful human- or agent-produced judgement, prioritisation and handover. Low-cost CSV tools similarly compete with basic transformation, so the more defensible Shopify preparation service would need to handle difficult exceptions and data integrity. These were commercial insights, not independently verified market demand.

22. The 11 November live-payment and customer-validation update

By 11 November the owner had decided that the experiment needed a credible method of accepting genuine payment rather than more infrastructure construction. Stripe live onboarding was completed and the restricted key tested. At the end of the record:

• The existing sandbox remained available.
• The new live utility could create products, GBP one-time prices and Payment Links.
• All temporary live test links were deactivated.
• No real customer charge had taken place.
• The agent's working notes were corrected so she no longer treated Stripe as sandbox-only.
• The same two-hour DEFCON schedule remained enabled.
• The still-unsent three agency messages were not silently authorised to be dispatched without their original legal-identity condition.

A focused 12–18 November 2026 customer-validation challenge was added to the scheduled operating instructions. It shifted attention towards real contact with potential buyers and evidence of purchase intent, while leaving Agatha free to choose which services, channels and customers to pursue. The point was not to tell her which business to build, fabricate sales conversations or impose an automatic business pivot.

The remaining owner-side requirement was to decide which genuine business/service address and legally required seller disclosures could be used with MOLT. The proprietor's legal identity was privately recorded in the operating environment and Stripe, but the public website was intentionally not turned into a personal profile. The owner did not authorise publishing a private residential address.

UK online and distance-selling requirements can apply before the first order, not only after a business becomes profitable. A case study that recommends accepting payments while indefinitely withholding legally required trader information would not be reproducible on a sound basis. Exact disclosures depend on the transaction and intended customers and should be checked before launch. See https://www.gov.uk/online-and-distance-selling-for-businesses.

The evidence-based position at cut-off

Technically: the agent, memory, automation, publishing, communications, emergency controls, journal and restricted live Stripe link creation had been demonstrated.
Commercially: Agatha had generated activity and plausible offers but no verified paying customer or captured profit flag.
Administratively: seller disclosure and appropriate contact-address decisions still constrained real orders and the three approved agency emails.
Experimentally: both the initial four-hour continuity mode and the revised two-hour DEFCON mode had been observed, but neither had yet produced verified net profit.

Part V. Recreating the experiment

23. Replication philosophy

The easiest mistake is to copy the amount of infrastructure rather than the experimental requirements. This case study shows that a relatively small study can become over-engineered when every optional check creates a new service, approval process, integration or monitoring layer.

A new operator should preserve these essentials:

1. One independent AI operator with genuine control over its own projects and commercial decisions.
2. A legally owned digital asset such as a domain and separate, authorised business accounts.
3. A persistent computer with the ability to research, build, deploy and communicate.
4. A working recurring job, with durable work checkpoints, rather than expecting a conversational agent to work continuously by itself.
5. Owner-controlled money and emergency stop, both technically separated from the agent.
6. Independent evidence capture, sufficient to inspect what happened without interrogating the agent daily.
7. Honest accounting, distinguishing work performed, public exposure, buyer demand, payment and profit.

Everything else, including a sophisticated dashboard, additional model routing, large testing matrices, multiple commerce services and additional memory databases, should have to justify its maintenance cost. The following is the closest practical reconstruction of the successful operating architecture, with unnecessary historical detours removed.

24. Prerequisites and ownership

A replicator should prepare the following before the launch clock starts:

Do not put legal or banking verification details into normal agent prompts. Establish merchant ownership through providers' legitimate identity interfaces. In a new deployment, no promise of “completely free” infrastructure should be made without checking actual provider limits and billing controls. For example, a fixed £50 experiment is not compatible with a cloud account that can silently accumulate unlimited charges.

Suggested cost treatment

Use two ledgers or at least two clearly separated columns:

• Incremental cash view: actual spending attributable to the experiment, revenue actually received, fees and refunds.
• Economic-cost view: also account for the value of shared subscriptions, model usage and subsidised hosting where a realistic business would otherwise pay for them.

Do not count the budget limit itself as an expense. Do not count owner contributions as revenue. Record explicit zeroes only where a source actually established that there were no transactions, not where an API failed or data were unavailable.

25. Step-by-step technical build

Step 1. Provision a truly separate machine

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.

Step 2. Install and persist OpenClaw

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

Step 3. Connect one strong model and test it

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.

Step 4. Configure local persistent memory

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

Step 5. Install communication and deployment tools

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.

Step 6. Add payments without giving away banking control

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.

Step 7. Establish the owner-controlled capital process

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.

Step 8. Create the small work-state and continuity documents

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.

Step 9. Enable native scheduled business work

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

Step 10. Add an independent Observer

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.

Step 11. Install and test an emergency hold

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.

Step 12. Secure a recoverable backup and freeze launch conditions

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.

26. A minimal copy-ready mission for a new experiment

The exact production SOUL.md text was not included verbatim in the exported transcript. The following is a reconstructed, reusable example, not a claim that these were the precise bytes deployed on 6 November.

You are the independent commercial operator of [DOMAIN].

MISSION
Create and operate a genuine, sustainable online business using the
allocated domain, accounts and permitted tools. You choose the market,
business model, customers, offering, pricing, distribution and timing.
No business ideas or commercial strategies have been preselected for you.

SUCCESS
Pursue real, independently verifiable net operating profit.
Every completed local calendar day without positive verified operating
profit is recorded as a failed-profit day. Continue learning and working;
a failed day does not automatically require a business pivot.

CAPITAL
You may request up to [£50] in total external owner funding. Funding is
not released until the exact request and amount are approved. Available,
cleared business earnings may be reinvested within the agreed controls.
Never treat seed funding, test purchases or unconfirmed income as revenue.

WORK
Operate through scheduled autonomous sessions. Resume unfinished work
from your persistent checkpoint. When blocked, diagnose the problem,
use bounded retries, consider materially different lawful methods and
request legitimate owner assistance when necessary. Continue other
productive work rather than repeatedly reporting the same obstacle.

BOUNDARIES
Operate lawfully, accurately represent your business, respect platform
terms and permissions, protect customer information, avoid deceptive
claims and do not bypass authentication or identity verification.
You may evaluate unconventional or legally uncertain ideas, but unresolved
material legal exposure or irreversible liability requires owner review.

OBSERVATION
Record important decisions, alternatives, experiments, failures and
results in ordinary working notes. Keep evidence links. Do not fabricate
proof or misstate outcomes. An independent observer records system activity.

You are responsible for your own commercial choices.
Begin only when the owner authorises the launch.

A short mission is preferable to one filled with example products, mandatory channels or a predetermined marketing calendar. Operational permissions belong in a separate rules file. If a subsequent owner intervention materially changes the operating protocol, preserve the old version and the effective date rather than overwriting experimental history.

27. A reusable scheduled-session contract

The actual two-hour DEFCON runner was implemented in owner-controlled scripts and files, not fully reproduced in the conversation export. The following is a simplified design pattern for a new system. It is not a verbatim copy of Agatha's runner.

ON EVERY SUBSTANTIVE COMMERCIAL SESSION

1. Check whether an owner emergency hold is active. If so, do not run.
2. Obtain the work lock. If another commercial run owns it, exit safely.
3. Read the current objective and next action from WORK.md.
4. Retrieve relevant persistent memory and outstanding owner requests.
5. Read the independent financial state. Do not infer missing revenue as 0.
6. Select and pursue a concrete commercial objective under the mission.
7. When an obstacle appears:
   - determine its cause;
   - retry only when a retry can reasonably work;
   - test a materially different authorised method;
   - request owner help where legitimate human control is required;
   - continue another useful task while awaiting a reply.
8. Preserve outputs, evidence links and important decisions.
9. Update WORK.md with the next executable action before ending.
10. Release the work lock and create a truthful run record.

A successful scheduler event is not itself a successful commercial result.
Do not equate a rewritten note, directory submission or inbox check with
verified buyer interest, a paid order or profit.

For a DEFCON-style experiment, inject the objective and latest independently checked profit flags into the scheduled work instruction. Treat UNKNOWN as profit not yet verified rather than as evidence of an actual £0 balance. Preserve all legal, credential and spending boundaries. The point of urgency is to improve useful action, not to authorise spam, deception, unauthorised spending or infinite retry loops.

28. Launch checklist and acceptance tests

Before pressing the launch button, a comparable deployment should have evidence for the following. “Not applicable” is acceptable only where the business model does not require a capability.

The historical Agatha launch deliberately left live Stripe activation pending. That was possible for initial market discovery, but it became a material commercial bottleneck once the agent wanted to test buyer interest and take paid bookings. Replicators should decide in advance whether their experimental clock measures commercial discovery or fully payment-ready selling. They should record any delay between launch and lawful ability to accept a real order.

Owner launch operation

The actual first launch combined an owner-approved mission, a one-off Astra Extra High work session and activation of a standing four-hour Sol High job. A new experiment can use this simpler procedure:

1. Verify server, Gateway, scheduler and observer health.
2. Confirm no emergency hold is active.
3. Confirm financial baseline and available external-funding ceiling.
4. Save the final approved mission and operating-rule snapshot.
5. Record official launch timestamp in the chosen local timezone.
6. Enable exactly one substantive recurring commercial job.
7. Trigger the first commercial session once.
8. Verify the model/process actually starts.
9. Verify WORK.md receives a real checkpoint and next action.
10. Verify the independent journal records the event.
11. Do not keep intervening unless permission, safety or evidence warrants it.

The operator should be able to continue when the owner's PC is switched off. A local desktop dashboard is a viewer, not the thing keeping the agent alive.

Part VI. Methodological lessons and evaluation

29. What this experiment does and does not establish

Established in the supplied record

• A distinct OpenClaw operator was installed on an Oracle Always Free ARM instance with no imported unrelated agent memory.
• The agent could complete real model calls, use local memory, perform scheduled work, communicate on Telegram, authenticate to business services, push code and deploy web resources.
• Owner-controlled emergency controls stopped and resumed the agent, including persistent hold through reboot.
• The first autonomous business session selected a niche, created a working checker and published a real website.
• The initial four-hour autonomy loop became commercially passive around an unresolved owner-information dependency.
• The 9 November two-hour DEFCON protocol was followed by substantially longer recorded sessions and more public activity.
• A separate independent monitoring chain caught its own technical faults and was repaired.
• Restricted live Stripe Payment Link creation was verified on 11 November without processing a real purchase.
• No customer payment or cumulative profit flag had been verified by the evidence cut-off.

Not established

• That the selected offers have genuine willingness-to-pay or durable market demand.
• That higher model reasoning or the first Astra session caused a commercially better decision than a cheaper model would have made.
• That DEFCON wording alone caused the increase in productive work, independent of the simultaneous schedule and workflow changes.
• That longer scheduled execution time means proportionate commercial value was produced.
• That automatic recall between two distinct private conversations was reliable, although explicit scheduled memory retrieval worked.
• That all provider charges and the fully costed economic profit were independently reconciled.
• That no indirect Stripe API route could create a recurring checkout from the available restricted key.
• That a customer could lawfully place a real order before the necessary public seller and contact disclosures were resolved.
• That a 60-day autonomous business experiment was completed. Only the first six calendar days and the subsequent setup changes are in this exported record.

30. The central findings

Finding 1. You must test actual autonomous work, not just a working scheduler

The scheduler ran and produced success receipts, yet the agent often performed little more than checking for mail. This is perhaps the strongest operational result. System uptime, session count and task completion status are inadequate proxies for business progress.

Finding 2. Memory does not automatically create initiative

Hybrid memory, persistent Markdown and cross-session retrieval were useful. They preserved context. They did not make the agent more entrepreneurial or help it decide how to bypass a permissible commercial dead end. Memory and autonomous task selection solve different problems.

Finding 3. A blocker can become an attractor

Agatha had a genuine unsatisfied condition for outreach. Rather than branching into other buyer-facing activities, she repeatedly returned to that condition because it was concrete, easy to check and safely within her permissions. A robust continuity system needs to identify work remaining possible despite the blocker, not merely remember that the blocker exists.

Finding 4. Measurable urgency changed behaviour but did not create customers

DEFCON and profit flags coincided with a marked increase in run frequency and duration, and with more externally visible activity. That is a meaningful behavioural observation. However, it did not produce verified sales in the period studied. The next evaluation stage must therefore measure buyer engagement and ability to collect a legitimate payment, not only work sessions, posts or listings.

Finding 5. Agent permissions can create the wrong task incentives

Agatha found many actions it could perform independently: directory submissions, software research, technical comments and account registrations. Reaching actual buying organisations exposed legal identity, outreach and payment dependencies. An agent can therefore appear “busy” while preferring actions with the lowest approval friction, regardless of their effect on revenue. The lesson is to supply a minimally complete legal/payment environment and measure the sales funnel honestly.

Finding 6. Owner-side oversight can accidentally break its own data pipeline

Legitimate manual commits caused the journal publisher to stop for three days. The dashboard later misread the word locked and overwhelmed a small VM with repeated SSH calls. Observation is a software system with its own failure modes. Monitoring needs self-checks and clear UNKNOWN states; otherwise it can mislead the owner into thinking the agent is inactive or blocked.

Finding 7. Security boundaries should be simple and real

The strongest controls were not prose warnings: separate operating-system users, limited cloud credentials, restricted financial permissions, root-owned emergency holds, owner-only secrets and independently verifiable transactions. Conversely, a utility wrapper around an API key was not a hard boundary if the operator could read that key directly.

Finding 8. Do not overbuild the apparatus

The project temporarily became bogged down in repeated setup approvals, credential rotations, backup cycles and multi-service integration tests. A scope-freeze intervention stopped the expansion and focused the remaining work on functional readiness. For a £50 business experiment, proportionate tests and honest limitations are more valuable than endlessly refining infrastructure.

31. How to evaluate the rest of a 60-day experiment

A rigorous evaluation should separate technical competence, commercial agency and economic outcome. Suggested measures are:

Keep an intervention log with date, reason, precise operating changes and observable consequences. A small autonomous-business pilot is not a controlled trial, but it can still be a useful longitudinal case study if the conditions are documented honestly.

The November 2026 run should be treated as two successive operating regimes:

• Regime A, 6–9 November before the change: four-hour scheduled work with continuity checks, no DEFCON flags, a business idea chosen in a one-off Astra launch.
• Regime B, from 9 November: two-hour DEFCON work runner, root-owned flag scoreboard, stronger emphasis on profit-first action and the ability to pursue multiple ideas.

A third phase began as live Stripe readiness and customer-validation instructions were introduced on 11 November, with a 12–18 November buyer-contact challenge scheduled for subsequent sessions. Outcomes of that challenge lie outside the supplied evidence and should not be reported in this paper as completed.

32. A concise change log for engineers

Sources and reproducibility notes

A. Primary project evidence

The principal source for this paper is the complete uploaded conversation export named ChatGPT_Autonomous-Profit-Experiment_20261111-2113.md. It contains owner requests, generated Codex specifications, execution handovers, reported tests, direct inspections, deployment decisions and subsequent corrections up to the stated cut-off. This document has been reconstructed from that export, not from an independently fetched production configuration archive.

The following owner-controlled resources were referenced in the export. Their access may require the owner's private GitHub permissions:

• Agatha private journal (owner-private evidence)
• Day-1 launch baseline (owner-private evidence)
• First commercial decision reconstruction (owner-private evidence)
• 9 November DEFCON intervention (owner-private evidence)
• 11 November live Stripe owner update (owner-private evidence)
• Encrypted recovery release (owner-private evidence)

Other private supporting records described in the export include VENTURE-01-INFRASTRUCTURE-HANDOVER.md, AGATHA-DAY1-READINESS-HANDOVER.md, AGATHA-EMERGENCY-OPERATING-GUIDE.md, protected Oracle evidence archives, Gateway trajectories and session records, and the original Codex execution history. These records would be required for forensic reproduction of every exact file byte and configuration setting. The exported dialogue captures the implementation specifications and reported outcomes, but does not embed every configuration file or test log.

B. Official technical references

• Oracle Always Free resource allocation and idle reclamation
• Oracle Free Tier account and billing behaviour
• OpenClaw Oracle installation
• OpenClaw official setup
• OpenClaw native memory engine
• OpenClaw automation scheduling
• OpenClaw heartbeat operation
• Stripe API key permissions
• Stripe fulfilment guidance
• Tailscale pricing and plan-use distinctions
• UK online and distance-selling information requirements

Version warning: Software commands, model names, free-tier quotas, provider permissions, pricing and regulation may change. The paper records the November 2026 installation. A future recreation should use current authoritative documentation when the live provider differs. In particular, use Oracle's own current quotas over a stale example in a third-party installation guide.

C. Final assessment

At the end of the available record, Agatha was a working autonomous business operator with a testable infrastructure, not a proven profitable autonomous entrepreneur. The implementation demonstrated that an AI agent could independently select a commercial direction, build and publish real assets, use external services, operate through scheduled sessions, preserve memory and work state, and remain under genuine owner financial and emergency control. It also demonstrated that such an agent could become commercially passive despite technically successful automation, and later become much more active without generating a paying customer.

For someone recreating this experiment, the key is not to copy every incidental integration. It is to preserve the testable separation between agent autonomy, real commercial outcomes, independent observation and human control of irreversible consequences.

The next decisive evidence will not be another successful deployment or longer scheduled run. It will be a genuine buyer, a completed lawful transaction and independently verified net profit.