Conditional AgentAction to create new child agents

I’m not sure what the master definition of a smart group is, but essentially, Yes. The query tests all notes (queries can use scoping query terms to limit the number of notes tested) and creates an (child) alias for each note it matches. N.B. an alias in-scope of an out-of-scope original note will still make a match. Matched items only generate a single listing (i.e. alias). so if a note and 3 of its aliases all match the query, the item is listed once. By comparison, in a find(query) action, the process lists the paths od all 4 matches. For agent use, the de-duping makes sense: list (and optionally act on) all the items matching the query.

There is no such think as a ‘smart’’ rule. Rules are rules. Edicts are essentially rules, but applied less aggressively. A rule is simply an action applied by a note/alias to itself. In truth ‘smart’ is generally confusing as it has no consistent meaning for all readers. If you mean ‘smart’ as experienced in some other app’s terminology, by all means mention the app, though be aware the wide range of users here (i.e.v using the same tool but for different purposes) means few may also have used app referred to.

The Agent’s $AgentAction is better compared a (container) note’s OnAdd action. Every time the agent runs, i.e. all the time by default, it adds an alias—as a child to the agent—for each matched item. The agents action is run on the added (OnAdd!) aliases.

In fact, as it runs a lot ,the agent is clever enough to not delete all aliases after each run. Rather, on run #2 onwards, it adds new aliases and deleted those for now non-matching items; aliases of still-matching aliases are retained. The agent action runs on the new and retained aliases but the OnAdd metaphor still holds good.

Absolutely not. An agent can only contain aliases or items matching its query.

Yes. An agent is only ever an (outline) container if it has alias(es) matching its query. Notes however, can be notes or containers. The latter are just notes with nested objects.

Note too that map adornments cannot be containers. Indeed, they are only seen in map view.

I see that @satikusala has already expanded on the Attribute Browser view (‘AB view’) which I think is really what you want to be doing.

Though it doesn’t, IIRC, get into AB view you might still find this demo data of interest: Beatles records: demo with example TBXs