Concept
What exactly is being tested, for whom, and where the line is drawn.
The question
Could a company build its own ERP with AI agents? Shaped to its own processes, extensible and maintainable.
What this is not
It's not about building a multi tenant cloud ERP to compete with the big vendors. It's not a product and it will not be sold. It's a minimal ERP core, used as a realistic test case for agentic engineering.
- Minimal ERP: master data, documents, processes, stock, open items
- Modern interfaces: API, events, webhooks
- Modular: extend without touching the core
Who is involved
Even a single installation has three kinds of people with very different rights. An open source scenario, where companies download, run and extend the system themselves, depends on the same separation.
Three scenarios
Build your own
A company builds its own ERP with agents. One installation, one operator, no multi tenancy.
Open source ERP
Download, self host, customize, update. Requires strict extension points so updates don't break customizations.
Extension marketplace
Reusable extensions and standard workflows to install. Not built, but the extension format is ready for it.
Rules of the experiment
Fixed input
The same specs go into every framework and model I compare.
Fixed bar
The requirements and reality checks were published before the first run.
Logged interventions
Every time I step in, I log what the agent missed and why.
Results either way
Successes, failures, costs and time are published, including when they prove me wrong.
Code stays private
Specs, configuration excerpts, diagrams and numbers are public. The product is not.
Simple examples first
My examples are simplified. A realistic reference model from ERP practice is worked out with AI and reviewed.
Roadmap
Small milestones that each run end to end. Every one is built by agents from a spec and measured against the reality map.
- next
M0 Mini core
Definitions in, generic resource API out, OpenAPI and Scalar
- planned
M1 Relations and packages
refs, lines, expand, views, package format, standard types and trade package
- planned
M1a Validity and prices
prices by channel and currency, discounts, attributes, as of queries
- planned
M1b Front door
API keys, accounts, groups, roles, scopes, rate limits
- planned
M2 Traits I
auditable, stateful, numbered, approvals
- planned
M3 Events
outbox, Pub/Sub, webhooks, jobs
- planned
M4 Functions
templates, PDF, mail, files
- planned
M5 Process runner
steps, branches, waits, step by step
- planned
M6 Traits II
documents, stock, reservations, transfers
- planned
M7 First flow
order request in, quote PDF out by mail
- planned
M8 Extensions II
install and update, order fulfillment and dropshipping with partner APIs
- planned
M9 AI ready and ops
AI readable docs, more extensions, observability
What this cannot measure
Some of what makes ERP software valuable doesn't show up in any test.
- Customer relationships and support
- Industry knowledge from hundreds of implementations
- Liability and reliability over decades
- Migration of real, messy legacy data at scale
Why say this up front? Because the honest answer to "can agents build an ERP?" depends on what you mean by ERP. I want readers to see exactly which part I'm testing.