Builder Guide
GoClaw in depth: acting on a user's behalf, under control
The complete control stack that lets the assistant do real work without ever being able to run away with it.
GoClaw is the platform's per-user assistant: it watches the conversations routed to a user, prepares replies and next steps, and — with approval — carries them out. The question every builder should ask before enabling it is the right one: what stops it from getting out of control? The answer is a stack of independent limits, each enforced by the platform rather than by the assistant's good behavior. For GoClaw to misbehave, every layer would have to fail at once.
Layer 1 — It sees only what its user sees
GoClaw is bound to one user account and has no wider identity in tenant data. Every read is constrained by that user's tenant, DataRole, record, field, and location permissions. A user scoped to one location gets an assistant scoped to one location. AI-specific CanAiReadRecords, tool policy, and quota checks can narrow the assistant further; nothing about being an assistant widens access by a single record. Fields marked secure are structurally invisible because encrypted values never enter search or AI context.
Layer 2 — It only works channels you've handed it
The Universal Inbox can receive all configured outside email, SMS, web-form, and other inbound communication, including items still waiting in Unsorted/Triage. GoClaw does not roam all of it: it engages only on items and queues routed to its user and explicitly enabled for assistant preparation. Shared and role-routed work stays human unless policy and assignment deliberately bring it into that user's scope.
Layer 3 — It proposes; a person disposes
Every action GoClaw wants to take — send this reply, create this task, update this record — lands in its user's approval queue first. The user edits, approves, or dismisses. An unapproved proposal does nothing, forever. This is the default and there is no “fully autonomous” switch to flip by accident.
Layer 4 — A hard daily budget, enforced by the platform
Each assistant has a maximum number of actions per day, checked server-side at the moment an action is queued — not in the assistant's own logic, where a bug could ignore it. At the limit, the platform refuses further actions with error 51005 and they wait for the daily reset. Even a hypothetically misbehaving assistant is mechanically rate-capped.
Layer 5 — Everything it makes is labeled
Every artifact GoClaw produces — drafts, records, tasks — is tagged with what created it and which conversation it came from. There is never ambiguity about whether a person or an assistant did something, which matters the day a customer asks.
Layer 6 — Behavior is tested before it ships
The behavior configuration an assistant runs can be gated through Harness Packs — scored scenario suites a configuration must pass before promotion. Quality is a gate, not a hope.
Layer 7 — Its work is graded, and the grades go somewhere
Every executed action can be rated, every suggestion records how users responded to it, and the assistant's reasoning is stored for inspection. Poor results are diagnosable and fixable, with Harness Packs gating each fix before it ships. See Rating GoClaw and improving results.
What this means in practice
| Worry | Why it can't happen |
|---|---|
| “It'll read data it shouldn't” | It has no access of its own — it reads as its user, minus secure fields. |
| “It'll send something embarrassing” | Nothing sends without a human approving that specific message. |
| “It'll go haywire and spam actions” | The daily quota is enforced by the platform, outside the assistant. |
| “We won't know what it did” | Full attribution on every artifact, plus the standard audit trail. |
| “It'll wander into channels we didn't intend” | It only operates on lines explicitly marked assistant-managed. |
Rolling out well: start with one or two users, a conservative daily quota, and only their personal lines. Widen after a week of reviewing what actually lands in the approval queues — the queue history is your evidence.
Capability review: 2026-09-14. For exact current technical availability, use the generated API Map and first-class module inventory.