The operational governance that keeps a live-money ClaudeTag accountable.
Design is done (L1–L6). This lesson is the operator's checklist: how it gets installed, how you cap the money, and — the part that matters most near live capital — how you prove after the fact what it did.
@Claude connect for a 15-minute pairing code; choose workspace-wide or specific channels.[ref §7]/invite @Claude then @Claude summarize this channel.Monthly channel caps run $100 / $250 / $500 / $1,000 (default) / Unlimited / custom to $1M. The behaviour that matters: work over the cap is "declined entirely rather than partially executed."[ref §6] DMs bill to the individual, exempt from the channel cap.
Admins can "view a log of everything that @Claude has done."[ref] For a live-trading estate this is non-negotiable: it's how you reconstruct what an autonomous agent touched, when, and why — the after-action record you already write as RCAs.
Same cadence as your estate audits: (1) read the log on a schedule, not just after an incident; (2) reconcile every mutating action against a human approval in-channel (your confirm-destructive rule); (3) when something looks off, root-cause before patching — never reactively yank access. The log makes "audit before write" enforceable for an agent that acts on its own.
A task would exceed the channel's monthly spend cap. ClaudeTag:
Fail-closed: over-cap work is declined entirely, not partially executed — a clean stop. It doesn't silently drain personal credits or half-run.
For a live-money channel, the audit log's core value is:
The log is the accountability record — your after-action trail for an autonomous actor. It doesn't affect latency, and it complements (never replaces) the spend cap.
You can stand up a ClaudeTag and govern it: Owner-only setup, a deliberate fail-closed spend cap, and a scheduled audit-log review reconciled against human approvals. That's a live-money-grade operating posture.