One Work Loop for Cloud Agents

Cloud agents are great at following instructions and terrible at inventing process. Give them a pile of Salesforce deploy rules, dual-org auth notes, screenshot rubrics, and Gearset MR quirks — and nothing that says how to approach the work — and they improvise. Investigations turn into half-implemented fixes. Simple metadata tweaks grow “while I’m here” cleanups. Every new task shape tempts you to write another instruction file: investigator agent, planner agent, Apex agent, ops agent.

I didn’t want that. I wanted one process that scales from “why is this field blank?” to “plan the epic” to “ship the Apex change with coverage proof,” with environment rules kept separate from reasoning rules. The result lives in three files:

CLOUDAGENTS.md — how this repo’s cloud VM works (auth, orgs, deploy, evidence, delivery)
WORK_LOOP.md — one generic seven-step loop with four work modes
PAPERCUTS.md — an append-only friction log so ephemeral sessions leave a trail

This post is the cloneable version of that setup. The Salesforce details — especially scratch orgs — are my concrete case. The architecture is what you should steal.

The high-level loop

Every task runs the same seven steps. Mode and scope change the depth; they do not change the sequence.

1. Understand and classify   → pick mode, scope, side effects, deliverable, verification
2. Investigate current state → gather enough evidence to choose an approach
3. Choose approach and proof → decide what "done" looks like before acting
4. Execute                   → answer, design, change, or operate in controlled increments
5. Verify                    → strongest practical evidence for the requested outcome
6. Review and deliver        → clean diff, conflict preflight, MR or pushed doc
7. Reflect when useful       → pitfall log and/or one paper-cut line — skip if nothing to keep

For a Salesforce metadata/code change, those middle steps specialize into a promotion path:

LEARNINGS.md
  → ensure this worker's SCRATCH org
  → implement + targeted deploy + targeted unit tests on SCRATCH
  → promote the same slice to AGENT_DEV
  → full feature suite + coverage + UI proof on AGENT_DEV
  → merge-conflict preflight → MR to qa
  → leave SCRATCH open for follow-ups

Scratch-only green is not enough to open an MR. AGENT_DEV is the integration gate. PROD stays read-only.

The loading chain

Agents don’t magically know they’re in the cloud. The repo tells them, then loads the right docs in order:

AGENTS.md
  → run detect-mode.sh  →  CLOUD or LOCAL
  → if CLOUD: read CLOUDAGENTS.md
  → CLOUDAGENTS.md requires WORK_LOOP.md before the task starts
  → skills/runbooks load only when the task actually needs them

Local sessions skip the cloud doc. Cloud sessions get the full stack. That split matters: most of your conventions (file placement, CLI usage, “read LEARNINGS before changing code”) belong in AGENTS.md for everyone. Cloud-only constraints — ephemeral VM, org model, “commit or lose it” — belong in CLOUDAGENTS.md.

Detection itself was a paper cut before it became a script. Checking a single env var for “am I in Cursor Cloud?” false-negatives when secrets inject after the first shell command. Layer the signals:

#!/usr/bin/env bash
# detect-mode.sh — prints CLOUD or LOCAL
set -euo pipefail

script_dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
repo_root="$(git -C "$script_dir" rev-parse --show-toplevel)"
marker="${repo_root}/.cursor/.cloud-agent-boot"

if [[ -n "${CLOUD_AGENT_ALL_SECRET_NAMES:-}" ]] \
  || [[ -n "${CLOUD_AGENT_INJECTED_SECRET_NAMES:-}" ]] \
  || [[ -f "$marker" ]] \
  || [[ -d /exec-daemon ]]; then
  echo CLOUD
else
  echo LOCAL
fi

Boot writes the marker. The daemon directory exists on cloud VMs. Secrets are a bonus signal, not the only one.

Three orgs, three jobs

The biggest operational lesson: do not make one sandbox do iteration and integration proof. Cloud agents in this repo use three Salesforce targets:

Org	Alias	Purpose
Production	`PROD`	Read-only queries; also the Dev Hub that creates scratch orgs
Scratch	`SCRATCH`	That worker's isolated edit → deploy → unit-test loop
Agent Dev sandbox	`AGENT_DEV`	Integration deploy, full feature suite, coverage, UI/review evidence before MR

Rules that keep the model honest:

Never deploy to PROD. Never deploy to qa/staging/prod from a cloud agent.
Do not share scratch orgs across different workers. Parallel agents each get their own.
Do not call ensure-scratch.sh for questions, investigations, plans, or docs-only work.
Scratch-only green does not satisfy the MR gate.

Where each kind of work runs

Activity	Where
Edit → deploy → fix loop	`SCRATCH` (targeted metadata slice only)
Apex unit tests while iterating	`SCRATCH` (narrow set: classes you're changing)
LWC Jest	Local (npm) — no org required
Full affected feature Apex suite	`AGENT_DEV`
Coverage ≥80% per changed class/trigger	`AGENT_DEV`
MR screenshots / UI proof	`AGENT_DEV`
Org-shaped failures (drift, packages, existing automation)	`AGENT_DEV` — scratch won't catch these
Prod data questions	`PROD` (read-only)

Rule of thumb: unit-test early and often on SCRATCH; prove the change on AGENT_DEV before the MR.

Scratch orgs: the iteration lane

A shared sandbox is a terrible place for an autonomous agent to thrash. Someone else’s half-deployed experiment, stale packages, or yesterday’s failed migration shows up as your bug. Scratch orgs fix that: each cloud worker gets a clean, short-lived org shaped by config/project-scratch-def.json, created from PROD as Dev Hub.

Lifecycle

Create once per worker via ensure-scratch.sh when metadata work is about to start.
Reuse on follow-up turns in the same conversation. A marker file (.cursor/.scratch-invocation) keeps the local SCRATCH alias pinned to that org.
Leave it open at end of turn. Do not auto-delete — follow-ups should not pay create latency again.
Optional cleanup with delete-scratch.sh only when the work is fully done and you need Dev Hub slots.

Default duration is 7 days. The Dev Hub org name is unique per worker (Worker <conversation-prefix> <timestamp>); the local alias is always SCRATCH so every skill and script can target one name.

# Start of this worker — creates or reuses
bash .cursor/cloud-agent/scripts/ensure-scratch.sh

# Iterate on a targeted slice (spaces, not commas)
sf project deploy start \
  --metadata ApexClass:Foo ApexClass:FooTest \
  --target-org SCRATCH \
  --test-level RunSpecifiedTests \
  --tests FooTest \
  --wait 30 \
  --json

# Promote the same slice before MR
sf project deploy start \
  --metadata ApexClass:Foo ApexClass:FooTest \
  --target-org AGENT_DEV \
  --json

What scratch is for — and what it isn’t

Work	Use `SCRATCH`?
Implement / change Apex, LWC, flows, objects	Yes — default path
Questions, investigations, SOQL, code reading, plans	No — repo + `PROD` / `AGENT_DEV` as needed
Docs / agent-convention edits only	No
Operate / backfill / one-off data work	No — usually `AGENT_DEV` or an explicit target

Never deploy the entire unpackaged/ tree to scratch. This metadata repo will not accept a full-org push into a fresh Enterprise scratch. Always send a targeted slice: the components you changed, plus the dependencies the platform needs (test class with the production class, handler with the trigger, Apex controllers with the LWC).

Deploy flag gotcha that burned us: --metadata ApexClass:A,ApexClass:B (comma-separated) resolves to zero components. Use spaces or repeated --metadata flags.

Why the two-hop promotion exists

Scratch answers: “Does this compile, and do my unit tests pass in a clean org?”

AGENT_DEV answers: “Does this survive contact with our real packages, existing automation, and the rest of the feature family’s tests?”

Those are different questions. Collapsing them into one org either slows iteration (dirty shared sandbox) or lies about readiness (clean scratch that never saw production-shaped dependencies). The work loop’s verify step maps onto both: targeted evidence on SCRATCH during execute, integration evidence on AGENT_DEV before deliver.

What CLOUDAGENTS.md owns

CLOUDAGENTS.md is not a personality. It is the operating manual for an async agent on a disposable machine. Mine covers:

Autonomy and persistence. Proceed on reasonable assumptions. Stop for consequential product choices, destructive actions, or real blockers. Commit and push every deliverable — the VM dies.
Org model. PROD read-only (+ Dev Hub). SCRATCH for iteration. AGENT_DEV for the MR gate. Never guess; never deploy to production.
CLI hygiene. Every sf command gets --json. Parse the response. Tabular output is for humans staring at a terminal, not agents.
Evidence rubric. Visible UI changes need screenshots from AGENT_DEV. Apex/Flow/logic changes need tests, deploy output, queries. Screenshots are not proof of hidden logic.
Delivery. Code gets an MR. Investigations get a pushed markdown blob, usually without an MR. Gearset may close your feature MR and open a replacement — update the live one.
Paper cuts. When the environment interrupts the task, append one line and move on.

The important boundary: CLOUDAGENTS.md specializes the work loop for this environment. It does not redefine how to think. Scratch lifecycle, deploy ritual, screenshot viewport size, Apex coverage gates — those are repository specifics layered on top of a generic loop.

A Salesforce change, under that specialization, looks like this in practice:

Read LEARNINGS.md (repo pitfall log) before touching metadata
Decide verification up front, including whether the UI must prove acceptance
Ensure this worker’s scratch org; implement; deploy a targeted slice to SCRATCH; run targeted Apex unit tests there
Promote the same slice to AGENT_DEV; run the full affected feature suite
For Apex: every executed test green + ≥80% coverage per changed class/trigger (not aggregate)
Capture review evidence from AGENT_DEV (screenshots when the rubric calls for them)
Conflict preflight against the MR target; open or update the MR with testing proof
Return the MR URL, verification result, and any blocker — leave SCRATCH open

That list is the cloud specialization of steps 4–6 of the loop. Keep your specialization short enough that an agent can hold it.

The work contract

Before the agent starts grinding, it classifies the task. Internally — not as a user-facing ceremony:

mode: investigate | design | change | operate
scope: local | cross-component | program
side_effects: none | repository | sandbox | production-data
deliverable: answer | report | plan | code | operation-result
verification: evidence | targeted | integration | ui | operational

Four modes. Same loop. Different terminal conditions:

Mode	Purpose	Done when
`investigate`	Facts, diagnosis, findings	Evidence-backed answer or report
`design`	Approaches, trade-offs, plan	Decision-ready proposal
`change`	Code, metadata, tests, docs	Implemented, verified, delivered
`operate`	Deploy, backfill, monitored procedure	Verified external result or concrete blocker

Scope is depth, not persona. An easy bug and a nasty cross-Flow bug are both change. They differ in investigation depth and verification strength — and, for Salesforce changes, whether you ever need a scratch org at all.

Example contracts

Triage a Slack report: “Closed Won opps sometimes miss PG Collections.”

mode: investigate
scope: cross-component
side_effects: none
deliverable: report
verification: evidence   # code + prod queries + specific opp IDs
# no scratch org

Fix a typo in a validation rule error message.

mode: change
scope: local
side_effects: sandbox
deliverable: code
verification: targeted   # SCRATCH deploy + reproduce; AGENT_DEV before MR

Plan splitting a monolith Flow into invocable subflows.

mode: design
scope: program
side_effects: none
deliverable: plan
verification: evidence   # constraints, migration sequence, open decisions
# no scratch org

Backfill junction records for one Closed Won opportunity.

mode: operate
scope: local
side_effects: production-data
deliverable: operation-result
verification: operational  # dry-run → execute → query proof → rollback notes
# no scratch org — follow the operate runbook

If you find yourself writing mode: investigate-but-also-maybe-fix, stop. Pick one mode. Finish it. Start another task if implementation is warranted.

The seven-step loop in detail

The process stays constant. Mode, scope, side effects, deliverable, and verification depth adapt it.

1. Understand and classify

Determine the outcome. Fill the work contract. Separate explicit requirements from assumptions. Load universal instructions, the relevant mode policy, and only the skills that actually apply.

Do not announce the classification unless the task is complex or resumable. Status theater burns tokens and patience.

Clone tip: Put a one-line trigger in your cloud doc: “Before beginning a task, read and follow WORK_LOOP.md.” Make the loop authoritative, not optional flavor text.

2. Investigate current state

Gather enough evidence to choose an approach — not enough to write a dissertation.

investigate — reproduce symptoms; kill competing explanations
design — map architecture, constraints, real alternatives
change — inspect components, dependencies, existing tests
operate — scope, preconditions, blast radius, rollback

Stop when more exploration is unlikely to change the approach or the proof plan.

Concrete Salesforce investigate sketch:

# Confirm the symptom in PROD (read-only)
sf data query --target-org PROD --json --query \
  "SELECT Id, Name, StageName FROM Opportunity WHERE Id = '006...' "

# Find automation that fires on Closed Won
rg -n "Closed Won|IsWon" unpackaged/main/default/flows unpackaged/main/default/classes

# Check whether the missing records exist under another parent
sf data query --target-org PROD --json --query \
  "SELECT Id FROM PG_Collection__c WHERE Opportunity__c = '006...' "

Claims in the report must point at query results, code paths, or authoritative docs — not at the user’s opening hypothesis.

3. Choose the approach and proof

Decide what will be answered, designed, changed, or executed. Define verification before acting. Ask the user only when a missing product decision materially changes the result — not for permission to run an already-authorized, technically constrained action.

For a local metadata fix, this step is a silent sentence: “Targeted deploy to SCRATCH; unit-test; promote to AGENT_DEV; MR with testing proof.”

For a cross-component business process, write the proof plan down in the branch artifact:

## Verification plan
1. ensure-scratch.sh
2. Deploy handler + trigger + test to SCRATCH; run FooTest
3. Deploy the same slice to AGENT_DEV
4. Run full feature test class on AGENT_DEV
5. Confirm coverage ≥ 80% on each changed production class
6. Screenshot only if a Lightning UI state is part of acceptance

4. Execute

Produce the deliverable in controlled increments. Stay inside authorized side effects. If new evidence kills the approach, reassess — don’t keep digging the same hole because step 4 is “the coding step.”

For Salesforce change work, execution means: create or reuse SCRATCH, deploy the slice, fix compile/test failures there, then promote. Investigation and execution may alternate. That is fine. Mechanical phase-gating is how agents waste the afternoon.

5. Verify

Use the strongest practical evidence that proves the requested outcome:

Work shape	Expected evidence
Investigation	Claims → code, data, runtime, or authoritative sources
Design	Constraints, trade-offs, risks, unresolved decisions
Local change	Targeted test/check on SCRATCH, then AGENT_DEV gate
Cross-component change	Integration validation on AGENT_DEV across boundaries
Business-process change	Representative scenarios + failure paths + QA evidence
Visual change	Rendered UI inspection + screenshots from AGENT_DEV
Operation	Preflight, scoped execution, post-check, rollback readiness

Test design quality (this belongs in the loop, not only in Apex folklore):

Prefer fewer coherent scenarios over one method per branch
Combine related cases that share setup; split different actors, transactions, and error contracts
Assert outcomes and persisted side effects — not assertion count theater
Coverage is a gate, not the purpose of the suite

My Apex MR gate, as a worked example of “repository-specific verification” — this runs on AGENT_DEV, not scratch:

sf apex run test \
  --class-names MyClassTest \
  --target-org AGENT_DEV \
  --wait 30 \
  --code-coverage \
  --result-format json

Parse per-class coverage for every changed production class and trigger. Aggregate org coverage does not count. Missing percentage blocks the MR.

6. Review and deliver

Review the diff or external result. Confirm you didn’t smuggle unrelated cleanup. Fetch the intended MR target and run merge-conflict preflight before creating the MR. Persist according to repo rules. Report outcome, strongest evidence, assumptions, blockers. Never claim external success you did not verify.

Cloud-specific delivery twist for ephemeral VMs: gitignored draft folders are a trap. Locally I write investigations to docs/investigations/drafts/. In the cloud, that content dies with the VM — so cloud agents commit straight to the tracked category directory and push. Same quality bar; different persistence model.

Gearset may immediately close the feature MR and open a promotion MR from a gs-pipeline/... branch. Treat the create URL as provisional. Put final testing proof — including screenshot re-uploads — on the replacement MR.

7. Reflect when useful

Two sinks, different jobs:

Task discoveries → the investigation doc, plan, MR, or LEARNINGS.md-style pitfall log
Environment / tooling friction → one line in PAPERCUTS.md

Skip reflection when nothing meaningful needs preserving. No mandatory retrospective essay.

Paper cuts: the append-only friction log

Ephemeral agents rediscover the same broken CLI flag every week unless you give them a place to leave a scar. PAPERCUTS.md is intentionally dumb:

# Cloud Agent Paper Cuts

Append one line when avoidable friction in the cloud environment,
tooling, instructions, or workflow materially interrupts a task.

Format:

- YYYY-MM-DD | area | problem | what would have helped | run: <URL-or-ID>

Append only. Never edit, reorder, deduplicate, or resolve existing lines.

Example lines (synthetic, but shaped like real ones):

- 2026-07-10 | sf-auth | --sfdx-url-stdin hangs on sf v2 | document --sfdx-url-file only | run: bc-abc123
- 2026-07-12 | detect-mode | CLOUD_AGENT_ALL_SECRET_NAMES empty at first shell | layer boot marker + /exec-daemon | run: bc-def456
- 2026-07-14 | glab | mr create --body unknown flag | use --description | run: bc-ghi789
- 2026-07-18 | scratch | comma-separated --metadata deployed zero components | require spaces in CLOUDAGENTS | run: bc-mno345
- 2026-07-19 | evidence | Gearset regenerated MR dropped screenshot URLs | re-upload on replacement MR | run: bc-jkl012

Rules that keep it useful:

One line. Then continue the primary task.
Environment and workflow only. Ticket code defects, one-off data facts, and “Salesforce can’t do X” platform limits do not belong here.
Commit on the task branch so the line survives the VM.
No status workflow. Maintainers triage separately. The file is a signal, not a ticketing system.

Concurrent agents will append on different branches. Give the file a union merge driver so parallel one-line appends keep both sides:

.cursor/cloud-agent/PAPERCUTS.md merge=union

That is the entire “platform.” No API. No dedupe service. Review the file when it gets noisy; fix the top offenders in boot scripts or docs; leave the historical lines alone.

Directory layout to copy

.
├── AGENTS.md                          # universal; detect mode; shared conventions
├── CLOUDAGENTS.md                     # cloud-only operating manual
├── config/project-scratch-def.json    # scratch shape (edition, features)
└── .cursor/
    ├── environment.json               # install + start hooks (auth, tools)
    └── cloud-agent/
        ├── WORK_LOOP.md               # modes + seven steps (generic)
        ├── PAPERCUTS.md               # append-only friction log
        └── scripts/
            ├── detect-mode.sh
            ├── ensure-scratch.sh      # create/reuse per-worker SCRATCH
            ├── delete-scratch.sh      # optional cleanup when fully done
            ├── sf-auth.sh             # PROD + AGENT_DEV auth
            └── check-merge-conflicts.sh

Suggested ownership split:

File	Owns	Must not own
`AGENTS.md`	Shared conventions, mode detection pointer	Cloud-only auth ritual
`CLOUDAGENTS.md`	Orgs, scratch lifecycle, deploy, evidence, delivery	Separate persona per task type
`WORK_LOOP.md`	Classification, reasoning, verification principles	Vendor-specific CLI encyclopedias
Skills / runbooks	Specialized sequences (bulk upload, UAT CSV, …)	A second competing work process
`PAPERCUTS.md`	Append-only friction signal	Resolutions, rankings, ownership fields

Keep the maintainable instruction set small on purpose:

Core loop + mode policies
Repository specifics (including scratch → sandbox promotion)
Specialized skills only when the workflow has genuinely specialized steps
Lightweight output standards for reports and MRs

Report formatting, plan formatting, ticket size, and change complexity do not justify separate agent personas.

Walkthrough: four tasks, one loop

A. Investigate

Prompt: “Why did opportunity 006ABC miss PG Collections on Closed Won?”

Classify → investigate / cross-component / report / evidence
Query PROD for the opp, related collections, and closed-won timestamp — no scratch
Trace the Closed Won automation path in Flows/Apex; note template or config guards
Write the investigation doc with claims tied to query IDs and code symbols
Push the branch; return the blob URL; no MR
If auth flaked mid-query, append a paper cut and re-auth — do not turn the investigation into a boot-script refactor on the same branch unless that was the task

B. Design

Prompt: “We need account matching to stop proposing PHI-looking fields in the UI. Plan options.”

Classify → design / cross-component / plan / evidence
Inspect current LWC + Apex field allowlists; query how often offending fields appear
Compare approaches (allowlist, blocklist, separate “safe display” DTO) with trade-offs
Deliver a decision-ready plan: recommendation, migration, test strategy, open product questions
Push; no code; no MR; no scratch

C. Change

Prompt: “Implement the allowlist from the plan; ship an MR.”

Classify → change / cross-component / code / integration + ui
Read LEARNINGS; inspect tests that already cover the controller
Proof plan: SCRATCH targeted loop → AGENT_DEV full suite + 80% gate → screenshot the picker without PHI labels
ensure-scratch.sh; implement; deploy controller + LWC + tests to SCRATCH; run targeted tests; fix there
Promote the same slice to AGENT_DEV; run full test class with coverage; capture 1440×850 screenshot
Squash, push, conflict preflight, open MR to qa with testing proof; after Gearset conversion, re-attach proof on the replacement MR
Leave SCRATCH open; paper-cut only if the toolchain got in the way

D. Operate

Prompt: “Backfill PG Collections for opp 006ABC using the existing helper. Dry run first.”

Classify → operate / local / production-data / operational
Preflight: confirm collections are actually missing; confirm helper matches origin/main; confirm rollback — no scratch
DRY_RUN → show proposed inserts → wait for explicit execute approval if your runbook requires it
EXECUTE → query proof → report record IDs
Do not “also fix” the automation that caused the miss unless that is a separate change task

Same seven steps each time. Different depth. Different proof. Scratch only when you’re about to deploy a change.

Failure modes this is designed to prevent

Creating a separate agent or large instruction file for each task variation
Treating the user’s initial explanation as verified current state
Choosing a solution before investigating dependencies
Asking questions that code or runtime evidence can answer
Applying change behavior to a read-only investigation
Opening an MR on scratch-only green
Sharing one scratch org across parallel workers
Deploying the entire unpackaged/ tree to a fresh scratch
Running checks that do not prove the requested outcome
Treating UI screenshots as proof of hidden logic
Expanding narrow work into adjacent cleanup
Turning internal process stages into visible status-message ceremony
Letting environment friction evaporate when the VM is destroyed

What I deliberately deferred

The loop does not require runtime orchestration. No classifier service. No workflow engine. No automatic Jira filing from paper cuts. Those can come later if a demonstrated problem justifies them — and they should support the loop, not replace it.

Also deferred: automatic “learning routing” that decides which pitfall docs to inject. The work loop is the stable hook for that later. Premature routing is how you get a second brain that fights the first one.

Minimal starter kit

If you want the gist without the Salesforce encyclopedia, start here.

AGENTS.md (excerpt):

At session start, run: `bash .cursor/cloud-agent/scripts/detect-mode.sh`
If it prints CLOUD, read CLOUDAGENTS.md before doing any work.

CLOUDAGENTS.md (excerpt):

# Cloud Agent Conventions

Required work loop: read and follow `.cursor/cloud-agent/WORK_LOOP.md`
before beginning a task. This file specializes that loop for this repo.

- Work autonomously; stop for consequential product choices or real blockers.
- This VM is ephemeral — commit and push deliverables.
- For metadata changes: iterate on SCRATCH, prove on AGENT_DEV, then MR.
- Paper cuts: append one line to `.cursor/cloud-agent/PAPERCUTS.md` when
  environment/tooling/workflow friction materially interrupts the task.

WORK_LOOP.md: copy the mode table, the YAML contract, and the seven steps from this post. Keep verification principles universal; put CLI commands and org aliases in the cloud doc or in skills.

PAPERCUTS.md: header + format line + “append only.” Add merge=union in .gitattributes.

Boot: whatever installs your CLIs and authenticates non-interactively. If auth needs a footgun warning, write it down once — that is how paper cuts graduate into docs.

Why this works for agents

Agents are obedient and forgetful. Detailed environment rules without a work process produce confident thrashing. A work process without environment rules produces beautiful plans that never deploy. An append-only friction log without either of the above is a graveyard of complaints.

Scratch orgs make the obedience useful: the agent can burn a clean org on a bad approach without poisoning the shared sandbox. The work loop makes the forgetfulness survivable: every task starts from the same contract instead of last week’s improvisation.

Together:

CLOUDAGENTS.md makes the machine survivable
WORK_LOOP.md makes the reasoning consistent across task shapes
SCRATCH → AGENT_DEV makes iteration fast without lying about readiness
PAPERCUTS.md makes the scars durable

You do not need a council of personas. You need a contract, a loop, a clean place to thrash, and a place to write down when the floor moves.