Hmmm! Obviously I don’t know what else is set up within the file. (And, of course, Eastgate support is the place that could really tell you, if you were willing to send them the file. My experience over the years is that – unlike, say, Facebook – Eastgate is very good about just looking at structural issues and not in any other way using, storing, or looking at your data.)
Based on your explanation, it seems that the file has to contain some rule, action, agent, or other process that is un-doing what your Remove action does. (You’ve confirmed that your Remove action works, since you initially see the “work” tag. So there must be some other rule or process undoing it, because otherwise the tag would not remove itself.)
So, two suggestions: 1) Send the file to Eastgate, vagueing up some of the data if you want. Or 2) Look very carefully at all prototypes and containers to see what rules or actions might be involved there, including ones you might have forgotten about, that could be having the over-write effect.
Update People who are more expert than I am in query-syntax than I am may have advice on the agent-query itself. It’s conceivable that the query term
$Text.contains("#work") introduces some complexity I’m not aware of, which would mean that the agent keeps re-matching items even when it seems that they should be excluded.
Or, conceivably this is a
.icontains issue? The experts can tell you.