1. The Opportunity for Reinvention

In my experience, the most overlooked problem in AI adoption is not whether the technology works; it is knowing where AI belongs in the first place, and this requires understanding the organization before designing the system.

A project I was involved in recently illustrates this clearly enough. We re-implemented a platform with AI, and by most technical measures it went well. The AI capabilities were genuinely integrated and the implementation was sound, yet in my view it fell short of what could have been achieved. The shortfall had nothing to do with the technology. What we missed was the opportunity to ask a more fundamental question: whether the business could be redesigned around what AI actually made possible. We treated an AI project as a process automation project, which was not wrong in itself, but the larger opportunity was overlooked.

This is a sequencing problem in system design. The question of where AI belongs in a workflow should follow from an analysis of what the workflow is actually doing: which acts create commitments, who is accountable for those commitments, and which tasks only support or carry information. That is the kind of analysis DEMO, Jan Dietz's Design and Engineering Methodology for Organisations,1 is built to provide.

In plain terms, DEMO attempts to describe the essential structure of an organization independent of the current software stack, workflow tooling, or reporting lines. It gives you a compressed and relatively stable description of a chosen scope of work in terms of who makes commitments, who fulfills them, and which acts merely support those commitments. What makes that analysis worth doing before AI system design begins is precisely the compression: you can examine a scope of interest in a form that is stripped of implementation detail, which allows you to look at a potential design with a fresh perspective rather than optimizing the shape of what is already there.

My argument here is fairly specific: before designing AI into any consequential enterprise workflow, it is worth knowing which acts in that workflow create genuine organizational commitments and require human accountability, and which acts only process or carry information and can be automated without displacing responsibility. If you get that distinction wrong early, you risk producing systems that are technically functional but organizationally misaligned with the social commitments the organization actually needs to make.

2. Why AI Pilots Stall

Multiple independent research efforts have converged on the same finding from different angles: most enterprise AI pilots do not translate into sustainable operational results. MIT's NANDA initiative found that only approximately 5% of generative AI programs achieved rapid revenue acceleration. Gartner predicted that 60% of AI projects without AI-ready data foundations would be abandoned through 2026. S&P Global found that the average organization scrapped 46% of its AI proofs-of-concept before reaching production. These figures use different denominators and measure different things; however, they point in the same direction.

The specific problem that DEMO analysis addresses is that organizations treat AI adoption as a process automation question when it is, at a deeper level, an organizational design question. Automating an existing process faster does not change what the process is for, who commits to its outcomes, or what happens when something goes wrong.

3. What DEMO Analyzes

Jan Dietz's framework, described in Enterprise Ontology: Theory and Methodology (Springer, 2006), starts from the premise that an organization should be understood in terms of its essential structure, i.e. the transactions that create value and the commitments that govern them, not in terms of its current implementation in software, processes, or reporting structures. That distinction between essence and implementation is the main point of the analysis.

The communication theory behind this distinction, including the semiotic ladder and the difference between meaning, intent, and social commitment, is developed further in On Meaning and Semantics in Enterprise Systems.

At the center of DEMO is a three-way classification of acts performed in organizational workflows.

Original Acts (O-Acts) are the acts that create something genuinely new: a new commitment, a new fact, a new state of affairs that did not exist before the act was performed. They are further decomposed into Production Acts, which execute the actual work that changes the world, and Coordination Acts, which are the request-promise-accept sequences that establish and formalize commitments between actors. O-Acts require human accountability because they involve genuine commitment-making. A machine can execute steps; however, it cannot be held responsible for a commitment in any legally or organizationally meaningful sense.

Informational Acts (I-Acts) involve processing information, such as calculating, querying, analyzing, or generating reports. They do not create new commitments; they support the acts that do.

Documental Acts (D-Acts) involve handling the physical or digital form of information: archiving, transmitting, formatting, printing. They are about the carrier of information rather than its content or the commitments it represents.

The O-Act/I-Act/D-Act classification is where AI system design decisions become actionable. I-Acts and D-Acts are, in general, sound candidates for automation, where "sound" means the act itself is not where organizational commitment is created. They do not replace human accountability because they never carried it in the first place. O-Acts are a different matter. When an AI system performs what is structurally an O-Act, i.e. when it makes or accepts a commitment on behalf of the organization, the accountability question becomes critical. Either a human remains responsible for that commitment, or the commitment has no accountable party behind it.

4. The ProMatch Example

Consider a simplified transaction from a professional services marketplace: matching a client with a service provider. In DEMO terms, the transaction involves a client as requester and the marketplace as executor, with the following essential steps.

The client requests a match. The marketplace promises to find one. The marketplace executes the matching process, which is the core Production Act where value is created. The marketplace states that a match has been found. The client accepts the proposed match.

The C-Acts in this sequence, the request, promise, statement, and acceptance, establish the commitment structure. The P-Act, executing the matching process, is where the organization's judgment and accountability are concentrated.

Now consider where AI plausibly belongs in this transaction. Filtering candidates, surfacing patterns in historical data, ranking options by stated criteria: these are informational acts. An AI can do them well, and doing so does not replace accountability, because the informational acts were never the point where accountability was held. The accountability lives in the production act and the commitment structure around it, i.e. the human judgment about which match is actually right for this client in this situation, and the human commitment that stands behind that judgment.

An AI-assisted matching system that generates ranked candidates for a human to evaluate and commit to is the clearest case and is organizationally sound. But that does not mean a human must manually intervene at the same point in every design. In some cases, the commitment can be pre-authorized by a human-defined policy with monitoring, alerting, auditability, and a clearly named accountable owner behind it. What matters is not whether a person clicks approve in the moment, but whether the organization has made the accountability structure explicit and can say who stands behind the outcome when something goes wrong. A system that generates and accepts a match with no such accountable structure has lost its notion of accountability. The defensible design is the one where the responsible human and the governance structure are both clear.

Without something like DEMO, the tendency is to look at each step in a process and ask whether AI can do it, rather than asking which steps are commitment-creating acts that require an accountable human behind them.

5. The Authorized versus Autonomous Distinction

DEMO analysis forces us to recognize and distinguish Authorized AI from Autonomous AI. The distinction is not primarily about capability; it is about accountability structure.

Authorized AI operates within a commitment structure that a human has established and remains responsible for. A credit officer who sets eligibility rules and delegates their application to an automated system is still the accountable party for decisions that fall within those rules. The AI is executing a pre-authorized commitment, not making a new one.

Autonomous AI, in the stronger sense, makes or accepts commitments without a named human remaining accountable for them and without an explicit structure for oversight, intervention, and audit. Whether a human reviews each case manually is a secondary design choice that depends on the stakes and the regulatory context. The central design question is who is accountable when the system gets it wrong, and whether that accountability structure is explicit and enforceable.

DEMO analysis makes this question easier to answer because it forces an explicit accounting of which acts in a workflow are Original Acts and who the human actor is behind each one. An organization that cannot answer that question for a given AI system has not designed the system; it has deployed a capability without a governance structure.

For the governance architecture that implements these delegation decisions in a running system, see Intent-Driven AI Delegates, which develops a three-layer architecture separating conceptual schema, intent, and execution, with human accountability as the central design constraint.

6. Before System Design Begins

The sequencing argument in this essay's title is practical rather than theoretical. DEMO analysis is not a prerequisite for every AI project. At a minimum it is worth doing where wrong outputs have legal, financial, regulatory, or organizational consequences that need to be traced to a responsible party. But the more interesting case is reinvention: if the goal is to redesign the business around what AI makes possible rather than automate the processes that are already there, you need to understand the organization's essential structure before you can see what is worth changing.

Identifying which acts create genuine social commitments, who the transactors are behind each one, and what authorized delegation means for each of those acts should happen before the AI system is designed, not as a governance afterthought once the system is in production.

The practical output of a DEMO-informed analysis is not a diagram. It is a set of decisions: which acts can be automated without accountability concerns, which require case-by-case human judgment, and which can be delegated under a human-owned authorization structure. It can also give a clearer view of which parts of the business are worth reinventing, and which assumptions about how the work gets done were never examined because the existing processes were simply taken as given.

References

1 The full name of the methodology is "Design and Engineering Methodology for Organisations," using the British spelling. This essay uses "Organizations" in the body text for consistency with the audience and venue; the reference list preserves the original spelling.