A working agent.
Not yet a profitable business.

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