## For agents - What Mensara is: it gives a team its own Mind, one shared memory for the team and their AI agents, built by Xanadu Labs LLC. - Status: signup is not open. A person joins the waitlist at https://app.mensara.ai/#waitlist. Agents cannot create an account or sign up. - How you can help your person: explain what Mensara does, check whether it fits a job their team repeats, and share the waitlist link. - Agent references: https://app.mensara.ai/llms.txt lists every page as Markdown and the tool input references for connected agents. --- # Connect a backup and inspect recovery readiness Operating procedures · For agents and technical readers · [How it works](https://app.mensara.ai/how-it-works) Use the owner-authorised backup ceremony, inspect freshness and kit state, and hand sensitive recovery material through the protected owner route. [Page as Markdown](https://app.mensara.ai/how-it-works/backup-procedure.md) [Human guide](https://app.mensara.ai/how-it-works/backup-restore-ownership) ## Use the released interface with current authority Availability: Core0.20.11 / Portal0.3.47 source checked; discover the actual installed client and enabled features. Who can do this: The connected principal with the permissions named in this procedure What changes: The procedure explains its actual reads, writes or external effects before action. Limits: An input accepted by a source schema is not a successful installed-runtime task.; Keep human decisions, client exclusions and pending results explicit. Verification: Source checked and independently reviewed; scoped runtime receipts are recorded separately. ## Authority and sensitive output The backup lifecycle requires owner recovery capability. `backup_status` can expose a reduced declined-only result to a non-owner onboarding caller; that does not prove connection state. `recovery_kit_download` returns live key material and must not be called into an agent conversation, shared log or document. Use the owner’s protected Portal download instead. ## Read the full owner state Call `backup_status` with `{}` under owner authority. Inspect `connected`, `declined`, `last_success_at`, `stale`, `remote_kind`, `recovery_kit_downloaded` and `recovery_kit_stale` when the full shape is available. Connected is stored configuration. A recent successful push is separate. A downloaded/current kit is separate from secure custody or a successful restoration. ## Start the repository ceremony Have the owner create a private repository they control. After explicit authorisation to connect that target, call `backup_connect_start`: ``` {"repository":"/"} ``` Replace the placeholder with the verified target. The response supplies the app-install URL, repository-selection instructions, user code, verification URL, expiry and poll interval. The owner performs the GitHub browser steps and selects only the intended repository. Do not place one-use codes or credentials in durable records. ## Poll the same attempt Call `backup_connect_poll` with `{}` no faster than the returned `interval`. Continue only while awaiting authorisation and within the ceremony’s expiry. Treat `no_session`, a named error, `failed` or a repository-entry correction as a state to resolve rather than polling forever. A connection can be stored while the first push failed. Inspect status before restarting. A denied or expired owner authorisation needs its specific remedy; it does not justify broader repository access. ## Inspect the result and keep the kit Read `backup_status` again and verify a successful push and non-stale result. The owner downloads the current Recovery Kit through **Settings → Recovery kit** and keeps it separately. Never copy its content into a support report. An explicit `backup_decline {}` records the owner’s decision to remain unprotected; do not call it as cleanup or as a way to silence a failed backup. Later successful connection supersedes that choice. ## Recovery and export handoff For recovery, name the repository, backup point, replacement environment and authorised operator. Supply the kit via its secure owner channel. The operator restores tracked history, verifies the signed audit chain against the separately held kit trust key, reconnects services and exercises the intended user’s harmless read. The owner CLI supports offline `brain-gateway --repo verify --trust-key `; placeholders require the actual approved paths/key. That verifies history, not the entire installed system. The kit includes sensitive material beyond the verify key and must remain private. Exporting current Markdown or cloning Git history does not export connection credentials, cancel billing or recreate the running service. Inspect the requested export and account consequences separately. A restore rehearsal result is required before claiming recovery works. ## Related - [Back up, recover and export your Mind](https://app.mensara.ai/how-it-works/backup-restore-ownership) - [Manage your Mensara account and billing](https://app.mensara.ai/how-it-works/account-and-billing) - [Recover pending, failed or interrupted work](https://app.mensara.ai/how-it-works/interrupted-work) [Join the waitlist](https://app.mensara.ai/#waitlist)