How Operator Understands ERP.net

Model discovery, custom attributes, and instance-specific context

An AI agent can only work with data it understands. For most systems that means someone writes a long description of the endpoints. For ERP.net, Operator already knows the model — and checks your instance for whatever is specific to you.

Three layers of understanding

1. The standard model. ERP.net's published entity model — namespaces, entities, attributes, types, and the references between them — is indexed inside Operator and searchable semantically. An agent can ask "where are customer credit limits stored?" and find Crm.Sales.Customers without knowing the name in advance.

2. Your instance's live model. Standard knowledge is not enough when you have added your own fields. When an agent inspects an entity in detail, Operator calls your instance's current model and merges in:

That is why an agent that first inspects an entity can then query CustomProperty_... fields that exist only in your system.

3. Your business context. Model metadata says what a field is, not what it means to you. Entity Instructions let instance admins attach plain-language notes to specific entities — naming conventions, which status values you actually use, which fields to ignore, which document type to pick. These notes travel with the entity: whenever an agent looks the entity up, your instructions come with it.

Discovery comes first

Data tools are gated: an agent must discover the model before it may query it.

search_entity_schema  →  unlocks  →  query_erp_data
get_entity_by_repository_name  →  unlocks  →  query_erp_data

This is deliberate. It stops agents from guessing repository names and attribute names, and it means every query is written against the real shape of your instance — including your custom fields.

The same pattern applies elsewhere: writing data, working with documents, files, and import/export each require reading their instructions tool first. See Technical Reference for the full map.

Finding records, not just entities

Knowing the model is one half; finding the right record is the other. Operator can search your instance's AI indexes — products, companies, and document types — with hybrid keyword and semantic search. So "the pallet wrapping machine we bought from the Italian supplier" can resolve to a product record without an exact code.

Exact codes still take the fast path: a direct lookup by number or code is preferred whenever the user supplies one.

Practical example

You: How many active customers do we have in Bulgaria, and what's their total credit limit?

Behind the scenes:

  1. The agent searches the schema for customer-related entities and finds Crm.Sales.Customers.
  2. It inspects the entity, pulling in your instance's custom attributes and any Entity Instructions you wrote (for example: "Ignore records where IsProspect is true — those are leads, not customers.").
  3. It builds a Domain API query with a filter on country and active status, selecting the credit limit attribute.
  4. It answers with the numbers and a link that opens the same filtered list in the ERP.net Web Client.