DocTypes and fields
Answers should include the relevant DocType, child table, standard field, custom field, and fieldtype context.
guide · Frappe AI
Frappe AI with DocType-aware retrieval.
ERPNext and Frappe agents need site-specific structure, not generic ERP knowledge.
The problem
Frappe context is relational, customized, and permissioned.
A Frappe or ERPNext site is not just a set of docs. It is a live system made of modules, DocTypes, child tables, custom fields, workflows, reports, scripts, roles, permissions, scheduled jobs, and installed apps. Two companies can both run ERPNext and still have very different data models, naming conventions, workflows, and permission rules.
That makes generic AI answers risky. A model may know what a Sales Invoice is in ERPNext, but it does not automatically know which custom fields exist on this site, which workflow state blocks submission, which role can approve Leave Applications, or which app added a child table. For Frappe AI to be useful in real operations, retrieval has to understand the site's structure and the current user's authority.
Workflows and roles
Operational questions often depend on workflow state, transition rules, role assignments, and permission levels.
Reports and scripts
Server scripts, client scripts, reports, hooks, and scheduled jobs can change behavior beyond the visible form.
Installed apps
Frappe suites and custom apps add modules and DocTypes that generic documentation does not cover.
Tenant boundaries
Multi-site and multi-customer setups need memory scope so one site's context never leaks into another.
Muster's approach
Keep the core light; put Frappe intelligence in a capability pack.
Muster's Frappe / ERPNext direction is plugin-owned. The main harness should stay small and fast. Site-specific Frappe context belongs in a capability pack that can connect to a Frappe site, use admin-approved credentials, inspect installed apps, collect DocType and DocField metadata, and build retrieval around modules, workflows, reports, scripts, and permissions.
That model also keeps authorization honest. If an agent reads or writes ERP data, it should act through explicit tools and the paired Frappe user. Frappe remains the authorization authority. Muster's job is to provide the harness around that action: setup checks, scoped memory, token visibility, tool receipts, and eval fixtures for behavior that should become durable.
For a real Frappe AI assistant, the useful output is not just "what does ERPNext usually do?" It is "on this site, with this user's permissions, using these DocTypes and workflows, here is the safe next step." That is the difference between generic chat and an ERP-aware agent harness.
This also changes retrieval design. Frappe data is naturally graph-shaped: modules contain DocTypes, DocTypes contain fields, child tables link back to parents, workflows depend on states and roles, reports depend on queries, and custom apps can override behavior. A useful Frappe AI system should be able to combine docs retrieval with live metadata retrieval and, where appropriate, graph-like traversal of related objects. The point is not to stuff the entire site into a prompt. The point is to retrieve the small set of structural facts that make the answer correct.
For example, an HR assistant on one Frappe site might need to know how Leave Application, Employee, Attendance, Salary Slip, and a custom OxygenHR app relate. Another site may have different fields, different workflows, and different permission rules. A governed harness should keep those contexts separated by site and tenant, then record which facts were used for each answer.
The safest path is incremental. Start with read-only context: docs, installed apps, DocTypes, fields, reports, and workflows. Add permission checks. Add eval fixtures for common questions. Only then introduce write tools, and keep those behind explicit actions, paired identities, and receipts. That is slower than a flashy demo, but it is the route that can survive production ERP usage.
This is also why Frappe AI should be evaluated with real site questions, not only generic prompts. Ask about a custom field, a workflow transition, a report that joins multiple DocTypes, or a permission issue that depends on role assignments. If the agent cannot show where the answer came from, it is not ready for operational use. A harness gives those answers receipts: retrieved context, tool calls, memory scope, token cost, and test fixtures for future regressions.