Values guide an entity's judgment. Steering rules guide its execution: small, specific lessons such as "when searching code, use the search tool instead of shelling out to grep". Rules come from failures and reflections, earn or lose confidence with use, and load at the start of every session.
#Feedback signals
A signal is feedback on the entity's work. It is either an explicit rating or a sentiment detected in your messages, and it records where it came from: Claude Code, the desktop app, or the portal. Agents record feedback with record_feedback, and get_recent_feedback lists it.
#Failure captures
A failure capture records what the entity attempted, what went wrong, and what was expected, with an optional transcript excerpt and a severity of low, medium, high, or critical.
Failures are created automatically from negative signals: a rating of 3 or lower, or negative sentiment. A rating of 1 or lower is critical, 2 is high, and anything else is medium.
get_unresolved_failureslists open failures.resolve_failurecloses one with a description of the resolution.- The REST API can derive a steering rule from a failure:
POST /api/failure-captures/<id>/derive-rule/.
#Steering rules
A rule has three parts, which read as a sentence:
| Part | Field | Example |
|---|---|---|
| When | trigger_pattern |
When searching code files |
| Do | correct_behavior |
Use the Grep tool |
| Don't | wrong_behavior (optional) |
Run grep through bash |
Each rule also has a category (code_generation, communication, tooling, architecture, testing, debugging, security, workflow, or general) and a scope: entity rules apply to one entity, system rules to every entity in the workspace.
Agents create rules with create_steering_rule and read them with get_steering_rules. Rules are not protected like values: a new rule applies immediately. The tool's own guidance asks agents to capture recurring classes of situations only, and not environment problems, one-off tasks, transient errors, or claims that a tool "doesn't work".
#Confidence
Every rule starts at 0.5 confidence. When a session records which rules it applied, the rules' confidence moves with that session's feedback:
- net positive feedback: +0.05
- net negative feedback: -0.10
A rule below 0.3 is flagged for review. A rule that reaches 0 is deactivated. Rules are ordered by confidence, then by how often they were applied, so the most trusted rules come first.
#Where rules show up
- Startup:
get_startupincludes the active rules, so every connected agent sees them. - REST:
GET /api/context-rules/returns the rules as Markdown, with an ETag so tools can cache them. - Portal: the entity's Activity tab lists rules and failures. You can turn a rule off there.
#Reflections
A reflection is a structured self-review. It has three assessments:
- Identity check: are recent actions consistent with the entity's values?
- Rule audit: do any rules contradict each other, or could they be merged or narrowed?
- Growth assessment: what patterns keep coming up?
A reflection can propose new rules, value adjustments, and pairs of conflicting rules. Proposals go through the same owner review as identity and value changes, on the Activity tab. See Owner-approved changes.
Reflections have a trigger: weekly_review, post_failure, or entity_initiated. Each nightly dream checks whether a weekly review is due, and the rules context from /api/context-rules/ tells the entity when one is. Agents submit reflections with submit_reflection; it skips a second weekly review in the same ISO week.
#A healthy loop
- You react to the entity's work: rate it, correct it, or say what went wrong.
- Negative feedback becomes a failure capture.
- The entity, or you, turns a recurring failure into a steering rule.
- Sessions that apply the rule adjust its confidence.
- Weekly reflections prune, merge, and question the rules, and propose value changes for your review.
Review the Activity tab now and then. Rules with low confidence, or rules that no longer match how you work, are worth turning off.