As I’m getting more comfortable with using Tinderbox, I’m now exploring ways to bring some order in my notes. Making my first baby steps with using Agents.
For the time being, I’m working in outlook view mostly. (98%)
how can I best re-locate an agent? What would be the way to modify $Path? Action code? If yes, where can I find some examples?
thinking path:
assuming that the results of an agent are shown as child-aliases beneath the agent, that also means that if I move an agent, I will also move the resulting aliases - Is this train of thought correct?
assuming we would prefer to gather “ALL” agents in the same place, e.g. tucked away within the Hints location, could I then “also” visualize these results elsewhere?
Reasoning would be to later on look into what I can do with a dashboard, then showing the agent(s) in my preferred location.
I’ve experienced the impact of agents / automation on my Mac, (2018 mini, 32 GB ram) so I’m very much interested in learning:
to find where an agent or agents are
how to control their behaviour (cpu wise) by setting $AgentPriority?
You can move an agent in exactly the same ways as other notes. In most documents, agents are comparatively few; moving them by dragging the agent where is ought to be is fine.
If you want to put all your agents in a single container, $Container is ideal.
Yes. This is also true of moving any container; dragging a container to a new place implies moving its descendants.
It’s worth noting that when you alias a container—note or agent—you don’t see its children (or agent child aliases), just an alias of the container. So, in Outline, if you make an alias of an agent and more the alias elsewhere in the outline, you only see the content of the agent’ note. To see its children, you have to go look at the original. It’s obvious once you know, but not necessarily beforehand.
That behaviour is documented here: AgentPriority. Is there an aspect of that which you are unsure.
Tip: turn agents off ($AgentPriority) once run and the target notes are not changing. Once off an agent retains any matched aliases present when last run.
If you think agents are a performance issue this is most often a tell the you are using agents inefficiently. Likely much of the information for which you are making individual agents is catered for by one or several tabs using Attribute Browser view.
If you have 20 agents all search the same set of notes (be it all, or just a part of the TBX) and then applying one extra differing item, then the efficient way is to make one agent that search the wider set of notes. Then for the 20 individual conditions those search the first agent filtering for the individual condition.
Let’s say the TBX has 1000 notes of which the first query matches 100 notes. I the opening scenario, 20 agents search all is 20,000 searches per agent cycle. In the second method is is 1,000 + (20 x 100), i.e. 3,000. We’re now doing 15% of the number searches and still getting the same result, albeit with 21 agents. Attribute Browser is an even better method.
Tip: different views are still looking at the same data, just visualising it differently. Tabs in the background don’t do anything so replacing loads of single purpose agents with one Attribute Browser view tab removes a lot unneeded searching.
It’s worth trying out aTbRef Fuzzy Search as it might save you having to ask here. For example, open the search and type in ‘CleanupAction’ as the search term. as well as the above you’ll get 6 other results of notes also mentioning CleanupAction.
Thanks a lot for your additional info!
As mentioned, I’m making baby steps..
I’m not sure what you mean here..
In the mean time I’m glad that I’m finally breaking through and using Tinderbox! That is the main gist to me. At least now I can start “thinking” what / how to do things in Tinderbox.
I’m working through Agents and Dashboards too at the moment and noticed the quite large amount of Agents used there too.
Also I realise that Actions can be chained. But as said: step by step!
Argh! Auto-correct strikes. The word (corrected above) is ‘performance’ not ‘preference’.
The reason I note this is a common pattern experienced is that s a user starts using agents and keeps adding more agents but never deleting any. Often these will be something like finding a value in $Tags. So, we successfully find one value. We add a new agent for a different value. Now we have 2 agents. But we have 50 tags and may end up with 50 agents. If we want to see which notes have which $Tags value(s) Attribute Browser view is perhaps a better approach.
Please don’t read this as critique. It is simply that as agents are often the first automation users try out, it can lead unintentionally to using more agents than makes sense (when other better but as yet undiscovered features would be better).
Tip: If adding an agent as a form of search there is no harm in deleting it once done. deletion remove the agent and its aliases but doesn’t affect other content. Coming soon, you will be able to use query-based search in the view Find bar. This should obviate the need for adding agents just for search.
If your agent use is more complex, then more information is needed to try and understand why you have a performance issue and whether it is the agents or something else that is the cause.
