By Arash Ghazi
AI belongs in the first architecture conversation
I believe the next generation of software should address a foundational question alongside data, security and user experience: which parts of the work can the system understand, analyze and carry out within a defined boundary? I do not mean adding a chatbot to the corner of an existing application. I mean considering effective AI as a design foundation that can change the division of work between people and software.
For years, many applications have collected records, exposed searches and displayed reports. People then connect the evidence, decide what matters and move the work forward. That model remains useful, but it should not be our only template for a new product. Software can take responsibility for parts of the gap between available information and completed work.
Industrial applications make this question particularly important. They operate around connected processes, limited decision time and consequences that may extend beyond an inconvenient screen. Ambition therefore needs to be paired with explicit limits, engineering discipline and domain expertise.
A design foundation is different from an add-on
An add-on approach builds the workflow first and asks where a conversational interface can fit later. A foundational approach asks earlier why each manual step exists, what evidence it needs and whether a controlled part of it can be delegated.
Consider the difference between answering a question about an order and detecting a delivery risk, gathering its evidence, preparing feasible responses and creating a follow-up task for an authorized owner. Both could use conversation as an interface. The second derives its value from participation in the workflow, not from its fluency.
This does not imply using a language model everywhere. Deterministic rules, statistical models, optimization, computer vision and human judgment serve different purposes. Good architecture selects an appropriate mechanism for the problem. A simpler reliable rule is preferable to unnecessary probabilistic complexity.
Look beyond tasks people already perform
Some opportunities concern existing work: reading shift notes, classifying requests, comparing documents and reconciling records. Others concern work that rarely happens because it takes too much time or requires reviewing too much information.
Continuous comparison of process signals, maintenance history and operator observations may be impractical as a routine manual activity. With suitable data and validation, parts of that analysis become candidates for software support. Technical feasibility is only the beginning; economic value and safe operation still need evidence.
In discovery, I would therefore ask two questions: what does the team do today, and what useful work does it repeatedly leave undone? The second can reveal opportunities absent from the current list of screens and reports.
Design around a process rather than a screen
Industrial work crosses boundaries between quality, equipment, materials, scheduling and operator knowledge. Keeping those records in isolated modules and adding an intelligent feature to one module does not automatically create a system-level view.
NIST's discussion of AI-enhanced manufacturing monitoring emphasizes data quality, system-level effects and testing in controlled environments. The relevant lesson here is that the behavior of one component cannot always explain the outcome of an interconnected process.
The application should connect an event to evidence, analysis, an authorized action and a recorded outcome. Producing more alerts without defining ownership and follow-up leaves the final link missing.
Three ways software can move work forward
Maintenance: prepare a reviewable case
In a hypothetical workflow, the system notices an unusual equipment trend. It gathers relevant maintenance history and operating context, then prepares a review task rather than declaring a root cause. A maintenance specialist reviews the evidence and records the decision.
The value is not necessarily autonomous diagnosis. Evidence gathering and accountable follow-up can themselves become useful software responsibilities. This is a design scenario, not a claim about an implemented customer project.
Quality: connect a suspect observation to a decision
A vision model can flag a possible defect for review. The surrounding application should retain the image, part identity, production context and reviewer decision. Uncertain cases need a defined review path, and the outcome should remain available for later evaluation.
A confidence number is not the whole product. The team needs to know which item requires attention, who owns the decision and what that decision is allowed to change. Acceptance should use representative operating data rather than a few carefully selected demonstration images.
Planning: prepare feasible alternatives
When a delayed material affects several orders, software can assemble planning alternatives against recorded constraints. The planner still judges commercial priorities and customer commitments, but need not manually collect the same information from several systems.
A language model might explain those alternatives. Capacity, inventory and other hard constraints need appropriate validation mechanisms. Persuasive prose must not substitute for a feasible plan.
Action requires an engineered boundary
Moving beyond generated text requires explicit execution paths. Creating a review request or drafting a work order should use narrow, auditable interfaces. Giving a model unrestricted access to every operation is not a shortcut to a mature product.
Define permitted inputs, preconditions, access, approval and observable outcomes for each action. Retries should not create duplicate work. Service failures need visible states and recovery paths. These familiar software-engineering responsibilities become more important when probabilistic components enter the workflow.
The interface must also distinguish a suggestion, a draft and a completed action. A user should never infer execution from a confident sentence when no operation has actually succeeded.
Keep people where responsibility requires them
Reducing manual work does not remove human accountability. Search, comparison and preparation can be delegated while specialists focus on exceptions and consequential judgments. But simply writing “human approved” into a design is insufficient: reviewers need evidence, time and real authority to disagree.
The NIST AI Risk Management Framework 1.0 provides a foundation for defining responsibilities and managing risk across the lifecycle. In an industrial product, those ideas need concrete roles, decision records and a way to stop the intelligent function. Referencing a framework does not prove that controls have been implemented.
For operations affecting equipment or safety, a probabilistic model should not replace independent safety controls or validated operating logic. Domain specialists must define those boundaries. Start with advisory or no-effect trial operation where appropriate, and expand authority only after evaluation proportional to the consequences of failure.
Measure useful work rather than conversational activity
Conversation counts and response length are weak measures of success. Evaluate how much work reaches an acceptable outcome, how often intervention is needed and which errors occur. Include review effort, running cost and support load. An articulate system that creates more work for the team has missed the point.
Begin with a bounded workflow and an observable baseline. Define acceptable outcomes, evaluate suggestions before automatic execution and then consider limited authority. Do not try to compensate for ambiguous processes or poor data simply by selecting a larger model.
This is not a demand to wait for perfect conditions. It is a case for choosing a step whose outcome can be inspected and whose mistakes can be contained. The architecture should support that gradual learning rather than lock the organization into irreversible automation from the start.
Redesign the division of work
My central argument is that effective AI deserves consideration from the beginning of software design. Not every problem needs it, and not every action should be automated. Yet copying yesterday's division of labor into tomorrow's application can leave valuable possibilities unexplored.
Alongside “where should the user click?”, we should ask “why must the user still perform this step?” In industry, a responsible answer combines process understanding, trustworthy data, suitable tools and explicit control. The next generation of software should be judged by useful work completed with evidence and appropriate authority, not by the number of answers it generates.
Explore EasySaz AI services and custom software development. If a valuable task remains undone because of its complexity or volume, contact EasySaz about that workflow. Start with the work, not a chatbot selection.
Custom illustration for this article.