Anthropic’s article on self-service data analytics (opens in new tab) makes an observation that transfers almost one-to-one onto the rollout of a highly configurable low-code ERP platform: the generative capabilities of an LLM are a double-edged sword — the very mechanisms that enable creative solutions also produce faulty output.

A configuration-happy low-code platform has exactly the same property. The flexibility that allows fast, tailored solutions is also the source of most failed rollouts. “Turn the platform loose on the customer and let them configure it” produces the same false precision the article warns about: euphoria at first, at being freed from rigid standard software, which curdles into disillusionment the moment it becomes clear that nobody knows anymore which configuration is the canonical one, why it was built that way, or whether it still holds.

The article’s central sentence, translated into our world: the complexity does not lie in building a configuration — that becomes trivial once you understand it properly. It lies in the ambiguity: the ability to map a business requirement onto the one right place in the platform and to know how to work there correctly.

This is why this guide follows the same logic as the article. It identifies three failure modes responsible for the overwhelming majority of failed low-code rollouts, and builds a defensive layer for each.

The three failure modes of a low-code rollout

1. Concept-to-configuration ambiguity. A business requirement (“When does an order count as complete?”) can be implemented on a flexible platform in dozens of plausible ways: a status field, a calculated field, a workflow step, a dedicated entity. Different consultants and different key users choose different routes, often with subtly different semantics. Exactly as with a data model holding forty plausible definitions of revenue, this produces overlapping, inconsistent configurations.

2. Staleness. Business processes, roles, and requirements change constantly during and after the project. Configurations that were correct at the time of the workshop begin to deliver subtly wrong results. On a low-code platform this is more dangerous than with standard software, because every configuration is potentially a one-off with no vendor maintenance behind it.

3. Retrieval failure. The right configuration, the right building block, the reusable pattern already exists — but given the vastness of the configuration space, nobody finds it again. The team rebuilds what was already there, or worse: a slightly divergent variant beside it.

Everything else in this guide is designed to attack these three failure modes.

The approach: four phases

The approach mirrors the article’s agentic stack (Foundations → Sources of Truth → Skills → Validation), transposed onto a rollout project.

Phase 1 — Lay the foundations (discovery & configuration guardrails)

Before the first configuration exists, the solution space is narrowed. This is the most important phase, and the one most often skipped under schedule pressure.

Concretely, in this phase:

  • Define canonical building blocks. Per domain (sales, purchasing, warehouse, finance, …) fix a small set of canonical entities, fields, and status models that count as the only valid source. The most common mistake is that the same concept later has three slightly different implementations. The remedy is fewer, more tightly governed building blocks with clear ownership, rather than many near-duplicates.
  • Glossary and disambiguation. A term like “customer” or “active contract” often means different things in different departments. Capture those ambiguities in writing early — later, that is your most important protection against misconfiguration.
  • Set configuration standards. Naming conventions; when a custom field is allowed versus using a standard field; when a workflow versus a calculated field; when an extension versus a configuration. These standards keep everyone from building in their own style.
  • Agree on governance. Who is allowed to configure what? Which changes need a review? The article stresses it: governance without enforcement decays quickly back into the many-candidates problem. Enforcement has to come through the tool itself (permissions, templates), through review processes, and through a clear mandate.

The result of this phase is not a finished configuration, but a frame in which every business question has, as far as possible, only one governed answer.

Phase 2 — Build the sources of truth (solution design & references)

This is where the reference layer takes shape, the one the whole project team refers to while configuring. In descending order of authority:

  • Standard functions first (analogous to the semantic layer). The single most important rule of the entire rollout: a requirement is checked first against the platform’s standard functions. Custom configuration is the fallback, which only kicks in once it is demonstrably shown that no standard coverage exists. Exactly as the semantic layer in the article is the mandatory default path and raw SQL is only the fallback. Anchoring that order structurally is the greatest lever against sprawl.
  • A catalog of solution patterns. Recurring requirements (approval workflows, number ranges, multi-currency, permission cuts) are solved cleanly once and documented as a reusable pattern, instead of being reinvented in every module.
  • Configuration documentation as a first-class product. Every non-trivial configuration decision is documented together with its business reason — not just the what, but the why. The article advises letting the documentation be generated but keeping the definition owned by a human. Transposed: routine documentation you may accelerate; the business definition belongs to the named owner.
  • Bring in the business context. The layer most teams skip. Anyone who does not understand the business background builds what the key users said, not what they meant. Roadmap, decision logs, and the question “why is this needed right now” belong in the project knowledge.

Phase 3 — Configure within guardrails (build)

Only now is anything built — inside the frame created in phases 1 and 2.

  • Iterate in short loops. Configure, cross-check with key users, adjust. Every loop ends with an observation, not an assumption.
  • Adversarial review. The article describes a review that aggressively interrogates all underlying assumptions, and quantifies the effect (roughly 6% more accuracy, at the cost of more effort). Transposed: every non-trivial configuration should be checked by a second person holding the stance “why is this wrong?” before it counts as done. No self-certification.
  • Make provenance visible. In the article, every answer carries a footer with source, freshness, and owner. Transposed: every configuration carries, traceably, which requirement it rests on, who owns it, and when it was last reviewed. That does not automatically make the solution more correct, but it makes trust auditable.

Phase 4 — Validation & go-live

  • Anchor test cases against a fixed state. The article warns that a test against live data goes stale the moment the number moves. Transposed: write acceptance tests against a defined data state and defined scenarios, not against volatile production data.
  • Release per domain. A domain goes live only once its test cases reach an agreed threshold. That forces corrections before users see the errors.
  • Fear the silent error. The most dangerous failure mode is the one where a result is wrong but looks plausible and gets used without objection. Countermeasures: provenance, explicit sign-off on anything that influences leadership-level decisions, and daily sanity checks of the most important figures against an approved reference.

Maintenance after go-live: the part almost everyone underestimates

The article’s most striking finding: offline accuracy drifted within a month from about 95% to about 65%, because the documentation was not maintained alongside a model that changed daily. Only once model change and documentation change were forced into the same step did it stabilize.

Transposed onto the ERP rollout, this is the most important message for the period after go-live: a low-code configuration is not a finished structure but a living system that rots if nobody tends it. Concretely, that means coupling configuration change and documentation change organizationally — whoever changes a configuration updates its description in the same act. And it means systematically collecting “that was the wrong setting” feedback from operations and feeding it back into the reference documentation, instead of letting it dissipate into a support ticket.

What does not work — the negative findings

The article deliberately documents what did not work, because negative results are cheap to log and keep the next person from making the same mistake. Three of them transfer directly.

First: more access does not solve a structural problem. In the article, full read access to thousands of earlier queries changed accuracy by less than a percentage point — the information was there, was seen, and still went unused. The bottleneck was structure, not access. Transposed: giving the team access to a hundred earlier project configurations helps little if there is no structure mapping a requirement onto the right pattern. Curated, searchable patterns beat raw access.

Second: automatically generated definitions encode exactly the ambiguity you wanted to remove. Transposed: letting configuration be derived automatically from legacy-system patterns produces plausible-looking but semantically muddied solutions. The business definition belongs in human hands.

Third: documentation refinement has a point of negative returns — at some point the documents get longer, not better. Transposed: documenting a configuration concept to death ties up effort without making the rollout safer.

First steps (if you are starting from zero)

As at the close of the article: you do not need the whole apparatus from day one. A handful of canonical building blocks per core domain, a lean set of acceptance test cases, and a spare “standard first, custom only as a justified fallback” principle capture most of the benefit. Everything else you build up once that foundation stands.

And steer the approach by a few guiding questions the article also asks: how important is correctness now versus later (the platform keeps evolving)? How technical is the audience for the configuration — key users who will spot an error, or end users with no model understanding? How much extra effort for review and validation is justified given the risk? And how far does the access reach that you give the customer team over the configuration — one centrally owned state, or many bounded ones?

The greatest lever remains, as in the article, taking on all three failure modes: consolidating ambiguity into one governed answer, making that answer easy to find, and flagging it when it has gone stale.

Apparatus: A guest contribution by Philipp Schrimpf. The text transposes the observations from How Anthropic enables self-service data analytics with Claude (claude.com (opens in new tab), 2026) onto the rollout of a highly configurable low-code ERP platform. The agentic four-layer stack (Data Foundations → Sources of Truth → Skills → Validation), the three failure modes (entity ambiguity, staleness, retrieval failure), the semantic-layer-first principle, and the finding that automatically generated definitions underperform a curated layer all come from that article. The two cited figures — the drift from roughly 95% to roughly 65% accuracy within a month, and the roughly 6% accuracy gain from adversarial review — are likewise reported there. The transposition onto the ERP rollout project is the author’s own work.