Chinoba Decision Runtime Edge: A Lightweight Runtime OS for Governing AI Agents and Operating Them Safely at the Edge

🎥 The YouTube version is also available:

How to Safely Connect AI Agents to Business Operations | Chinoba Decision Runtime Edge

Books : Runtime OS Implementation Guide: A Practical Architecture Integrating AI Agents, Human Gates, and Decision Traces

When introducing generative AI and AI agents into business operations, the first requirement is not to run a larger number of agents.

What is needed is an execution foundation that makes clear who decides on an agent’s proposal, who authorizes execution, and how that process can be explained and audited.

One answer to this challenge is the Chinoba Decision Runtime Edge (CDR Edge).

CDR Edge is a lightweight Decision OS / Runtime OS for operating multi-agent systems safely. AI and agents are not made sovereign. AI emits signals, and only the Runtime finalizes decisions.

AI produces signals. Only the Runtime produces decisions.
Agents execute only approved, traceable decisions.

Separating AI Output from Decisions

Even if an AI says, “We should send a proposal to this customer,” that is not yet a decision. It becomes an executable decision only after questions such as the following have been addressed: Is the evidence sufficient? Does the actor have authorization to handle the customer’s information? Are the pricing conditions satisfied? Is human review required before sending?

Likewise, even if multiple agents conduct research and planning and reach agreement on a conclusion, that agreement alone does not create authority to operate an external system.

CDR Edge acts as a small Decision Kernel that connects Signals, Context, Policy, Permission, Risk, and Human Gates, and determines whether to Act, Ask, or Stop.

Positioning of CDR Edge

• Product name: Chinoba Decision Runtime Edge
• Abbreviation: CDR Edge
• Core: Decision Kernel
• Positioning: A lightweight Runtime for governed multi-agent execution
• Execution principle: Agents execute only decisions that are approved and traceable

The name “AgentOS” can make the agent itself appear to be the center of the system. In CDR Edge, the center is not the agent, but decisions, boundaries, accountability, and traceability. This also clarifies the division of responsibilities among the Enterprise Gateway and the Decision Trace Ledger.

Overall Architecture

flowchart TD
    IC["Interaction Core v2<br/>Message · Evidence · Event"] --> SI["Signal Ingress"]
    AG["Specialized Agents<br/>Research · Plan · Review"] --> SI
    SI --> DK["CDR Edge<br/>Decision Kernel"]
    DK --> BE["Policy & Boundary Engine"]
    BE --> HG["Human Gate<br/>when required"]
    HG --> CP["Command Permit Service"]
    BE --> CP
    CP --> AO["Multi-Agent Orchestrator<br/>execution only"]
    AO --> GW["Enterprise Gateway"]
    GW --> EX["Business Systems / Devices"]
    DK --> TJ["Local Trace Journal"]
    GW --> TJ
    TJ --> LS["Decision Trace Ledger"]

The important point is that the Multi-Agent Orchestrator does not make decisions. The Orchestrator expands decisions finalized by the Runtime into execution by the appropriate agents or workflows. When an agent replans or discovers an exception, it returns that information to the Runtime as a new Signal.

Internal Modules

Execution Flow

CDR Edge is not a mechanism that receives direct execution requests from agents and calls external APIs. It separates accountability through the following sequence:

Interaction Core v2
  → Signal
  → Policy / Context / Risk Evaluation
  → Decision
  → Boundary Check
  → Human Gate (only when required)
  → Command Permit
  → Multi-Agent Orchestrator
  → Enterprise Gateway
  → Execution Result
  → Runtime Evaluation
  → Local Journal + Decision Trace Ledger

A Command Permit is not merely an access token. It is a short-lived execution authorization that limits what can be performed, on which target, how many times, and until when. For example, a permit may authorize “prepare this estimate,” while “send it to the customer,” “finalize the price,” and “execute payment” are separated into distinct Decisions and Permits.

This prevents authority from expanding without limit, even as agents become more capable.

Division of Responsibilities with interaction-core-v2

interaction-core-v2 is positioned before CDR Edge as the Input / Interaction Layer. It transforms human conversations, documents, sensors, business events, and analytical results from other agents into structured Signals that the Runtime can handle.

This separation allows input understanding, decision-making, execution, and explanation to evolve independently. Avoiding the concentration of all responsibility in a single agent or a single large application is a prerequisite for long-term evolution and auditability.

Design as a Lightweight, Embedded Runtime

CDR Edge does not require Kubernetes or large-scale cloud infrastructure from the outset. It supports three profiles so that it can also run on field terminals, store servers, factory equipment, and departmental systems.

As a first implementation step, it is suitable to build the Core as a single Rust process and make external connections replaceable through adapters. State and the Journal can begin with SQLite; external databases, cloud Ledgers, and central Policy distribution can be added when needed.

During network outages, only pre-delegated, low-risk operations should continue. Operations involving unknown authority, high risk, or unverifiable expiration status must not be executed. This is not about sacrificing availability; it is fail-closed design for making autonomy across boundaries safe.

Initial Repository Structure

chinoba-decision-runtime-edge/
  crates/
    runtime-kernel/          # decision state machine
    signal-ingress/          # interaction-core-v2 adapter
    policy-boundary/         # policy and risk evaluation
    human-gate/              # approval / override
    command-permit/          # signed execution permits
    agent-scheduler/         # execution assignment
    gateway-adapters/        # Enterprise Gateway adapters
    trace-journal/           # local append-only journal
    ledger-sync/             # remote ledger commitment
    supervisor/              # watchdog / rollback / isolation
  profiles/
    embedded/
    edge-gateway/
    enterprise/
  contracts/
    signal/
    decision/
    permit/
    trace/

What should be fixed first is not the implementation language, but the data contracts. At a minimum, Signal, Decision, Command Permit, and Trace Event must share common fields for ID, issuer, target, Policy Version, expiration, and references to Evidence.

Connection to Chinoba’s Seven Layers

CDR Edge turns each Chinoba layer into a practical execution foundation.

The Learning Layer does not make Decisions in place of the Runtime. Learning returns Signals that improve Policies, models, rules, and the quality of proposals. Decision sovereignty always remains with the Runtime.

Conclusion

CDR Edge is not a mechanism for allowing AI agents to operate with greater freedom. It is a Runtime for reconciling freedom and accountability when AI and agents become involved in real business operations and physical equipment.

AI can make proposals. Agents can investigate, plan, and execute. But the Runtime must determine what is authorized, where the process stops, and who assumes responsibility.

Chinoba Decision Runtime Edge is a small but essential Decision OS for bringing that principle into the field.

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance