Where AI should enter enterprise systems: keep design-time and runtime agents separate

"A one-stop shop" sounds convenient, but when something goes wrong, no one will sign off.

There is a common line in project reports: 'We need an assistant that can both map processes using natural language and answer operational data questions on the spot.' The demos are flashy: modify a nonconforming product handling flow, then ask for the three suppliers with the highest defect rates last month—all in the same chat window. IT later realized that the permissions matrix couldn’t be implemented—who approved the configuration changes? Which original documents do the answers correspond to? Was there any unauthorized access to factory data? When it comes to accountability, saying 'it was an AI recommendation' becomes a gray box that no one wants to take responsibility for.

AI project failures in companies are rarely because the model isn’t smart enough; it’s usually because it was placed in the wrong position: tasked with both 'building systems' and 'making business judgments.' If the model is built incorrectly, you can fix it and redeploy; if the decision-making is wrong, goods are already shipped, payments made, and complaints have arrived. The costs of mistakes are asymmetric, so you can’t use the same set of entry points, permissions, and audit designs. When 'convenience' is mistaken for 'correctness,' audits and rollbacks are the first to break. This isn’t product marketing language, but a structural fact stated in the platform capabilities page — configuration and permissions are still completed on the design side; runtime queries and reviews use only published page permissions and do not write the database directly; the two are not the same chat window. If you choose the wrong entry point, changing the model later won’t save you. First establish the boundaries of responsibility, then discuss the list of model capabilities — boundaries come before parameters, and before any demo scripts.

Two jobs: one changes configuration, one queries and transacts within authorization.

It is more reliable to understand it according to the division of labor of 'dual agents' than according to the capability list of large models.

Design Side (Implementation): Service implementation, business, and secondary development. Build/modify applications, models, forms, reports, processes, and pages using natural language; the output isReal object that can enter the designer for further adjustment, not a block of instructions that cannot be implemented. For example, describing 'Nonconforming product disposal: discovery — review — rework/scrap/concession — approval — closure,' the system provides a structured draft, which is then confirmed by a person and slightly adjusted in the designer before being released.

Query side (query and handling)Serves managers and business owners. On the live system they query, spot exceptions, and get suggestions. Creating records and completing reviews goes through the business API, stays within that person's page permissions, does not change configuration, and does not write the database directly. For example, the three suppliers with the highest incoming defect rate last month and the main defect types: the answer must drill to the source records.

An 'assistant' that only spits out text and requires the implementer to redo everything in the designer is just for chatting, not for design. The proper workflow is: natural language describes intent and constraints → generate a draft object that can be opened → human verifies boundaries in the designer (parallel, rollback, approval, etc.) → confirm release and write into change audit. The on-the-spot validation is very specific: describe your most complex change or non-compliant process, and see if the output can go directly into the designer for further modification, rather than copying and pasting it elsewhere.

The value of asking for numbers does not lie in 'answering like a consultant,' but in the answer being verifiable against business documents: key figures should point to the details; time, organization, and version of the metrics should be visible; if the information is insufficient to support a decision, state it clearly, rather than fabricating a complete conclusion. What management really fears is not being unable to answer, but being wrong while appearing confident. When the dictionary of standards is not frozen, a 'professional tone' only stitches together conflicting indicators into a seemingly unified story—this erodes trust even more than not being able to answer.

Hang it on the engine, not chat in the air

Agents are an acceleration layer and do not replace organization, permissions, forms, flows, reports, or integration. Design-time can help draft forms and flows, but publish still needs designer review. Runtime queries the live business database. Answers should land on concrete tables and rows, without redefining metrics or bypassing row-level permissions. Creating records and completing reviews goes only through the business API, stays within what that person can do on the page, does not write the database directly, does not approve for someone else, and does not change master data. After org or permission changes, visibility must follow the new assignment so a transferred person is not still queried under the old org. If you cannot say who confirmed a generated flow publish, which records an answer rests on, or whether a review stayed within that person's permission, it should not go to production.

The three bottom lines are governance requirements, not model parameters:

1. Do not directly modify production data——Writes go only through the business API and stay within that person's page permissions. The model must not decide freely or write the database directly.
2. Do not bypass permissions——The visible range is consistent with the user themselves; if natural language can ask for data beyond its authority, it is a leakage channel.
3. Not detached from auditing——Each time changes are generated and confirmed, it can answer 'who confirmed the changes' and 'which records the numbers are based on'.

Before writing these three items into the system and access control procedures, it's better for the pilot scope to be small. Common failure patterns are obvious at a glance: mixing responsibilities makes permissions impossible to consolidate; immediate implementation without confirmation amplifies errors; untraceable answers are eventually abandoned; permission escalation leads to leaks; inconsistent standards result in professional but incorrect responses; using the query channel to 'conveniently change the approver' bypasses the change gate. Posting failure patterns in the project charter is cheaper than pursuing accountability afterward.

Ancestors in circles, then ask the numbers: Order is more important than model version

It is recommended to roughly follow a ninety-day schedule: In the first thirty days, select one or two form/process scenarios, enforce "Generate → Human Confirmation → Designer Adjustment → Publish," and use delivery cycle comparison and auditable changes as completion markers; in the middle thirty days, supplement the standards dictionary, master data uniqueness, and permission matrix, and close the 'universal chat' entry; in the last thirty days, only allow question counts on already launched report domains, enforce drill-down and permission inheritance, and ensure no unauthorized events occur. Pilot scenarios also require careful consideration: on the design side, prioritize documents with complex processes but relatively stable rules (changes, nonconforming product disposition, concession acceptance), and avoid jumping straight into master data reconstruction; for question counts, prioritize quality or delivery indicators with frozen standards, and do not let the model 'unify' KPIs whose definitions are still being modified weekly. Before expanding the organizational scope, first complete a permissions spot check and baseline the indicator ledger—once model-induced illusory answers enter management meetings, the cost of correcting them later is extremely high.

Using account partitions is more secure than sharing high-privilege tokens for querying; long-term shared tokens will distort both permission inheritance and auditing. Drafts on the design side must be separated from releases, and chat drafts are prohibited from directly overwriting the production version. On the querying side, only published metrics can be consumed, and metric definitions cannot be modified privately—the definition changes must still go through the designer and release gates.

If it's not yet time for the window, it's better to be a month late.

When master data is not unified (the same material has multiple codes), the permission system is unclear, there is no traceability mechanism, business rules change weekly, report standards have not been frozen, or AI is treated as a substitute for acceptance, relying on it to 'guess the requirements'—introducing smart agents in these situations will only amplify the chaos faster. When even humans can't clearly manage visibility, the assistant will just ask unauthorized questions more fluently. A self-check: without the assistant, can you still clearly state "who can change configurations, who can see which data, and where the numbers come from"? If you can't answer, it's not yet time to go live. It's better to open up inquiries a month later than to destroy management trust with a single wrong answer.

Write human–machine division into policy: the assistant drafts and surfaces leads; people judge and own outcomes. If the permission matrix is unclear, dual agents collapse into a gray box anyone can chat with and no one can audit. JEDP Digital Platform separates design-time for landing configuration and runtime for queries and handling—config and permissions still finish in design-time—so selection can check two entries, two permission sets, two audit trails, not one flashy dialog.

The next demonstration will only ask three questions

When selecting procurement and information systems, don’t be misled by a 'conversational all-in-one assistant.' Have them demonstrate your most complex change or nonconformance process: can the product continue to be modified in the designer? Then ask about a live KPI: can the answer drill down to the original document? Finally, make an unauthorized request: is it rejected and auditable? If these three tests fail, no matter how new the model is, it shouldn’t go into production. If the vendor insists that one chat window can both modify configurations and query operational data, demand to see two sets of permission matrices and two sets of audit logs—if they can’t explain, it means the boundaries of responsibility haven’t been fully defined. Only when boundaries are clear can capability be applied properly; when boundaries are blurred, capability will only accelerate failures. Separation of duties is not a slogan; it’s a threshold for going live. Two entry points, two sets of permissions, two sets of audits—if any of these are missing, don’t rush to roll it out across the entire company.

• JEDP Platform Capability: Dual Intelligent Agents
• Details of Dual Agents: Design State and Operating State
• Platform and Dual-Agent Sandbox Trial
• System Selection Scoring Sheet (No Information Retention)