The AI-native paradigm: development and operations working as one

Barrier one: general-purpose agents remain outside the system

• API access reveals only function names, parameters and return values
• Business objects, field semantics, relationships and state rules remain invisible
• Agents cannot execute accurately or reason from the complete business context

Barrier two: general-purpose agents lack task specialization

• One general-purpose agent handles every business task
• It lacks focus, depth and domain-specific decision criteria
• Capabilities stay on individual desktops, outside shared governance and reuse

Specialized agents

• Build dedicated agents for each business function
• Each function focuses on its own responsibilities and decision criteria

Embedded agents

• Agents operate inside the system rather than as external tools
• The runtime schedules them under shared governance

Business twins

• The system mirrors the real business
• Business objects, processes and rules have corresponding system representations

AI-friendly systems

• AI can perceive and understand the system
• AI can invoke and operate its capabilities

Traditional development: deep customization means high cost, long timelines and difficult maintenance

• A system meeting all four requirements must be built around the enterprise's actual business and cannot be replaced by generic software
• Traditional custom development requires substantial investment, slow delivery and costly changes

Introducing AI development: AI coding delivers only about 15% overall efficiency improvement

• Root cause: information is fragmented across requirements, design, coding, validation, release and operations
• AI cannot see the whole system and its context, leaving an unbounded range of errors that is hard to resolve
• Generated code receives no automatic feedback; errors are discovered through manual testing

1. AI-native application systems

• The runtime dimension: help operational AI understand the system
• Every system module is a standardized, self-describing element
• AI can see and understand every module
• Including models, services, workflows, permissions, states and their constraints

2. AI-native application development technology

• The development dimension: help development AI understand what it is building
• AI can see lifecycle information for the module being developed
• Definitions, responsibilities, code, specifications, validation and runtime results
• Requirements through operations are connected, allowing errors to converge

1. Design an abstract application system model

• Define system layers, element types and responsibility boundaries
• Use system-level knowledge to guide AI architectural decomposition

2. Express system modules as elements

• Standardized and self-describing
• Hot plugging and hot loading

3. Unify development and operations

• One system model, specification, runtime, architecture and technology framework
• Development can also drive the runtime

4. Connect both directions

• Development can observe and drive operations
• Operations can provide feedback to development

Traditional approach: disconnected external tools

• Development tools sit outside the system architecture
• Runtime agents operate outside the business system
• Development AI cannot see the full lifecycle of its development targets
• Runtime AI can call APIs but cannot see the complete business context

JitAI: embedded and connected

• Development technology is part of the architecture itself
• AI operates inside the system rather than as an external tool
• Development AI can see the full system and all elements
• Runtime AI can also see the whole system and interact through business objects for complete perception

Semantic gap

• AI does not actively clarify ambiguous requirements and implements the simplest interpretation
• Root cause: no requirement clarification mechanism

Context gap

• Limited context windows cannot hold all materials, and content in the middle can be overlooked
• Root cause: no structured context

Lifecycle gap

• AI is responsible only for writing code, excluding upstream requirements and downstream deployment and operations
• Root cause: separation of development and operations

Feedback gap

• Generated code receives no automatic feedback; errors depend on manual testing
• Root cause: no runtime-feedback loop

Memory gap

• Context and requirement clarification disappear between sessions, forcing repeated explanations
• Root cause: no persistent design document

Observability gap

• AI cannot see where code runs, where it fails or who calls it
• Root cause: no runtime observability

A correct system-wide design perspective

The abstract application model holds system knowledge and element responsibilities, enabling accurate architectural decomposition while maintaining a correct view of the whole system

Precise element development specifications

Element specifications form the sole contract for development and operations. Standardizing smaller system modules constrains generation, improves accuracy and makes errors enumerable

An embedded loop: development, operations and feedback

Development AI is embedded in the system and can see runtime results and exceptions, creating an automated development, validation and iteration loop

Abstract application model: system-level knowledge

• Define common layers of enterprise application systems
• Define responsibilities and collaboration between layers
• Define element reference and invocation rules
• Each node in the model represents an element type

Element types: knowledge of type responsibilities

• Every type has a clear position in the system
• Specify field structures, public capabilities and modification boundaries
• Specify validation methods and architectural ownership
• Models · Services · Pages · Workflows · Events · Agents · Roles…

Type specifications as upfront constraints

• Specifications are enforced by Types and validation tools rather than AI discretion
• When specifications do not cover a scenario, stop and report the gap instead of inventing behavior
• When specifications conflict with implementation, use implementation source as the authority

Elements are standardized source modules

• Development AI generates source code and delivers it as elements
• Conversational development means business users normally need not touch source code
• Source remains visible and editable, allowing manual changes

Context: from one-time injection to retrieval on demand

• Traditional approach: a fixed, limited context window requires people to split tasks and choose materials
• JitAI: addressable context retrieved on demand
• One element is the smallest independently buildable and verifiable unit
• Read only the current Type specification and direct dependencies
• Content outside the target scope stays outside the context
• Context becomes a retrieval problem rather than a capacity problem

Design documents: mandatory clarification and persistence

• Application design documents have states: draft → confirmed
• Drafts record confirmed facts, public sources, inferences, assumptions and open questions; they are not implementation authority
• Confirm scope, role permissions, state transitions, exceptions and acceptance criteria individually
• Unresolved ambiguity prevents confirmation
• Make ambiguity explicit · Carry clarification downstream · Separate facts from inferences

Validation is feedback

Development validation errors, runtime exceptions and logs return directly to development AI, creating an automated hypothesis → validation → modification → revalidation loop

Repair threshold

Limit repairs on the same object to five attempts, then transfer to a person to prevent repeated iteration in the wrong direction

01 External AI

Agents run on employee desktops or in the cloud and use APIs. Outside the architecture, they cannot see the full system or element structure

02 Systems are not AI-native

Legacy systems center on tables and pages, without AI-readable object models, field semantics or constraints. Agents see interfaces but not business objects

03 Disconnected judgment and execution

Rules are duplicated in systems and agents and inevitably diverge. Chained API calls hide intermediate states and make failures difficult to roll back

04 Missing governance

Integration accounts have coarse API-level permissions, while desktop skills and prompts cannot be audited or upgraded centrally

AI as a first-class element

Agents are dedicated elements sharing specifications, builds and governance with business elements, scheduled by the runtime

Separate intelligence from functions

• AI handles non-deterministic reasoning, including interpretation, judgment and decisions based on knowledge, experience and thinking frameworks;
• Runtime services deterministically execute strongly consistent calculations, inventory updates and state transitions

Unified governance

Elements and agents share RBAC, data scope and audit trails; permissions determine AI visibility

Business agents: runtime AI

Understand intent → Select authorized services → Record actions

People: manual operations

Forms · Pages · Portals · Approvals

Language models: non-deterministic reasoning

• Understand goals, analyze situations and explain changes
• Identify exceptions, propose solutions and handle ambiguity

System services: deterministic logic

• Calculate amounts, deduct inventory and manage batch states
• Check permissions, execute approval transactions and reconcile accounts

Can this order ship?

• AI summarizes customer credit and history
• The system applies credit and release rules

Can this batch be released?

• AI retrieves inspection criteria and history
• The system determines batch status and release

Do these balances reconcile?

• AI compares differences and explains exceptions
• The system calculates amounts and reconciliation relationships

Business agents

Operate real business objects and workflows

Long-running agents

Asynchronous extended execution, including unattended operation

Workflow orchestration

Coordinate multi-step processes across activities

Embedded in external websites

Expose controlled business intelligence to external users

Shared RBAC and data scope

• Organizations, roles and data scope apply equally to people and agents
• Agents can perform exactly the business capabilities they are authorized to use

Authorization before invocation

• Backend authorization, not interface visibility, controls access
• Checks are specific to roles, workflow steps and data scope

End-to-end runtime records and auditing

• Backend requests, element execution, business exceptions and build diagnostics
• Every business action is traceable and supports rollback

Sensitive-data filtering

• Keep secrets out of logs and raw variable values out of model context
• Do not persist sensitive data; permissions determine what is visible

Element development

• Read the abstract system model
• Generate elements by Type specifications
• Six automated checks
• Deliver conforming element packages

Element specifications: the shared contract

• Type definitions · Public capabilities
• Permission models · Namespaces

Element runtime

• Load elements by contract
• Execute business logic and transitions
• Runtime AI reasons and coordinates
• Output states, exceptions and logs

Deployment options

• Private deployment: enterprise-owned infrastructure and data boundary
• Multi-tenant SaaS: centrally hosted by the platform
• Hybrid deployment: private core data with cloud-based peripheral capabilities

Model gateway

• Support multiple language-model providers through one interface
• No dependency on a single model provider
• Route by scenario: models handle judgment, services handle precise logic

Responsibilities the platform does not assume

• Replacing people in final business decisions
• Performing exact financial and inventory calculations through AI; services handle these
• General-purpose office and creative work
• No dependency on a single model provider
• Element modeling has a cost and requires acceptance testing with real data

Technical direction

• Continually improve element specifications
• Industry templates and reusable element libraries
• A marketplace for reusable skills and specialized agents
• Partner-built Types and industry solutions