Self-adapting ERP is quickly becoming one of the most provocative ideas in enterprise software: instead of consultants and developers endlessly translating business needs into tickets, configuration, and releases, the application itself could understand its structure and help change itself.

That vision surfaced in a recent r/SaaS discussion about an interview with DOSS CEO Wiley Jones. The thread’s reaction ranged from curiosity to outright contempt, which is useful: the argument is ambitious, but its real value depends less on AI magic than on whether a system can make operational change visible, reversible, governed, and safe. (reddit.com)

The self-adapting ERP idea, without the hype

The core proposition is straightforward. Most business applications are designed in one environment and operated in another. Product teams write requirements, developers change code, admins configure settings, quality teams test, and operations teams finally use the result. Every meaningful adjustment travels through a chain of people, tools, approvals, and handoffs.

A self-adapting ERP attempts to compress that chain. Rather than treating the live application as a fixed destination for changes made elsewhere, it treats the application as something that can inspect its own data model, understand its configuration, propose modifications, and—in tightly constrained situations—apply them.

In the original discussion, Jones described DOSS as pursuing self-introspecting schemas, an application-layer language comparable in spirit to infrastructure-as-code, and a data architecture meant to bring operational and analytical data closer together. The larger claim is not merely that AI can generate a workflow or dashboard. It is that enterprise software should become more malleable after it goes live. (reddit.com)

That distinction matters. Generative AI has already changed how people create software artifacts: code, tests, documentation, SQL, automations, and prototypes. A self-adapting ERP asks a harder question: can the operational system itself participate in its own evolution without turning mission-critical workflows into an uncontrolled experiment?

Why ERP is the hardest place to test autonomous software

Enterprise resource planning software is not a typical SaaS application. It often sits at the center of purchasing, inventory, production, order management, fulfillment, accounting, customer records, supplier relationships, and financial reporting.

A typo in a marketing automation sequence may be embarrassing. A mistaken modification to an inventory allocation rule can trigger stockouts, overselling, delayed shipments, or inaccurate replenishment. A flawed tax, invoice, or revenue-recognition workflow can create accounting problems that are expensive to identify and repair.

That is why the skeptical comments in the r/SaaS thread should not be dismissed as simple anti-AI reflexes. Several commenters made a more precise point: AI-driven adaptability may be useful for configuration and administrative rules, but it becomes much less comfortable when it changes core transaction logic. That is the real dividing line.

Systems of record cannot behave like a chatbot

An ERP is a system of record. It must answer questions such as:

Which purchase order was approved, by whom, and under which policy?
Why did this inventory quantity change?
Which workflow version produced this invoice?
What rule assigned this order to a warehouse or fulfillment path?
Can the organization reproduce the state of the system at the time a decision was made?

A natural-language assistant can help a user ask those questions. But a trustworthy operating system must also preserve the answers. That requires traceability, access controls, separation of duties, test evidence, approvals, and rollback capabilities.

This is not an edge case for large public companies alone. Deloitte notes that governance, risk, and controls should be addressed from the earliest design phase of an ERP implementation through testing, go-live, and ongoing operation. The reason is simple: ERP transformations introduce both new capabilities and new risks to financial and operational controls. (deloitte.com)

The more an AI system can change, the more rigorously it must prove what it changed.

What DOSS appears to be building

DOSS positions its product as an Operations Cloud powered by an Adaptive Resource Platform, or ARP, rather than as a conventional monolithic ERP. Its current site emphasizes connecting existing tools, unifying master data, automating workflows, and analyzing operations data. (doss.com)

The company says its platform supports configurable modules using tables, forms, and workflows, while synchronizing with connected systems and reading from or writing to those systems. In other words, the pitch is not necessarily that a model freely rewrites production code in the background. It is more plausibly an operations platform where the business layer is intentionally configurable and AI can help users navigate or modify that layer. (doss.com)

That is an important clarification because the phrase “self-developing software” can imply several very different architectures.

Four levels of software adaptability

Not all AI-driven change deserves the same level of trust. Buyers should separate at least four levels:

Explanation: The system answers questions about its data, settings, workflows, exceptions, and history. Example: explain why an order is blocked or identify the rule that assigned a reorder point.
Recommendation: The system proposes a change but does not alter production behavior. Example: suggest a revised approval workflow based on recurring bottlenecks.
Controlled configuration: The system creates a draft form, workflow, alert, field, or mapping that a human reviews, tests, and approves.
Autonomous execution: The system changes live rules or data without a case-by-case human approval.

The first two levels are already practical in many business contexts if the underlying data is clean enough. The third can deliver serious implementation and administration gains when it includes guardrails. The fourth is where the burden of proof rises sharply—especially for finance, inventory, payroll, regulated industries, or safety-relevant operations.

DOSS announced Dossbot as a generally available AI copilot in November 2025, saying it could address operational problems and automate changes across large record sets through conversational prompts. Company claims should be independently validated during procurement, but the announcement illustrates where the market is heading: AI is moving from reporting and search toward operational actions. (doss.com)

The real opportunity is reducing implementation drag

The strongest case for a self-adapting ERP is not that it eliminates humans from operations. It is that it reduces implementation drag.

Traditional ERP deployments are infamous for their long timelines because every business is different in consequential ways. A food manufacturer needs lot traceability, expiration logic, production planning, and quality processes. A multi-channel consumer brand needs channel-specific order flows, wholesale rules, retail compliance, co-manufacturer coordination, 3PL integrations, and demand planning. A software company may prioritize procurement, subscription operations, vendor management, and financial workflows instead.

Off-the-shelf software usually handles this variation through a mix of configuration, custom development, spreadsheet workarounds, middleware, and professional services. The cost is not just the initial project. It is the continuing dependence on specialists every time the business changes.

A platform that can represent business logic declaratively—and help users safely create or revise that logic—could make software meaningfully easier to adapt. This is the sensible interpretation of the “Terraform for the app layer” metaphor raised in the interview: business configuration becomes a managed, versioned artifact rather than a collection of hidden settings and consultant knowledge. (reddit.com)

The Verve Coffee example is promising, but not universal proof

DOSS points to Verve Coffee Roasters as a case study. According to DOSS, Verve unified operational data and workflows around production, inventory, and orders, implemented the platform in eight weeks, eliminated four hours of daily manual order batching, and reduced unbatched orders from 30% to 1%. Those are vendor-reported results, not independent benchmarks, but they illustrate the tangible operational outcomes buyers should focus on. (doss.com)

The lesson is not that every ERP can or should go live in eight weeks. Scope, integrations, data quality, reporting requirements, and regulatory needs vary wildly. The lesson is that deployment speed becomes plausible when a product can meet a company where it is rather than demanding that every process be reshaped around a rigid template.

For founders and operators, the better buying question is not “Does this vendor use AI?” It is “How many changes can our team make safely without filing a ticket, hiring a consultant, or creating another spreadsheet?”

Why the community reaction was so hostile

The Reddit thread included blunt dismissals such as “vaporware,” warnings about agents blindly modifying databases through PR loops, and a practical objection that users do not want to build software—they want their business problems solved. (reddit.com)

The tone was harsh, but the underlying concerns are legitimate. Architecture-first pitches can easily lose contact with the operator’s reality. A warehouse manager does not wake up hoping for a self-evolving data model. They want accurate available-to-promise inventory, fewer order exceptions, usable pick tickets, and a faster way to resolve a discrepancy before a truck leaves.

The problem-first test

Any adaptive enterprise platform should be able to answer five concrete questions:

What expensive or frustrating workflow does it remove today?
What can a business user change without engineering help?
What changes still require technical review or an external partner?
What evidence exists that the system will not break critical operations?
How quickly can the business revert a bad change?

If a product cannot answer these plainly, the “AI-native” layer is mostly positioning.

The strongest products will not ask customers to trust a black box. They will show the source data, the affected records, the proposed diff, the test results, the approver, the release history, and the rollback plan. In enterprise software, transparency is often more valuable than apparent autonomy.

Self-adapting ERP needs a change-management operating model

AI does not eliminate change management. It makes change management more important because it lowers the cost and frequency of proposing changes.

The Institute of Internal Auditors describes IT change management as an area involving controls, governance, and technology risk. That framing applies directly to adaptive ERP: if a conversational interface can create or revise a workflow, the organization must decide who is authorized to request, test, approve, deploy, and monitor that change. (theiia.org)

A practical self-adapting ERP should use different policies for different risk tiers.

A sensible autonomy ladder

Low-risk changes can be automated or approved quickly. These include dashboard creation, saved views, alerts, report formatting, nonfinancial labels, help text, task routing, and exception summaries.

Medium-risk changes should be drafted by AI and approved by a process owner. Examples include reorder-point rules, vendor onboarding flows, warehouse task assignments, approval routing, field mappings, or customer segmentation.

High-risk changes need formal controls. These include accounting logic, inventory valuation, tax rules, user permissions, revenue treatment, payment instructions, master-data merges, and transformations that affect regulated reporting.

Irreversible actions should receive the highest scrutiny. Deleting records, bulk-correcting transactional history, changing compliance settings, or transmitting financial files should require explicit confirmation, narrow permissions, durable logs, and often a second approver.

This does not make the technology less innovative. It makes it usable. A model can still save huge amounts of time by diagnosing an issue, creating a recommended policy, generating test cases, preparing a change set, and monitoring results after release. The system simply should not confuse speed with permission.

Explainability is the missing product requirement

The interview’s most interesting technical idea may be the notion of a system that can explain why it is configured the way it is. That capability is more valuable than a flashy agent demo.

Every mature organization eventually runs into “configuration archaeology.” A field exists, but nobody knows why. An approval rule routes requests to a former manager. A discount calculation works except for one customer class. A spreadsheet performs a transformation that should have lived in the core system years ago. An integration fails because a historical exception was never documented.

A genuinely introspective application could reduce this institutional-memory tax. It should be able to show a user:

the workflow or rule responsible for an outcome;
the version and date of the last change;
the requester and approver;
the data inputs used in the decision;
downstream systems and records affected;
tests that passed before deployment; and
a safe route to simulate or reverse the change.

This is also where AI can be genuinely useful. Large language models are good interfaces for translating a human question into a search across configuration, metadata, documentation, logs, and data relationships. But the answer must be grounded in verifiable system facts, not a plausible-sounding narrative.

NIST’s Generative AI Profile emphasizes that organizations need to identify and manage risks specific to generative AI in line with their objectives, risk tolerance, and available resources. For ERP vendors and buyers, that means evaluating not only model quality but also data provenance, human oversight, validation, monitoring, security, and the ability to contest or correct AI-driven outputs. (nist.gov)

The data architecture challenge is real

The original post also highlighted a technical difficulty: combining live operational data with analytical queries. That is not a superficial implementation detail.

Operational systems are optimized for creating and updating transactions reliably. Analytical workloads often scan large volumes of historical data, aggregate across entities, and support unpredictable reporting questions. Putting both demands on the same data foundation can create performance, consistency, governance, and modeling challenges.

DOSS describes an architecture intended to unify operational and analytical work, while its product messaging stresses real-time operational visibility and connected source-of-truth data. (doss.com)

For buyers, the architecture should be judged by outcomes rather than component names. Whether a vendor uses Postgres, Iceberg, DuckDB, DataFusion, a warehouse, a lakehouse, or another stack is secondary to several questions:

Can the platform preserve transaction integrity under real operating load?
Can it show current operational truth without waiting for stale exports?
Can it support historical analysis without slowing critical workflows?
Can it explain lineage when a metric, rule, or operational recommendation is challenged?
Can it integrate cleanly with the systems that must remain authoritative?

A self-adapting ERP that cannot provide dependable data foundations will simply automate confusion more quickly.

AI branding is becoming quieter for a reason

One notable detail from the source was that DOSS reportedly deemphasized the word “AI” for much of 2025, then returned to quieter AI-oriented messaging under the “Adaptive ERP” or ARP framing. Its current website emphasizes AI-native operations but leads with operational outcomes: connecting tools, master data, automation, and analysis. (reddit.com)

That approach reflects a broader buying reality. Operations leaders are often less interested in whether a vendor has an agent than whether the product can reduce manual effort, improve service levels, support traceability, and prevent errors.

For B2B marketers, this is an important positioning lesson. AI is not always the customer’s job-to-be-done. In high-consequence categories, leading with the mechanism can create skepticism. Leading with the workflow improvement—fewer manual batches, faster exception handling, accurate inventory, auditable process changes—gives AI a credible role as an enabling technology rather than a vague promise.

The best AI messaging in enterprise software answers three questions in order:

What operational result improves?
What does the software do differently to produce that result?
What safeguards keep the change reliable?

If the buyer must work backward from a model demo to understand the business outcome, the message is upside down.

What founders should learn from the DOSS thesis

Even if DOSS’s full self-evolving-software vision takes years to mature, the direction is strategically important for builders.

The category opportunity is not limited to ERP. Most vertical SaaS products share the same implementation burden: customer-specific workflows, rules, fields, forms, integrations, reports, and exceptions. The software looks scalable from the outside but often depends on a hidden service layer to make each account successful.

Build for adaptation, not merely customization

There is a critical difference between customization and adaptation.

Customization often means bespoke work that creates a unique branch of product behavior. It may solve a customer’s immediate problem while making upgrades, support, and quality assurance harder.

Adaptation means the product deliberately exposes safe, structured ways to represent legitimate differences between customers. That can include configurable entities, policies, workflow states, validation logic, permissions, integrations, and reporting views.

Founders building AI-native software should focus on these foundations before adding an agent:

A clear domain model: AI cannot safely modify concepts the product itself does not model coherently.
Versioned configurations: Every change needs a diff, history, and restore path.
Permission-aware actions: The assistant must respect the user’s role and organizational policies.
Sandbox and simulation: Proposed changes should be testable against representative scenarios before production.
Observable outcomes: Teams need alerts and metrics that reveal whether a change helped or harmed.
Human-readable explanations: Users must be able to understand the recommendation and its expected impact.

AI can accelerate each layer, but it cannot substitute for them. A weakly modeled product with powerful agents is more likely to generate novel failure modes than durable customer value.

A buyer checklist for evaluating self-adapting ERP

Do not buy based on a conversational demo alone. Ask the vendor to demonstrate a full change lifecycle using a realistic workflow from your business.

Questions to ask in a proof of concept

Show me the diff. What exactly changes when the assistant proposes a new workflow, field, data mapping, or rule?
Show me the blast radius. Which records, users, reports, integrations, and downstream processes could be affected?
Show me the evidence. Can the platform produce test results, validation rules, release logs, and an approval trail?
Show me rollback. How do we restore the prior configuration, and what happens to records created under the new version?
Show me access controls. Can a warehouse supervisor draft a change without being able to deploy it? Can finance require a second approver?
Show me failure behavior. If the model is uncertain, if an integration is down, or if data conflicts, does the system stop safely and escalate?
Show me data lineage. Can users trace a metric or recommendation back to the underlying operational data?
Show me portability. Can we export our configurations, workflow definitions, audit history, and business data if we leave?

A good vendor should welcome these questions. In fact, a vendor building durable AI for operations should make them central to its sales process.

The likely future: adaptive, not fully autonomous

The most plausible near-term future is not an ERP that silently rewrites itself overnight. It is an adaptive ERP where AI becomes a governed co-administrator.

It will inspect records, explain exceptions, generate workflows, create reports, identify data-quality issues, recommend rules, run simulations, prepare approval requests, and monitor whether changes produce the intended business outcome. Humans will still own policy, accountability, and high-stakes decisions.

That may sound less dramatic than “self-developing applications,” but it is more valuable. Enterprise technology wins when it removes friction without creating unacceptable uncertainty.

DOSS’s thesis deserves attention because it identifies a genuine problem: too much business software is expensive to adapt, opaque to operate, and dependent on human translation layers. The r/SaaS backlash also deserves attention because it identifies the condition for solving that problem: adaptability must be earned through controls, evidence, and concrete outcomes—not asserted through AI rhetoric. (reddit.com)

FAQ

What is a self-adapting ERP?

A self-adapting ERP is business operations software designed to inspect its own configuration and data model, then help users explain, propose, test, and sometimes apply changes to workflows, rules, forms, or integrations. The safest versions use AI to assist governed change rather than allowing unrestricted autonomous modification.

Can AI safely change ERP workflows?

Yes, for bounded, well-tested changes with permissions, approvals, simulations, audit logs, and rollback. AI should face much stricter controls when proposed changes affect financial reporting, inventory valuation, taxes, payments, user access, compliance, or irreversible transactional data.

Why are traditional ERP implementations so slow?

ERP projects are slow because every company has unique processes, data, integrations, reporting needs, controls, and exceptions. Adaptive platforms aim to reduce this burden by making legitimate process differences configurable rather than requiring custom code or consultant-led work for every change.

Is self-adapting ERP the same as AI agents changing a database?

Not necessarily. A responsible design can use AI to understand the system, produce a proposed configuration change, test it in a sandbox, request approval, and deploy it through versioned controls. Direct, opaque modification of production data or logic is the highest-risk version of the idea.

What should a company test before buying an AI-native ERP?

Test the complete change lifecycle: the proposed diff, affected records and integrations, approval workflow, test results, audit trail, permissions, monitoring, and rollback. The key question is not whether the system can generate a change, but whether your team can safely govern it.

Self-Adapting ERP: Can AI Safely Change Business Software?