Takeover, atomically

When a human steps in and sends a message as Clara, four things must happen as one action. The design for making that structurally true — and usable from the UI.

2026-08-29 · separate initiative (Fede) · design only — implementation scheduled, not started · Trello 3Cp0XQEt

The invariant: a takeover is one atomic update. Send the message, close the question it answered, record what the human said as the true answer, hand the conversation back — all four commit together or none do. There is never an observable in-between: never a sent message with its question still open, never a closed question with no message.

Why this is a lane of its own

Twice, the four steps living as a written checklist has burned us:

Aug 12 — a human answered a tenant's question by hand; the escalation record stayed open, and reminders kept chasing a question that was already answered. The takeover instructions have required "close the escalation your message answered" ever since — as prose.
Aug 28 — a human sent the corrected voucher answer as Clara; the send rail silently flipped the thread back to autonomous 79 ms later, and Clara contradicted her own boss 82 seconds after that. The checklist step ("keep the thread human-owned until settled") was not skipped by carelessness — the rail made it structurally unfollowable.

A safety step that lives in prose gets skipped under "loop closed" momentum. This initiative moves all four steps into the send path itself, where forgetting is impossible.

Already shipped (defect fixes, merged Aug 29)

Release at settle, not at send — a takeover send never releases a thread whose open matter still awaits an answer. The message still goes out and is recorded; only the hand-back waits. The flip itself is correct (human answers, Clara continues — Fede's ruling); its timing was the bug. Fails safe in both directions: a storage error flips rather than wedging the rail, and threads with no open matter behave exactly as before.
An answered question stays answered — a re-contact can never wipe a recorded answer back to "pending."
A refused send says why — a hold/opt-out block surfaces the reason and the action instead of failing silently.

Operator caveat until the composer exists: the manual rail runs from a local checkout — the fixes protect an operator only once their session is on updated main.

What this initiative builds

1 · The atomic update

One operation, transactional on our side: the state effects (matter closed with the answer recorded, human-authority stamp, thread release) commit in a single transaction, keyed to confirmation of the dispatched message. Ordering: persist the outbound row, dispatch, then commit the state transaction on dispatch confirmation. The message send is external and cannot sit inside a database transaction — so the failure semantics are specified, not implied:

Dispatch fails → nothing commits: the message row is marked failed, the matter is untouched, the thread keeps its posture. The operator sees the failure and the reason.
Crash between dispatch and commit → a reconciliation pass completes the state commit from the confirmed dispatch record. The window is milliseconds; the repair is automatic; no partial state is ever observable to the loop or the UI.

2 · Absorption — the human's words become ground truth

The deferred half of the Aug 29 fix, done deliberately: the operator's text is recorded as the matter's staff answer and stamped authoritative — Clara can never contradict it, on this thread or after hand-back, forever. The known design wrinkle (settling a matter from an outbound send must not re-relay the answer the operator just sent by hand) is the core review item of the build.

3 · The composer — takeover from the UI

Reply-as-Clara in the conversation pane (Fede: "would be nice to do on the UI"). What today needs a terminal and a skill becomes a text box any teammate can use. The record carries who wrote it ("Sofia, as Clara"); the send works on a muted thread (one send goes out, the mute stays — Fede: keep this). Known prerequisite from adversarial review: the human-authority flag must be threaded through whichever dispatch rail the composer uses — one rail today drops it, which would over-block the muted one-send.

Decisions

#	Decision	Status
1	Four effects commit as one atomic update — no observable partial state.	Decided — Fede, Aug 29
2	Hand-back is expected: human answers, then Clara continues — takeover never permanently locks a thread.	Decided — Fede, Aug 29
3	Reply-as-Clara stays, including on muted threads (one send, mute stays on).	Decided — Fede, Aug 29
4	Own lane: separate design, separate harness, separate priority — not coupled to reply-necessity or the send-chokepoint work.	Decided — Fede, Aug 29
5	Send-failure semantics: recommend abort-all (marked-failed row, operator retries deliberately) over auto-retry of the whole operation — a takeover is a human act; the human should stay in the loop on its failure. Note: transient carrier/API retries already exist below this layer; Sentry is wired throughout the agent — the reconciliation pass reports there.	Proposed — pick at build kickoff
6	Composer v1 scope: text + email threads first; voice callback stays on the existing skill path.	Proposed — pick at build kickoff

The harness (its own rig)

Separate harness, atlas-registered, never shared with the other lanes' rigs:

Kill tests — terminate the process between every pair of steps; state must come back whole (completed or fully rolled back) every time.
The canonical red — replay Aug 28, 22:32 → 22:34: after the fix, the sequence must end with the matter closed, the thread active, and the next reply either the confirmed answer or nothing. The walk-back must be unreproducible.
Four-effect end-to-end on the Willows bench: real rows, real send paths, all four effects verified per run.
Authority — after a takeover, adversarial follow-ups must never elicit a contradiction of the human's message.
Muted one-send — delivers exactly once, mute intact before and after, on every rail the composer can use.

Related pages: Knowing when not to answer (judgment lane) · Mute, end to end (person switch) · send-chokepoint design (separate page, in progress). Sources: PR #6518 body and bench pins, ws8/ws9 build ledgers, clara-takeover skill §6/6b, incident records 2026-08-12 and 2026-08-28.