Independent enough to act.
Contained enough to stop.

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

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.