Runtime Protocol — Why AI Needs Decision OS Architecture —

With the rapid evolution of generative AI and multi-agent systems, AI is no longer merely a “conversation system.”

AI systems are beginning to:

• act
• coordinate
• decide
• execute

in the real world.

However, this introduces a fundamentally important problem:

How should we control AI Runtime?

This is not simply a matter of:

Prompt Engineering

What truly becomes important is:

• In what order decisions are made
• Where execution should stop
• When escalation to humans should occur
• How boundaries are enforced
• How conflicts between agents are resolved
• Who ultimately holds responsibility

In other words, what is needed is:

Runtime Protocol as DTM

Why Runtime Protocol Is Necessary

Most current AI systems still follow a relatively simple structure:

Input
 ↓
LLM
 ↓
Output

This architecture is extremely powerful for:

• conversation generation
• search assistance
• summarization
• code generation
• content creation

The rise of generative AI has dramatically accelerated our ability to:

• access information
• organize knowledge
• generate ideas
• build software
• understand complex documents

However, once AI begins operating inside real-world systems, another layer of problems emerges.

The real world contains many things that cannot be handled by a simple:

Input → Output

structure.

Real-world environments contain:

• ambiguity
• organizational conflict
• regulations and compliance
• safety boundaries
• accountability
• approval flows
• human review
• exception handling
• unknown unknowns

Manufacturing environments face:

• sensor anomalies
• machine variation
• operational inconsistencies

Healthcare systems involve:

• patient variability
• ethical decisions
• uncertainty in diagnosis

Governments require:

• accountability
• fairness
• institutional legitimacy

Financial systems require:

• risk boundaries
• auditability
• regulatory compliance

In other words, in the real world, it is not enough for AI to merely generate a plausible answer.

What matters is:

• who made the decision
• under what conditions execution occurred
• where execution stopped
• who approved the action
• why the decision was made

At this point, AI begins evolving beyond a mere “prediction system.”

The world shifts from:

AI = Prediction

to:

AI = Decision Coordination

AI is no longer simply an entity that generates answers.

Instead, it becomes a coordinated execution infrastructure that supports, controls, and records decision-making while coordinating:

• multiple information sources
• multiple agents
• organizational rules
• safety boundaries
• human gates
• external systems

As this transition accelerates, what becomes important is no longer model capability alone.

More important are questions such as:

• How should AI be controlled?
• How should execution be stopped?
• How should approvals work?
• How should responsibility be handled?
• How should boundaries be defined?
• How should decisions be traced?

This becomes a problem of:

Runtime / Governance / Coordination

design.

The AI era is shifting from merely generating outputs toward designing:

decision structures

themselves.

How Should Runtime Be Controlled?

This is where the following components become important:

• DSL
• Behavior Tree (BT)
• Policy Engine
• Ledger
• Human Gate

1. DSL: Describing Runtime Protocol

A DSL (Domain Specific Language) is a language designed to express decision rules in a human-readable form.

For example:

when:
  risk_score: "> 0.7"
  conflict: true

then:
  boundary_check: required
  human_gate: required
  trace: write

This means:

“If risk is high and conflict exists, require boundary validation, human review, and decision tracing.”

Without DSL, the same logic often becomes embedded inside ordinary code:

if risk_score > 0.7 and conflict:
    boundary_check()
    request_human_review()
    write_trace()

At first, this appears simple.

However, reality quickly introduces:

• additional conditions
• exception handling
• department-specific variations
• country-specific regulations
• emergency modes
• role-based permissions

Eventually the code evolves into:

if risk_score > 0.7 and conflict:
    if country == "JP":
        ...
    elif country == "US":
        ...

    if emergency_mode:
        ...

    if operator_role == "senior":
        ...

The system slowly turns into “if-statement hell.”

The advantage of DSL is that it externalizes decision rules from code into explicit Runtime Policy.

Instead of writing procedural logic, we declaratively describe:

how decisions should be made

For example:

when:
  medical_risk: high

then:
  human_gate: doctor_required
  escalation: emergency_team

Even non-engineers can immediately understand:

“High-risk patients require physician approval.”

This is critically important because:

• operators
• managers
• auditors
• legal teams

can all understand the decision policy.

DSL therefore expresses not merely:

Algorithm

but:

Decision Policy

This becomes extremely powerful in domains such as:

• Government Runtime
• Manufacturing Runtime
• Medical Runtime
• Financial Runtime

where:

• rule changes
• auditability
• accountability

are essential.

2. Behavior Tree (BT): Controlling Runtime Execution, Stops, and Escalation

DSL alone does not execute Runtime behavior.

What matters is:

how the system actually behaves during execution

This is where Behavior Trees become important.

Even a simple factory temperature monitoring process can be naturally expressed using BT:

Root
 └─ Sequence
    ├─ Detect High Temperature
    ├─ Check Machine Status
    ├─ Evaluate Safety Limit
    ├─ Notify Operator
    └─ Write Incident Log

This flow means:

1. Detect abnormal temperature
2. Check machine condition
3. Evaluate safety boundaries
4. Notify operators if necessary
5. Record the incident

BT naturally structures real-world operations such as:

• continue monitoring if temperature is slightly elevated
• stop the machine if danger thresholds are exceeded
• escalate to humans if uncertainty exists

For example:

Evaluate Safety Limit
   ├─ OK → Continue Monitoring
   └─ NG → Stop Machine

BT naturally expresses:

If dangerous → stop

This is why BT is especially powerful in domains where:

safe stopping

matters:

• manufacturing
• healthcare
• robotics
• autonomous driving
• government systems

BT is particularly strong at expressing:

• branching
• stopping
• retry
• escalation
• human gates

and aligns naturally with the DTM structure:

Event → Signal → Decision → Boundary → Human → Log

Another major strength of BT is that it structures not only:

successful execution

but also:

failure handling

In the real world, AI systems are not always correct.

Manufacturing systems may encounter:

• safety violations
• abnormal sensor readings
• unstable machine states

Healthcare systems may face:

• diagnostic uncertainty
• high-risk patients
• ambiguous symptoms

Government and financial systems may face:

• regulatory conflicts
• permission problems
• accountability concerns

In these situations, what matters most is:

AI should not continue blindly

BT naturally expresses safe failure handling.

Without BT, systems often degrade into deeply nested if-statements:

if boundary_ok:
    execute()
else:
    if risk_level > 8:
        stop_line()
        notify_manager()
        ...

This creates:

if-statement hell

where complexity grows uncontrollably.

By contrast, BT expresses failure handling structurally:

Detect Signal
  ↓
Evaluate Boundary
  ├─ OK → Execute
  └─ NG
       ↓
   Escalation
       ↓
   Human Review
       ├─ Approve → Retry
       ├─ Retry → Retry
       └─ Reject → Shutdown

The execution logic becomes visually understandable.

BT therefore excels at building:

AI systems that can safely stop

rather than systems that only pursue success.

This distinction is critically important in real-world systems.

3. Policy Engine: Handling Boundaries

A Policy Engine is a specialized layer responsible for evaluating boundaries.

If all boundary logic is embedded directly inside BT, the tree becomes enormous.

For example:

• GDPR validation
• ISO compliance
• safety standards
• internal policies
• budget constraints
• permission checks
• audit requirements

would all accumulate inside the tree.

Therefore, responsibilities are separated:

BT = controls execution flow
Policy Engine = determines execution validity

BT focuses on:

• detecting signals
• analyzing context
• requesting boundary evaluation
• stopping or escalating when necessary
• continuing execution
• writing traces

Meanwhile, the Policy Engine evaluates:

• whether an operation violates GDPR
• whether an action is allowed by company policy
• whether safety thresholds are exceeded
• whether the user has authority
• whether automatic approval is permitted

Inside BT this becomes:

Evaluate Boundary
  ↓
Call Policy Engine
  ├─ OK → Continue
  └─ NG → Escalation / Human Review / Stop

This separation is important because:

execution logic and policy rules become independent

When regulations change, the entire BT does not need to be rewritten.

Only the Policy Engine rules are updated.

This is extremely powerful in highly regulated domains.

4. Ledger: Recording Decision Trace

One of the most important ideas in DTM is:

Decision Trace

What matters is not only:

what decision was made

but also:

• why the decision was made
• which signals were received
• which context was referenced
• which boundary was triggered
• where human review occurred
• which agents conflicted
• which risks existed
• who ultimately approved the decision

In other words, the system records not only outputs but the decision-making process itself.

This is the role of the:

Decision Ledger

The Decision Ledger enables:

• explainability
• auditing
• failure analysis
• organizational learning
• reuse of decision knowledge

It is not merely a log.

It becomes:

Decision Memory

for the AI era.

5. Human Gate: AI Is Not the Final Decision Maker

A Human Gate ensures that AI does not become the ultimate authority.

A critically important principle here is:

LLM should not be the center of the system

LLMs are extremely powerful at:

• generating explanations
• summarizing information
• presenting options
• acting as human interfaces

However, it is dangerous to let LLMs alone determine:

• whether execution should proceed
• whether systems should stop
• who is responsible
• whether safety boundaries are violated
• how exceptional cases should be handled

Therefore, the center of Runtime Architecture becomes:

BT + Policy Engine

rather than:

LLM

When situations such as:

• conflict
• boundary violations
• unknown unknowns
• high-risk decisions
• responsibility-sensitive actions

occur, the system escalates to:

Human Gate

This means:

AI supports decision-making,
but humans or organizations remain final decision-makers.

The goal of Runtime Architecture is not to let AI decide everything.

The goal is:

to place AI inside a controllable decision structure

Why This Is “Decision OS”

This is not merely an AI application.

Traditional AI systems follow:

Input
 ↓
AI
 ↓
Output

However, real-world AI systems must manage:

• Agent Coordination
• Governance
• Boundary Management
• Escalation
• Human Responsibility
• Decision Memory

This resembles not an application, but an operating system layer.

Just as an OS manages:

• execution
• permissions
• resources
• logging

Decision OS manages:

• execution
• control
• boundaries
• approvals
• records
• accountability

for AI-era decision systems.

Conclusion

AI systems will increasingly:

• reason
• execute
• coordinate with other agents
• operate external systems

However, what truly matters is not merely:

how intelligent AI becomes

What matters is:

how AI Runtime is controlled

As AI becomes more powerful, what becomes necessary is no longer merely:

LLM

but:

Runtime Protocol

This is not about creating systems that let AI operate freely.

It is about creating systems that:

• safely control AI
• stop AI when necessary
• escalate decisions to humans
• preserve decision history

Future AI systems will evolve from:

systems that use AI

to:

systems that control AI Runtime

Chinoba — Runtime Society and Coordination Systems:
chinoba.org