Why enterprise AI must be designed at the task level—not implemented as one fixed process
Enterprise AI projects often begin with new technology but return to a familiar implementation pattern.
Business users explain how the work is currently performed. Project teams collect expected questions, causes, decision criteria and outputs. These are translated into requirements, rules, workflows and screens. When a new case appears, another condition or branch is added.
An LLM may now generate the explanation. An Agent may call several tools. Semantic Views, Skills and search capabilities may also be included.
Yet the underlying system can still operate like a conventional enterprise application: the investigation path and expected outcome have already been defined.
This does not mean that rules or programs are outdated. Many parts of enterprise work should remain deterministic and conservative.
The problem begins when an entire business process is converted into one fixed system logic before the work is decomposed into its individual tasks.
The Real Choice Is Not Fixed Systems or Autonomous AI
Enterprise AI is often framed as a choice between two models:
Traditional systems follow predefined logic. AI understands the situation and decides what to do.
This is too simplistic.
A customer credit rating should not change because an LLM interprets the same financial ratio differently today. The scoring formula, mandatory checks, approval limits and regulatory controls should remain deterministic and auditable.
Credit monitoring, however, may also involve management changes, lawsuits, adverse news or unusual transaction patterns that are difficult to represent in a fixed scoring model. An LLM may help identify and connect those signals.
Production planning presents a similar distinction. A language model may understand a planner’s question, explain constraints and compare scenarios. But the production mix itself may still be calculated more reliably by an LP or MIP optimization engine.
The question is therefore not whether a business process should be implemented with programs or AI.
It is:
Which detailed tasks should be performed by rules, analytical programs, existing ML models, optimization engines, LLMs, workflows and people?
A single business process usually contains several different types of work. Treating the whole process as either “system logic” or “AI work” hides those differences.
Business and Engineering See the Same Project Differently
Engineers naturally view the problem through available technical capabilities.
Can an Agent select tools? Should this content be represented in a Semantic View? Would a Knowledge Graph improve the context? Should the procedure become a Skill?
These are valid implementation questions.
Business users begin somewhere else.
They are concerned with what must be detected, what should be calculated, which evidence is required, what may vary by case, which conditions cannot be bypassed and who is responsible for the final action.
The difficulty is that one business concept rarely maps to one technology.
Consider an inventory-shortage risk. Its business definition may belong in a semantic model. The relationships among item, location, inventory, demand and production may be represented in a Knowledge Graph. The projected shortage may be calculated by SQL or a program. Relevant policies may be retrieved through search. Investigation guidance may become a Skill. Approval may be managed through workflow.
When business users and engineers discuss technologies before separating the business content, the conversation becomes confusing.
The discussion should not begin with:
Should we use a Semantic View, Knowledge Graph or another AI component?
It should begin with:
Is this business content a definition, a relationship, a calculation, evidence, an investigation method, a control or an execution authority?
Only then can the appropriate technical representation be selected.
Building with AI Is Not the Same as Running by AI
This is one of the most important distinctions in enterprise AI.
AI can be used extensively while building a system. It can analyze policies, draft decision logic, generate SQL, propose a Semantic View, create Skills, write code and produce test cases.
But that does not mean an LLM should execute every part of the work in production.
A credit model may be built faster with AI assistance and still run as deterministic code. A production-planning application may be developed with AI but calculate its answer through an optimization solver. A demand-diagnosis process may combine rules, statistical programs, existing ML models and an LLM.
A system built with AI does not need to be run entirely by AI.
The runtime architecture should be determined by the characteristics of each task—not by the technology used during development.
Once business content is separated from its technical representation, the work can be decomposed into the tasks that actually need to be performed.
One Business Problem Contains Many Different Tasks
Consider the question:
Why was the demand forecast wrong?
Treating this as one Agent task would hide several distinct activities.
The system may first use rules and SQL to select materially significant cases. Programs calculate bias, recurrence and financial impact. An existing ML model produces the baseline forecast. SQL and tools retrieve promotion, order, inventory, production and logistics data.
An LLM may then compare plausible causes and determine which evidence should be examined next. Programs verify the statistical and financial implications. The LLM integrates the findings into a business explanation. A planner approves any material change through workflow.
No single mechanism performs the entire job.
The demand problem may not even be a demand problem. Actual sales may have been suppressed by a stockout. Production may have been constrained. Customer orders may have shifted. A statistically large error may have little financial impact.
A fully predefined investigation can only identify causes anticipated during design. An unconstrained LLM, however, may generate a plausible but incorrect causal structure.
The solution is neither complete procedural fixation nor unrestricted reasoning.
It is task-level allocation based on validated business logic.
AI Can Draft Business Logic. It Cannot Approve It
I saw this directly while designing a demand-diagnosis decision tree.
The first AI-generated version appeared logically complete. But detailed review revealed duplicated branches, inconsistent levels of logic, missing prerequisite checks and overlaps between current performance and future-plan diagnosis.
It took two days of expert review and revision before the structure became operationally reliable.
The lesson was not that AI was useless. It accelerated the initial draft and supported repeated revision.
But it could not determine whether the final logic was correct for the business.
AI can accelerate the design of business logic. It cannot validate that logic on behalf of the business.
This is why simply allowing an Agent to reason more freely is not a sufficient alternative to traditional implementation.
The reasoning structure must first be made explicit, tested against real cases and approved by people who understand the work.
Three Ways Enterprise AI Can Go Wrong
The first failure is to over-program the investigation. Every cause, sequence and conclusion is defined in advance. The architecture may include an Agent, but the Agent only follows a fixed path.
The second failure is to accumulate technical artifacts without a shared model. A new request leads to another prompt, Semantic View field, rule, document set or workflow branch. The system grows, but the same business concept is defined differently in each component.
The third failure is to let the LLM create and apply business logic without sufficient validation. The result may look coherent while containing overlapping conditions, missing evidence or incorrect precedence.
These failures appear different, but they share one cause:
Business knowledge has not first been structured and validated as a shared reasoning model before it is distributed across technologies.
I refer to this shared and validated structure as a Business Reasoning Model.
A Business Reasoning Model Before Technical Artifacts
Before separate technical artifacts are built, the business logic they share must first be structured and validated as a Business Reasoning Model.
It should describe what matters to the business: the problem, relevant entities, states, possible causes, relationships, required evidence, decision criteria and authority.
In our implementation, a Knowledge Graph became the primary structure for representing and connecting this Business Reasoning Model.
The graph made explicit what should be understood and what evidence would be needed. But it was not treated as a perfect representation of the physical data from the beginning.
The actual process was iterative:
The Knowledge Graph made explicit what mattered. SQL verified what actually existed. Semantic Views governed how AI could use the verified data.
SQL exploration confirmed the physical tables, columns, grain, join keys, timing, completeness and data quality.
Sometimes an expected business concept could not be measured with the available data. In other cases, data exploration showed that one concept had to be divided into more precise definitions.
For example, “customer order change” may need to distinguish the original order date, revised order date, requested delivery date and actual shipment date. That discovery should update the Business Reasoning Model—not merely the SQL.
Once the data structure and analytical limits were validated, the Semantic View formalized the entities, dimensions, measures, relationships and terminology that AI could use reliably.
Other technical artifacts could then be developed from the same foundation. Stable conditions could become rules. Reusable calculations could become programs. Investigation procedures could become Skills. Relevant policies and cases could become searchable evidence.
AI can accelerate the creation of these artifacts.
But they should not be created independently whenever a new requirement appears.
One business concept may be used across many technologies, but its meaning and ownership should remain consistent.
The Boundaries Will Continue to Move
The allocation among programs, LLMs and people is not permanent.
Some boundaries are relatively stable. Regulatory controls, official formulas, approval authority and high-impact execution should remain explicit.
Other tasks may move as the technology proves itself.
An LLM may initially draft an explanation for human review. After sufficient testing, it may select tools and complete low-risk investigations independently. If repeated errors occur, part of that task may be moved into a rule or program.
The boundary should therefore be treated as an operating standard that is adjusted through actual evidence.
This does not mean continuously increasing the LLM’s role. It means continuously finding the most reliable division of work.
Agent autonomy may be technically interesting, but it is not a business performance measure by itself.
The relevant measures are business outcomes: faster diagnosis, fewer missed risks, lower operating cost, better decisions and clearer accountability.
Enterprise AI Is Task-Level Work Design
Enterprise AI is not defined by the presence of an Agent, a Knowledge Graph, a Semantic View or any other individual technology.
It is defined by how the work is decomposed, how business knowledge is structured and how each task is assigned to the most appropriate combination of deterministic engines, LLMs and humans.
The existence of rules and programs does not make an AI system less intelligent.
The real mistake is applying one implementation model to an entire business process.
Keep stable logic deterministic. Preserve existing ML and optimization where they work. Use LLMs to understand context, connect evidence and coordinate capabilities. Validate the business logic before any of them operate on it.
That is how enterprise AI can move beyond simply rebuilding another enterprise system.
Next in Enterprise AI by Design
AI Needs a Validated Business Reasoning Model—not a Collection of Answers
The next article will examine how business knowledge can be structured and validated before it is represented in a Knowledge Graph and translated into Semantic Views, rules, Skills and other technical artifacts.