Agent Instructions
The Agent Instructions tab of an Object Definition shows what the AI Agents are told about that object type: an instruction for the type as a whole, and for each of its Custom Properties whether the value is sent to the model and what guidance goes with it.
The tab appears only on URLs where LLM Agents are enabled. Anyone who can see the URL can read it, so an instruction can be quoted when reporting how an Agent behaved. Changing it needs the Manage Agent Configuration permission — renaming an object type and shaping what an Agent does with it are separate jobs, and an Organization can grant either without the other.
What an Agent is sent
When an Agent loads an object of this type as a specification it receives, in this order:
The Object instruction, if there is one.
The Agent instruction of each property that has a value, where one has been written.
The name and value of each property that has a value.
Only properties marked Sent appear at all. A property that is not sent contributes neither its value nor its guidance, and there is no way for an instruction to reintroduce it — telling a model to ignore a value does not stop it being sent.
Sent
Sent is off until you turn it on. A property reaches the model only once someone has decided it belongs in the specification. This is deliberate: values are sent to a sub-processor, and properties recording who tested or reviewed an object — a UAT tester, a peer reviewer, a distribution list — are personal data with no bearing on what the Agent is being asked to build.
Until at least one property is marked Sent, Agents that build from a specification report that the object type has no Agent instructions configured, rather than working from an empty one.
Inactive properties are listed and can be sent. Nothing in the specification path filters on whether a property is active, so an inactive property that still holds values would otherwise be sent without appearing on this page.
Writing the instructions
The Object instruction says what objects of this type are, and how their properties relate to each other. Write it for someone who can see the property values but has never been told what they are for. Two or three sentences is usually enough:
These properties are the specification of an Edit Check. Build the check from them.
Description of Logic is the specification. Everything else either scopes it or says what kind
of check it is; where any of them disagrees with Description of Logic, Description of Logic
wins.
The last clause is the part people leave out and then miss. An agent reading a specification will meet properties that contradict each other, and saying which one is authoritative is something only you can tell it.
A property's Agent instruction says what that one value means. Keep it to the property in front of you — what the values signify, what an empty value means, and anything about the value that is a local convention rather than something that can be guessed:
Dynamic
Dynamic says whether this check changes the casebook. "Yes" means its action adds or merges an
object — Add Form, Add Matrix, Merge Matrix, Set Data Point Visible —
or calls a custom function that does. "No" means it does not: treat Add Form and Add Matrix as
ruled out.
Target FieldOID
The field the check's action fires on. Not necessarily the only field the logic reads.
Query Message
The text of the query this check raises. Applies only to Open Query checks. "N/A" and "NA"
are placeholders, not query text — treat them as unset.
What not to write
Do not restate what the agent can already see. It has the property names and values; it does not need to be told that Description of Logic contains the description of the logic.
Do not describe a property that is not sent. If a value should not reach the model, mark it as not Sent — an instruction telling the model to ignore something does not stop it being sent, it just spends words on it.
Each property's Agent instruction can also be seen and edited on the Custom Property itself; it is the same setting in both places.