Dual Agents

Design-time turns requirements into publishable configuration. Runtime queries, exports, and handles work within authorization. The two paths stay separate, and permissions and audit are not mixed.

Solution Positioning

The dual agents are an acceleration layer, not a seventh engine. Design-time turns natural language into configuration, then reviews, publishes, and can roll back in the designer. Runtime queries, exports, and handles work within authorization, and never beyond the account's page permissions. The two paths stay separate.

Enterprise AI usually stalls on four things: disconnected data, no fit in the business process, heavy operations after go-live, and business and IT talking past each other. The agents sit on the platform, not in a separate system: design-time connects to forms and flows, runtime to visible data and existing APIs.

Putting work into the process and cutting operations, the platform can do directly. Data cleanup and definitions need the business to lead. Tacit rules need experts in the knowledge base. Accountability needs the company itself. The platform lowers the technical bar; the company owns the business. Together they move from demo to production.

Start with design-time: publish only after human review, with rollback. Open runtime in a small pilot after permissions and visibility are clear. Keep the publish record in the designer, write the pilot scope into acceptance, then use it with the six engines and seven product lines.

Where It Fits

Designdesign state

Implementers and developers use natural language to build apps, modules, forms, pages, and flows. Output goes into the designer and is published only after edits.
In the editor, chat or ⌘K can revise scripts or SQL. Designer review and publish still apply—no side path to production.

RuntimeRuntime

Query orders, inventory, quality, and delivery. View text and charts in the dialog, or export Office, HTML, or Markdown.
Business users create forms and complete reviews through platform APIs. Validation and permissions match the page. No direct database writes.

Design-time vs Runtime

Design

Design-time agent

Who uses: Implementation consultants, business key users, secondary development personnel
What it does: Create/modify application categories, applications, modules, form models, fields and model relationships using natural language, as well as forms/lists/Vue/reports/dashboard pages and processes; secondary development can use the editor to interact and assist in modifying scripts/SQL with ⌘K
What you get: The real configuration that can be entered into the designer for further adjustments and publishing, rather than remaining as a draft description in the conversation

Runtime

Runtime agent

Who uses: Management, business leaders, workshop/warehouse/quality and other operational roles (as authorized)
What it does: Within authorization, query data and search the platform knowledge base. Results appear as in-dialog text and charts or as Office, HTML, or Markdown. Through platform business APIs, help business users create data and complete reviews.
What you get: Several deliveries of the same retrieval, plus business data or review results written through APIs. Exports do not replace official definitions. Creating data and completing reviews stay within that account's on-screen permissions and are auditable.

The handoff happens only after publish: runtime queries and transactions use the published version, and unpublished design drafts do not enter operational queries.

Capability Highlights

Coverage of configurable objectsDesign-time covers app categories, modules, forms, fields, pages, and flows. Natural-language output enters the designer and is published only after confirmation.
Developer accelerationSecondary development can use chat assist or ⌘K for scripts and SQL. Designer review and the publish gate still apply—no chat-to-production path.
Intelligent query and multiple deliveriesQuery within authorization and return conclusions and charts. Show them in the dialog or export Office, HTML, or Markdown without changing published metrics.
Handling through business APIsCreate forms or complete reviews through APIs within authorization. Validation, permissions, and audit match the page. No direct database writes; what the page cannot do, the API rejects.
Human review, with rollbackPublish only after a person confirms in the designer; a bad version can roll back. Runtime should start small, then widen step by step.
Permissions, knowledge base, and auditDesign-time owns modeling delivery; runtime owns queries and handling. Permissions, the knowledge base, and audit are built in. Unauthorized calls are traceable. No separate platform.

Works With the Six Engines

The agent replaces no engine. Design-time speeds up configurable objects. Runtime consumes the visible business database and existing business APIs. The six engines keep master data, authorization, modeling, orchestration, consumption, and connectivity.

Organization Engine

In design-time, picking people, departments, and positions uses organization master data. At runtime, visibility follows the appointment and permissions, so a transfer does not keep the old organization scope.

Permission Engine

Design-time and runtime are both bound by functions, data scope, and organization boundaries. Key actions can be audited to a person, and the agent still cannot bypass least privilege.

Form Engine

Design-time can generate and adjust form models, which must be reviewed in the designer before publish. Runtime creates records through the business API, with the same field checks and permissions as on-screen entry.

Workflow Engine

Design-time can build or change approval and business flows, and preview component permissions. Runtime handles reviews through the API, stays within that account's scope, and does not replace countersign rules.

Report Engine

Design-time can create report and large-screen pages. Runtime queries can be exported for interim reporting. Frozen definitions stay with the reporting engine, and exports do not change official definitions.

Integration Engine

Integration failures must be visible and handled in the integration engine. Runtime query exports do not change channel setup, mapping, or credential isolation, and do not act as an operations console.

Solution Snapshot

Typical breakpoints

Breakpoint	Common cause	Control lever
Chat results go directly into production	Skip designer review	Manual review and rollback before release
Writing to the database while bypassing APIs	The business API was not used	Creating data and completing reviews call only existing business APIs
The agent sees out-of-range data	Data permissions not inherited	Consistent with permissions/organization
Treat a query export as an official report definition	Not included in report design governance	The formal system caliber still goes through the reporting engine
The pilot scope is too large to roll back	A company-wide promotion	First, conduct a small-scale manual review pilot
Design state covers someone else's unpublished draft	Version gate missing	Separation of personal drafts and publication
Treat the agent as an integrated operation and maintenance entry point	Channel configuration still relies on manual work	Failure handling is still in the integration engine

Promotion and Acceptance

Design-time: take one form, flow, or report from generation through edit to publish. A ⌘K script change still needs review.
Runtime: show query results as text and charts or export an Office file. Numbers trace back to the query. Unauthorized access and direct database writes are rejected.
Audit: agent actions trace to an account and a time. The pilot states its scope and keeps a rollback note.
Knowledge base: retrieve one platform FAQ. The answer must come from a knowledge entry, not from invention.
Permissions: when one account queries or completes a review, the visible tables and rows stay inside the permission engine.
Close-out: when the pilot ends, no unpublished configuration is left, and temporary elevated accounts are reclaimed.
Separate accounts: design-time and runtime accounts are used apart. Do not share a high-privilege token for analysis queries.

Implement in stages

Phase One: In the design state, manually review and release a business chain; minimize permissions
Phase IIAfter permissions and visible tables are clear, pilot runtime queries and reviews in a small scope
Phase Three: Conduct a permissions regression before expanding the scope of organizations/tables; the official business caliber still goes through the reporting engine

Create a landing prompt

Design-time: speeds up QMS inspection forms, SRM approval flows, WMS exception release, plus lists, pages, and shop-floor screens.
Secondary development: ⌘K can revise validation scripts or retrieval SQL, and the change still needs human review before publish.
Runtime: query orders, inventory, inspection, and delivery. Show text and charts, or export Office, HTML, and Markdown.
Handling: business users can create documents through the API, and complete reviews through the API.
Definitions: published metrics and large screens stay with the reporting engine. Query exports do not change those definitions.
Boundary: reads and writes stay within the account's permissions. Configuration changes go only through designer publish.

When not to apply

It is hoped that the agent will replace one of the six major engines—it is an acceleration layer and does not replace organization/permissions/forms/processes/reports/integration.
Rolling Runtime out across the whole plant from day one instead of phasing it - complete the baseline for metric definitions and permissions first, then pilot on a small scale with humans in the loop
The 'anonymous assistant' without audit requirements changed production — does not meet the recommended baseline
Treating an exported query file as a published official definition. Exports serve reporting and filing. Official definitions stay with the reporting engine.
Expecting the platform to automatically clean up historical dirty data - data cleansing and metric alignment are outside the agent's remit and need the business side to lead the governance effort
Expecting the platform to automatically understand the tacit business expertise a company has accumulated over years - knowledge-base content must be continually curated and maintained by business experts; the platform will not do it for you
Expecting one system to solve organisational and policy problems - adjusting process ownership, role responsibilities, and performance mechanisms is something the enterprise itself must drive

FAQ

Common questions on responsibility boundaries, adoption prerequisites, and platform division of labour - start here; contact us if anything remains unclear

What do design-time and runtime agents do?

Design-time uses natural language to build or change application categories, apps, modules, form models, field relationships, and form, list, Vue, report, large-screen, and process pages. Results enter the designer for further editing before publish. ⌘K assists scripts and SQL. Runtime, within authorization, presents query results as in-dialog text and charts or as Office, HTML, or Markdown, and can create form data or complete reviews through platform business APIs.

Does editor chat or ⌘K count as a bypass publish path?

No. Chat and ⌘K only speed up draft scripts/SQL or configuration; you must still open, edit, publish, and keep rollback in the designer. Chat output is not a production object.

Can runtime create data or complete a review?

Yes. Within the user's own permissions, form data can be created and reviews completed through platform business APIs. Validation, permissions, and audit match on-screen actions. The agent cannot exceed authorization or bypass the API to write to the database directly.

What is the relationship between runtime state and reports/dashboards?

Runtime queries can appear as in-dialog text and charts and be exported as Office, HTML, or Markdown for reporting, circulation, and filing. Cockpits, large screens, and published metric definitions stay with the reporting engine. Export files do not rewrite official definitions.

Does the JEDP agent require building a separate AI system?

Not necessary. The agent is built on the platform, directly interfacing with forms, processes, and visible business databases. Knowledge base retrieval, permissions, and audit links are built into the platform. Private deployment can be evaluated as needed; there is no need to build an AI engineering foundation from scratch, nor is there a secondary integration issue between AI and business.

Can agents replace the six engines?

No. It is an acceleration layer: in the design phase, it shortens the configuration path; in the runtime phase, it shortens the path from data to reportable conclusions. Organizations, permissions, forms, processes, reports, and integrations are still guarded at the boundaries by the corresponding engines.

Can queries and reviews be opened plant-wide before permissions are clear?

Not recommended. Runtime only queries, exports, and completes reviews inside the permission scope. If permissions have not been sampled and visibility is not frozen, finish that baseline before widening the organization.

Can design-time output go straight to production?

No. It must be opened in the designer, edited, published, and kept rollback-ready. A chat draft is not a production object.

Can the platform also solve data governance and organisational problems?

No. The platform only lowers the technical barrier. Cleaning up historical data, making tacit business rules explicit, and establishing accountability rules and organisational support for AI use still require deep, ongoing participation from the business team. The platform provides the tool and the boundaries; the enterprise leads business governance. Only together can they move from demo to a production-grade application.