I’m building AgentReady, a platform that makes existing ERP installations queryable and actionable by AI agents.
The current prototype works end-to-end with ERPNext:
Connect an ERPNext site.
Run automatic discovery of its actual DocTypes, reference data, reports, fields and customizations.
Publish the discovered capabilities as machine-readable MCP/API tools.
Let an authorized agent query ERP data and create or update documents through governed actions.
Apply policies, approvals and audit logging around execution.
The main design decision is that AgentReady does not normalize every ERP into a fixed universal model. It keeps a small set of universal actions such as search, get, create, update, submit and run_report, while exposing the exact schemas discovered from each installation.
I’m aware of the excellent @casys/mcp-erpnext project, which provides a comprehensive set of prebuilt ERPNext tools. AgentReady explores a different architecture: instead of maintaining a large ERPNext-specific tool catalog, it discovers each installation’s live metadata and exposes a small generic tool surface backed by installation-specific schemas and policies.
ERPNext is the first working connector. Additional ERP platforms are planned, but they are not implemented yet.
I would particularly appreciate feedback from people running customized ERPNext installations:
Does discovery correctly represent your custom fields and DocTypes?
Which permissions and deployment model would you require before allowing agent access?
Which real ERPNext workflow would be most useful to test through an agent?
Would anyone be interested in testing this against a customized non-production site?
The recent discussion about Frappe as a strong harness for agents strongly resonated with this approach: the ERP remains the system of record, while agents receive a governed machine-readable interface to it.
AgentReady does not copy or store ERP business data. It discovers metadata and schemas; runtime requests execute against your connected ERP under your credentials and policies.
The live-discovery call is right. prebuilt tool catalogs describe a vanilla erpnext and nobody runs a vanilla erpnext. every real install is custom fields and custom doctypes, so discovering the actual
schema is the only honest way to do this.
Q1 — DOES DISCOVERY REPRESENT CUSTOM FIELDS CORRECTLY
the trap isnt the fields, its the rules. discovery sees the schema, it doesnt see the server scripts, client scripts, and validations that give the fields their meaning. a create that passes the discovered
schema can still bounce off a server validation, and worse, one that passes both can still be a document the business never wanted.
so represent custom fields, yes, but tell the agent what you DONT know: discovered schema is shape, not law. the law lives server-side and your error handling is the real interface for it.
Q2 — PERMISSIONS AND DEPLOYMENT MODEL
your self-reply says runtime requests execute “under your credentials and policies.” thats the weak point, not the strength. customer credentials are almost always over-broad, an erpnext api key/secret
carries that users ENTIRE permission surface. hand that to an agent and your governance is riding on whatever sloppy role the customer happened to have.
the agent needs its own identity, scoped to LESS than any human. per-connection scope, deny-biased, minted for the purpose, not borrowed from a person.
attribution is the second half. if every agent action lands in the audit trail under one connection credential, the WHO and the WHY are gone. carry the intent through: which agent, which request, what it planned to do, into something the trail can answer for later. you cannot retrofit attribution onto old entries.
and weight your actions differently. search/get/run_report are one risk class. create-as-draft is another. submit is not a verb like the others: in erpnext, submit is the irreversible ledger event. a flat
action list with uniform governance treats tuesday and dynamite the same.
from running automation against a live erpnext: start read-only. run_report and search deliver value day one with zero blast radius, and they exercise your discovery against real custom schemas.
first write test: draft-only creation. material request or sales order as DRAFT, agent creates, human submits. rich validation surface, ledger untouched, every mistake reversible with a delete.
test submit last and gate it hardest. anything that touches the stock ledger or the accounting ledger is where a governance product earns its name or loses it.
Q4 — TESTING AGAINST A CUSTOMIZED NON-PRODUCTION SITE
i run a lab erpnext alongside my production one, customized, non-production by design. could point it at your discovery and tell you what breaks.
youre building the door, im building the vault behind it. different layers, same conviction: agents touching an erp need governance thats machine-checkable, not vibes.
Thanks, this is exactly the kind of feedback I was looking for.
I agree that discovered schema is shape, not law, but that boundary is intentional. AgentReady does not replicate or replace ERPNext business logic. It discovers the callable interface, governs access to it, and leaves server scripts, validations, workflows, permissions and accounting rules authoritative inside ERPNext. When ERPNext rejects an action, that structured failure becomes part of the agent interface rather than a rule duplicated in the gateway.
AgentReady also does not expose ERP credentials to the agent. I agree that production connections should use dedicated least-privilege integration identities, while agents and human approvers should have separate identities and permissions. That separation is not fully implemented in the prototype yet.
Risk is already differentiated internally: reads are low-risk, draft writes require approval, and submit is treated as high-risk.
I’d definitely like to test discovery against your customized lab site. Starting read-only is perfect. I’ll send you the connection requirements privately.
the structured-failure answer is the right. dont duplicate the law in the gateway, let erpnext stay the authority and surface its rejections cleanly. thats the architecture i was hoping you would describe.
two things to keep pressure on:
“does not expose ERP credentials to the agent” answers visibility, not scope. whether the agent sees the key or your gateway wields it on the agents behalf, the permission surface is still whatever role that
borrowed key carries. hiding the credential doesnt shrink it. until the dedicated integration identity ships, your governance rides on the customers sloppiest role, so i would put that above everything else
on the roadmap. its the floor the rest stands on.
attribution didnt get an answer, and its the item with a deadline. every action the prototype executes today under one connection credential becomes an audit entry that will never know which agent acted or why. you cannot backfill that later. schema discovery can improve any time. identity and attribution cant wait, because skipping them poisons the trail retroactively.
on the test, still in. rather than pointing you at my lab directly i will stand up a disposable v16 site for it. synthetic data, a representative set of custom fields plus a couple of custom doctypes so
discovery has something real to chew on, and a dedicated read-only api key minted for the test with an expiry date. same doctrine i want your product enforcing: scoped identity, purpose built, nothing
borrowed. post the connection requirements here in the thread rather than dm if you can. anyone else evaluating this will want to see them anyway.
That is exactly the kind of test environment we need.
Current connection requirements:
Frappe/ERPNext v16 site reachable over HTTPS
a dedicated API user with API key and secret
read access to DocType and Report metadata
read access only to the business DocTypes and reports included in the test
AgentReady will also keep the connection read-only at the gateway layer. Since the site is disposable, synthetic and the key is scoped and expiring, public test credentials are fine if you are comfortable posting them here or on demand in dm for those who want to test.
Your attribution point is correct. Today the audit identifies the AgentReady account behind the API token, but multiple agents sharing that token would collapse into one identity. Per-agent scoped tokens, expiry/revocation, declared purpose and durable attribution need to come before further discovery improvements.
Once the site is ready, I’ll run discovery against the custom fields and custom DocTypes and post the results here.
it meets what you listed in post 7 — public https, dedicated api user, metadata read access. customized on purpose too, custom fields and two doctypes that exist nowhere else, so discovery has something real to chew on.
say the word and your key is minted, read-only, scoped, with an expiry, yours alone.
you also said scoped tokens and durable attribution come before further discovery work. i think that is the right call. the write cases will be waiting on the same site when they ship, same data, run side by side.
