Ask an AI chat tool: "How do I change the sales order approval workflow in Dynamics 365?" You will probably get a tidy, sensible answer. Then try to apply that answer to your own system. Chances are you will get stuck somewhere.
The reason is simple. The model knows Dynamics 365 as well as the internet does. It knows nothing about your system.
Every F&O installation is a little different
We have been working on Dynamics projects since 2005, and we have hardly ever come across an installation used purely as standard. Every company has its own fields, its own tables, its own workflows, sometimes a small MES module it wrote itself. These customisations were usually built over years, by different consultants, with different habits.
A general model cannot see this layer. It gives you a standard answer, and that answer does not take your custom fields, extensions and business rules into account. The result is a solution that looks right but is wrong for your system.
Three layers of knowledge
When we work with Claude, we feed the model from three separate sources of knowledge:
1. Microsoft's standard
We split the source code of Microsoft's standard F&O packages into chunks and keep them in a local vector database. Instead of guessing how a standard class or table works, Claude reads the actual code. To be honest about it: this layer does not contain everything. At the moment it holds the Foundation, Platform and Common packages. Application Suite, the largest package, is not included. For that part, Claude still looks directly at the code in the development environment.
2. Your customisations
A catalogue of your custom objects and the documents for your project sit in a separate collection. Claude can also read the code in your development environment directly while it works. So when a new request comes in, the first step is to check whether your system already has something that does the job.
3. Our team's experience
The traps our developers run into, and how they got out of them, build up in a shared repository. When Claude starts a task, it knows that repository too.
Keeping the two sources apart
One important thing we learned while building this: do not give your code and Microsoft's code the same weight.
Customer code is not always code worth copying. Over the years it can pick up rushed solutions that go against the standard. If you tell an AI "this is how it's done in this system, do it the same way", it will carry old mistakes into new code.
So we separated the roles. Microsoft's standard is the design guide. Your code answers the question "what do you already have?". Claude writes a new customisation to fit your structure, but takes the way to write it from the standard.
What about your data?
One consequence of this structure is that most of the knowledge layer stays local. The vector database and the embedding generation run in the customer's environment. But we should say this clearly: while Claude works, the code snippets and query results it reads, in other words the context of the task at hand, are sent to Anthropic's API. Saying "no data ever leaves" would not be true. The right approach is to work knowing what goes where, and to keep it limited.
In short
AI not knowing your system is not a flaw. It is the natural state of things. A consultant on their first day does not know your system either. The difference lies in how, and how consistently, you give them that knowledge. In our experience, good results come less from a good model than from well-built context.