An ERPNext AI agent that understands DocTypes, fields, workflows, and permissions.

Point a generic coding agent at an ERPNext instance and the failure is consistent: it answers about ERPNext-the-open-source-project rather than about your site. It suggests a field that exists in the upstream DocType and not in your customised one. It writes a query against a table name it inferred from a doctype label. It proposes a workflow transition that your workflow does not have. None of this is a reasoning failure. It is a retrieval failure, and it happens because the context an ERP agent needs is not in the model's weights and is not in the files on disk either.

The context an ERPNext AI agent actually needs

ERP context is relational, permissioned, and constantly customised, which makes it a genuinely harder retrieval problem than a codebase. Before answering or acting, an agent needs to know which site it is on, which apps are installed and at what versions, which DocTypes exist and how they link, which fields are on those DocTypes today including custom fields, which workflows are defined and what states and transitions they permit, which reports and scripts already exist, and — critically — which roles and permissions apply to the person asking.

That last one is where most ERP assistant projects quietly go wrong. An agent that retrieves across everything and then answers for whoever is asking has become a permission bypass with a chat interface. The retrieval boundary has to be the permission boundary, not a filter applied afterwards to the answer.

A pack, not a bigger core

Muster keeps the site-specific part in the Frappe / ERPNext capability pack rather than in the harness. The core stays a run loop with memory scoping, tool policy, and a token ledger; the pack knows about DocTypes, fields, modules, reports, scripts, workflows, and the setup checks that tell you when a connection is misconfigured before a run depends on it. This is deliberate on both sides: the harness does not accumulate ERP knowledge it cannot test, and the pack can evolve at the speed of the ERP rather than the speed of the framework.

It is also, honestly, the one place Muster's integration is deep rather than declared. Of 34 capability packs, only two are substantial — and this is one of them. Anywhere else on this site that Muster claims integration breadth, treat it as thinner than it sounds.

Memory scoped the way an ERP is scoped

Multi-tenant ERP deployments are the case scoped memory was designed for. Facts learned while working one company's books must not surface while working another's, and inside a single company, what a finance role saw should not become retrievable by a warehouse role. Muster's lanes — tenant, workspace, user, role, session — are filtered at retrieval time by what the current run is entitled to see, with tests whose specific job is to try to make one lane leak into another.

Changes to an ERP need an audit trail

An agent that edits client scripts, server scripts, or custom fields is changing a system of record. Muster derives the file-change set from git and the filesystem rather than from the agent's own report of what it did — measured live against Codex across five runs, that self-report channel reported zero of the real edits while all of them landed on disk. The observer caught the equivalent edit in 86ms with a diff verified by git apply, and emitted a receipt hash that reproduces byte-identically on a machine that was never there. For a system an auditor will eventually look at, that is the difference between a log and evidence.

Guide: DocType-aware retrieval -> How file changes are observed -> How memory scoping works ->