Ask a business assistant "which distributors are below their credit limit but still ordering?" and it has to do something unglamorous before it can do anything clever: work out which of several hundred entities holds distributors, which field holds the credit limit, how orders relate to accounts, and what "below" means when the platform stores a limit, a utilised amount and an available balance separately.
None of that is in the model's weights. It is in your configuration — and in a platform where every tenant can add entities and fields, it is different for every customer.
Why fine-tuning is the wrong instinct
The intuitive fix is to train a model on the schema. It fails on three counts, and the third is decisive.
The schema changes constantly — an admin adds a field on Tuesday and the assistant should know about it
on Tuesday, not after the next training run. It is per-tenant, so training would mean a model per customer.
And most importantly, the schema is not the hard part: names are. A field called
PartnerAccountId is unambiguous to the database and useless to a model reasoning about a
distributor unless something states the connection.
What we do instead: describe the model, in the model
The platform carries a first-class description layer alongside the metadata. Entities, fields, actions and reports can each hold an AI description — a plain-language statement of what the thing is, what it is for, and the traps in using it.
The difference between a schema and a good description is the difference between:
- Account. Fields: AccountType, CreditLimitAmount, UtilizedLimit, AvaliableLimit.
- "Account is any commercial party — customer, distributor, supplier — distinguished by AccountType. Credit is held as three values: the sanctioned limit, the amount consumed by open documents, and the remainder. To find accounts near their ceiling, compare utilised against sanctioned rather than reading the available balance, which is recomputed at posting."
The second is what lets an assistant get the query right first time. It also encodes the kind of knowledge that normally lives in the head of whoever has been at the company longest.
Task knowledge, separately
Descriptions explain the model. They do not explain how to accomplish something, and those are different kinds of knowledge.
So there is a second layer: task cookbooks, retrieved on demand — short documents covering how to answer questions in a domain, which entities to prefer, which relationships to traverse, and when to run an existing report rather than assembling the answer from raw data. That last instruction matters more than it sounds: a platform with well-built reports usually has a correct answer already, and an agent that reconstructs it from tables will produce something subtly different from what the business considers official.
Retrieval, not stuffing
The obvious implementation — put all of it in the prompt — does not survive contact with a real tenant. Hundreds of entities with descriptions is far more context than any question needs, and paying to process it on every turn is both slow and wasteful.
Instead the agent has tools to look things up: list what entities exist, describe one in detail, inspect its relationships, search the knowledge base for task guidance. It fetches what a specific question needs. The pattern is closer to how a competent new joiner works — not memorising the data dictionary, but knowing where to look and what to look for.
This also has a security property that matters: what an agent can discover is bounded by what the asking user is permitted to see. Grounding runs inside the same permission model as everything else, so the description layer cannot become a side channel to the shape of data a user has no access to.
The part that is genuinely hard
Description coverage is a content problem, not an engineering one, and it is the honest constraint of this approach. A platform ships with hundreds of entities and thousands of actions; describing all of them well is a substantial body of writing, and an out-of-date description is worse than none because it is confidently wrong.
Two things help. Descriptions are versioned alongside the metadata they describe, so a field change and its description move together. And generation is treated as an ongoing editorial process reviewed by people who know the domain, rather than a one-time exercise — the goal is prose a new colleague would find useful, which is a higher bar than prose a model can parse.
What we would tell another team building this
If you are building an assistant over a configurable business platform, the interesting work is not prompt engineering and it is probably not fine-tuning. It is writing down what your own data means, in a place the system can read, and keeping that current.
The useful test: hand your entity and field descriptions to a competent person who does not know your product, and ask them to answer a real question using only those. If they cannot, no model will — and if they can, you have most of what grounding requires.
Related: Sense Assist · AI Studio · App Builder