Good agent style

Hi all,

I have a quick question: Is it considered good Tinderbox style to write agents so that after their action is run on a note their queries no longer match that note? For example, say I want every note with the attribute $MakeBlack set to true to be colored black. This can be done with this agent:

Query: $MakeBlack
Action: $Color=black

However, all $MakeBlack notes would continue to be within the agent. Is it better style to use this query instead?

Query: $MakeBlack & $Color!=black

Or does it just always depend on the context? Any thoughts?

Thanks!

Or, your action in the first example could be

$Color=black;$MakeBlack=false

and then the notes appear in the agent for a moment, $Color would change, and then the notes would disappear from the agent and not return.

Yes, always.

What you want to avoid is agents that “churn” – doing the same action over and over to the same notes. This just builds processing cycles and is inefficient. The solutions include action and/or query changes, as discussed above, or reducing the frequency the agent runs, or using edicts.

The same solutions could be apply to agents that have no actions, just queries – plus the option of not using an agent for queries but use Attribute Browser.

2 Likes

Thanks, Paul — keeping it in mind to avoid agent churn makes the whole subject clear. I appreciate it!

1 Like

Enlightening discussion. So, does it follow that if I have an agent with a query and no action – basically, a simple device for generating aliases of all notes for which a particular attribute is true – than I’ve got a lot of “churn”? At this stage in my Tinderbox learning curve, I still prefer agents that don’t do much, because if I get mixed up this can result in notes winding up in the wrong place. (For example, if I have a Person container some Person notes might not end up in it because other agents besides the Person-collector are acting on other attributes. The Person agent, though, always contains aliases of all Person notes, b/c it is simply Query: $Prototype=“Person”.

I know there are ways around this but at the moment I want to use the doc, not work on this problem. But if I understand this thread I guess I will have to deal with this as the doc gets more complex and the cost of churn rises. Is that correct? And, yes, I do see that one way around my specific example would simply be to use the attribute browser, and maybe I’ll try that.

David

I’ll defer on the particulars to those here with more insight, and everything is situational, of course, but I don’t think you’ll see a major effect on processing load unless your document grows to a very large size (multiple 1,000s of notes) and you have a lot of agents running. You shouldn’t feel you should avoid agents – they are after all a powerful feature of Tinderbox. As noted, you can mitigate things, if ever needed, by lowering agent priority

or using an edict.

Thanks for the reminder about priority. That’s helpful.

Btw I am not really avoiding agents, I am just being cautious about having agents do a lot to notes until I better understand how to order agent interactions with each other. I have a bunch of agents that move notes (for instance, removing completed tasks from a “To Do Soon” container) and that works fine. But when one agent wants to move a note to one place because of one query, while another wants to move the same note to a different place based on its query, I can get a little confused. I guess this means I need to understand how to order agent actions.