In short. 'No'. Actually, in this sort of scenario, agents aren't the way to go. Rather, use edicts which are rules that run less intensively so you don't cane performance. Like rules, edicts are action code run by a note on itself. The edict code ($Edict) can be generic and thus set via a prototype. Getting every item (note) to find mentions of itself of itself doesn't scale well; I say this from experience with files with 0,000s of items. Edicts are the least intensive method of doing this and I'd recommend that if using on 00s of notes that you design your code so it only runs if the $EdictDisabled isn't set in the prototype - i.e. turning off the prototype edict you do the same for all notes using it.
If you haven't yet tried out Attribute Browser view, I'd do so as that might answer some of your issues.
Normalising author names is a chore. For things like books by all means store the author name as published but also store separately the canonical name you've chosen for that author and do all your querying/linking on the latter to ensure lack of ambiguity. Thus a person note would use the author's canonical name as the note's title and query book/film/etc notes based on their stored canonical author name(s) as opposed to the as-published variant. This is important as authors may be multiple and are therefore a list-based attribute, in your case a Set.
As Sets and Lists can only query-match via
.contains() based on using complete values - i.e. not particle name matches) have the same author name in both a person and the book they wrote is an important step towards your task.
What's not clear is how you intend to 'collect' the eventual data in the person-type note. As the $Text? As another list? As a set of links? Any suggestions here need clarity as what you want to do with the info. Read it (i.e. needs to be presented in a readable form, such as $Text)? Analyse it for further info such as counts of occurrence? do thing? ...etc.
If you're committed to agents, don't make an agent pr note, for performance reasons above. However you could make a note whose query and action used attribute values drawn from the agent. For example instead of hard-coding a person name into the query, set a key attribute in the agent to an attribute listing all the person notes. Thus you might use $MyString to store those values and then query for
CanonicalNameSet==$MyString(agent). Any note whose (user) Set-type attribute of canonical author name(s) matches the name currently set in the agent's $MyString will return a match.
In summary, there's lots of detail above. Don't try and understand it all at once. I'd recommend making a test file or copy of your work thus far with the bulk of the detail stripped out so you can test the ideas above. Avoid the temptation to test complex and CPU-intensive actions you don't yet fully understand on your whole dataset. It makes things slower and takes longer to figure out when things go wrong.
HTH and do follow up on the specifics of the above that don't yet make sense.