Good agent style

(Galen Menzel) #1

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?


(Paul Walters) #2

Or, your action in the first example could be


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.

(Galen Menzel) #3

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

(David Berreby) #4

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.


(Paul Walters) #5

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.

(David Berreby) #6

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.