I sense the word ‘code’ is part of the confusion here as it sort of has two different meaning, contextually. Queries, as stored in $AgentQuery are written in action code syntax, but essentially a subset of the whole of action code as used in app automation. So, it helps to have a firm grasp of the basics of queries in order to understand how/where to make dynamic changes to the targetting of the query, as is your desire.
As simply as I can put it, the query must be a single complete expression, i.e.
inside("Projects")
No semi-colon terminator is used (it is ignored if put in). Also you cannot have multiple expressions. This is not correct:
inside("Projects");$Prototype=="Person"; NO!
But in a query you can have multiple terms (questions). for that you must use a & (AND) or | (OR) join between each term. For instance, trying the the last above using those types of joins:
inside("Projects") & $Prototype=="Person" (an AND join)
inside("Projects") | $Prototype=="Person" (an OR join)
White space around the join characters is optional.
Working at this sort of level, it doesn’t matter whether you type directly into the Query Inspector (or use Get Info/agent) as the single or multi-term expression used is complete, so to speak.
The first level of allowing some dynamic change of the query’s meaning is to use a test value that is stored in an attribute. then, altering the attribute value alters the query’s meaning. Most usually, this involves a String type attribute, but you can test most types (Number, Boolean, Date). Whilst starting out avoid trying to test lists (List or Set) or dictionaries (Dictionary) as that is more complex usage - keep the latter for after you understand the basics.
So, if you want to test for a prototype the varies with the task at hand (i.e. the tested value of $Prototype needs to differ) you can store the value in the agent (any suitable attribute, here $SomeAttribute) and use the agent designator to address it:
inside("Projects") | $Prototype==$SomeAttribute(agent)`
Your query can also read an attribute value stored in some other note:
inside("Projects") | $Prototype==$SomeAttribute(“My Config Note”)`
But, do not use this:
inside("Projects") | $Prototype==$SomeAttribute`
Why? Because now the value of $SomeAttribute is being read from the note currently being queried and not from the agent’s value, as you might have assumed. This may seem counter-intuitive at first encounter but will make sense once you use agents a bit.
The neat part about the agent designator use is if you make the tested attribute, e.g. here $SomeAttribute, a Displayed Attribute in the agent you can alter its value by hand in the Displayed Attributes table and the meaning of the query is automatically updated and used by the agent.
You can even use action code elsewhere in the doc to set the agent’s $SomeAttribute value and achieve the same effect. By the same token, code can be used to write a complete query (as in the terms described above) into the agent’s $AgentQuery, thus altering the query run. I’d suggest these latter code based approaches you leave for now. Using the agent designator should get you started and you can loop back to a more code-based automation if the need arises, by which time you’ll likely have a better handle on agent and action code.
Lastly, if you haven’t looked at the Getting Started with Tinderbox PDF (accessed via the app’s Help menu) then it’s well worth a read/skim through as it covers the basics of queries.
It’s just Murphy’s Law that often our initial desired use of a feature isn’t the basic form and the form we want requires some understanding of the basics for the explanation of our desired form to make sense. 
HTH
