Builder Guide
Rating GoClaw and improving results
Every action can be rated, every suggestion explains itself — so poor results can be diagnosed, not just endured.
An assistant you can't grade is an assistant you can't improve. GoClaw is built the other way around: every piece of work it does generates signals, every suggestion keeps a record of why it was made, and the path from “that was a bad draft” to “here's exactly what to change” is a read, not a guess.
The signals, explicit and implicit
Explicit ratings. After an action executes, the user can rate it one to five, mark whether it was helpful, and leave a comment. Ratings attach to the specific execution — not to the assistant in general — so a 2-star is always a 2-star on something inspectable.
Implicit responses. Richer still: every suggestion the assistant makes records its fate — accepted, dismissed, ignored, or modified and accepted — along with where it ranked in the list and how confident the AI was at the time. Nobody has to remember to rate anything for this signal to accumulate; using the assistant normally produces it.
Rejection reasons. When an approver rejects a queued action they can say why, and the reason is stored on the action and in its event trail. A week of rejection reasons is a tuning brief written by your own users.
| Response | What it tells you |
|---|---|
| Accepted as-is | The draft was right. The baseline you're protecting. |
| Modified, then accepted | The most valuable signal there is: the idea was right, the execution needed polish. Read the edits — they're your users showing you the target. |
| Dismissed | Wrong action for the moment. If one action type is dismissed persistently, its triggering conditions are too broad. |
| Ignored | Not even engaged with. Chronic ignoring means suggestions are surfacing at the wrong time or place, not just with the wrong content. |
Diagnosing a poor rating
What makes diagnosis possible is that the assistant's homework is retained. Each suggestion stores a snapshot of the data it saw at that moment and its reasoning — the factors it weighed, how heavily, and the alternative actions it considered with their scores. Each execution stores a step-by-step trail: every step's input, output, duration, and any error. So a bad outcome decomposes into one of three findings:
| Finding | You'll see it in | The fix lives in |
|---|---|---|
| It saw the wrong data — the snapshot is missing or stale relative to reality | The context snapshot vs. the actual record at that time | Data quality and what context the action is fed — not the AI's behavior |
| It reasoned poorly — right data, wrong weighting or wrong alternative chosen | The reasoning's factors and the scores on alternatives it passed over | The behavior configuration: prompts, factor emphasis, and the conditions that trigger each action type |
| It executed badly — right decision, a step failed or produced a poor artifact | The execution steps: which one erred, how long it took, what it emitted | The specific step — a template, a connected channel, a timeout |
Start every diagnosis with the reasoning, not the output. “What did it think it was doing, and was that reasonable given what it saw?” separates a data problem from a judgment problem in about thirty seconds — and they have completely different fixes.
Closing the loop
Diagnosis without a safe way to ship the fix just moves the frustration. The improvement loop here is deliberately gated:
- Read the signals — ratings, response patterns, and rejection reasons, sliced by action type. One action type usually accounts for most of the pain.
- Diagnose with the stored evidence — snapshot, reasoning, steps, as above.
- Adjust the behavior configuration — the prompt, the triggering conditions, the context provided, or simply disabling an action type that isn't earning its place.
- Prove it before it ships — run the candidate configuration through a Harness Pack that includes scenarios built from the failures you just diagnosed. A fix that passes the scenarios that used to fail is a fix; anything else is a hope.
- Promote and watch the same metrics — the ratings and response rates that flagged the problem are the same ones that confirm the cure.
Feedback also works passively: user responses feed suggestion ranking over time, so consistently dismissed suggestions sink and consistently accepted ones surface earlier — the feed self-corrects between your deliberate tuning passes.
The numbers worth watching
- Acceptance rate by action type — the headline. A type below your comfort line is a tuning candidate; a type near zero should be switched off until fixed.
- Modified-and-accepted share — high is actually encouraging early on (right ideas, improvable drafts); the goal is converting it into accepted-as-is by learning from the edits.
- Rating trend across a configuration change — the before/after that tells you whether a tuning pass worked in production, not just in the Harness Pack.
- Ignore rate — the placement-and-timing metric. Content fixes won't move it; where and when suggestions appear will.
Capability review: 2026-09-14. For exact current technical availability, use the generated API Map and first-class module inventory.