We migrated our Claw instance last week to a new team plan. The agents are working, but they keep ignoring our core team rules, like "always tag the support channel" or "don't escalate without approval." It's like the migration stripped their context.
We used the official export/import tools. The rules show as configured in the dashboard, but the agents act like they don't see them. Anyone else hit this? Did you have to re-teach every agent from scratch, or was there a fix?
Oh, I saw something very similar during the Claw beta migration tests! The dashboard shows everything correctly, but the agents pull from a cached rule set that doesn't always sync. For us, the fix was forcing a full config reload on each agent, not just restarting them.
In the beta, we had to use a specific CLI command (`claw agent --reload-rules`) after the import. Maybe check if that's still the case? If you're on the new team plan, the UI might have moved that option under "Agent Settings" > "Advanced." It saved us from re-teaching everything.
Did your rule set have any nested conditions? Those seemed to be the most prone to getting 'lost' in our experience.
edge cases matter
The CLI command still works on the new plan, but they moved the UI option. It's now under "Agent Management" > "Tools," not "Advanced." A full reload is definitely the first step.
Nested conditions are a known weak spot. If your rules use "and/or" logic within other rules, the reload might not fully reconstruct the execution order. You might need to break complex rules into simpler, sequential ones after a migration. The cache doesn't invalidate the relationship mappings properly.
Did the beta fix actually persist, or did you have to run the reload after every agent update? We saw the cache corruption recur with minor version patches.
Your cloud bill is 30% too high
The cache corruption after patches is a separate, persistent issue. Even after a full reload, we found the rule mappings degrade if the underlying rule store uses eventual consistency, which Claw's architecture does.
You can mitigate it by versioning your rule sets externally and injecting a hash into the agent's context on boot. We do this via a pipeline that dumps the processed rules as a JSON artifact, calculates an MD5, and forces a reload if the stored hash doesn't match. It's a hack, but it works.
> break complex rules into simpler, sequential ones
This is the real fix. Nested logic never survives serialization/deserialization cleanly in these systems. Treat your rules like idempotent DAG nodes. If rule B depends on rule A, make that explicit in the rule name and order, not in a hidden condition tree.
garbage in, garbage out
That cache sync issue you saw in beta is still around, just moved. The UI option is now under Agent Management > Tools, like user899 said.
The nested condition problem is real, but we found the reload command alone doesn't always fix it if you've got a lot of rule chaining. You might have to flatten them first, then reload, or the cache rebuilds a broken dependency tree. It's like the reload process needs a clean, simple rule set to work from.
Yep, that tracks. We flattened our "escalation approval" rule chain into three separate, numbered rules after our migration. The reload finally stuck.
The annoying part is you have to do this flattening *before* the reload, like you said. If you reload a corrupted tree, it just caches the broken logic again.
data over opinions
Thanks for confirming the UI location. I tried the reload after reading user899's post, but you're right, it didn't stick for our chained rules either.
Flattening first is a great tip. So the process would be: export rules, flatten them outside of Claw, import the simpler set, then run the reload? Just want to make sure I've got the order right before I try it tonight.