Skip to main content

From Container Cloud to Intelligent Cloud

· 5 min read
tanzhuo

AI agent systems have reached a point where a single agent is no longer enough. What we need is multi-agent collaboration, observable execution traces, safe side-effect governance, and reliable scheduling in distributed environments.

OpenClaw excels at gateway, tools, sessions, and local multi-agent routing, but falls short when it comes to large-scale collaboration, cross-node scheduling, and operator visibility. Meanwhile, golutra-style orchestration and trace capabilities offer a valuable complement.

Building on OpenClaw's gateway runtime, I propose an evolutionary architecture: treat Kubernetes as a solid foundation and build an AI-native control plane on top of it — call it the Kubernetes AI OS. It does not replace Kubernetes; it treats Kubernetes as the infrastructure layer and adds an agent runtime, execution scheduling, capability discovery, side-effect governance, and cross-node coordination — a genuinely operator-facing execution system.

Why This Architecture?​

OpenClaw is currently strong in channels, tools, sessions, and local multi-agent routing, but has clear gaps in large-scale collaboration, execution-trace auditing, and cross-node placement.

What we want to fuse together:

  • OpenClaw's southbound integrations and agent runtime
  • golutra-style execution traces and visualization
  • Kubernetes's lifecycle management, scheduling, and failure recovery

The core idea fits in one sentence: execution must be visible, inspectable, and attributable. Without a clear execution ledger, a multi-agent system quickly becomes a black box.

Design Goals​

  • Clear multi-agent collaboration within a single node
  • Workflow-level scheduling across nodes
  • Nodes that can automatically join, be quarantined, and recover
  • Small models assist with role recommendation, but high-risk decisions must go through the policy plane
  • Every meaningful action lands in a unified execution ledger
  • Clean separation of control plane, execution plane, observability plane, and policy plane

Non-goals: no replacing Kubernetes-native scheduling, no unrestricted free-form chat between agents, and no letting the model directly decide on high-risk operations like privilege escalation or topology changes.

The Six-Layer Architecture at a Glance​

The system is divided into six layers with clear responsibility boundaries:

  • Southbound Gateway Layer: reuses OpenClaw's channel, tool, and session integration capabilities
  • Execution Kernel: the core execution layer, managing the full Run → Flow → Step → SideEffect lifecycle
  • Cluster Mesh: handles node registration, capability publishing, step scheduling, and security isolation (free-form chat between nodes is discouraged)
  • Observability Plane: the unified execution ledger, with visual views of runs, flows, steps, and side effects
  • Cognition Plane: uses small models for workload identification, role recommendation, and state summarization
  • Policy Plane: owns security approvals, secret scoping, side-effect governance, and trust checks

The control plane decides "what should run, where, and under which policies"; the execution plane does the actual work and produces the trace.

A Single-Node Multi-Agent Runtime​

Even with just one node, multiple roles should run in coordination. The recommended base roles:

  • Planner
  • Executor
  • Reviewer
  • Watcher
  • Specialist (domain expert)

Every action is first reported to the local ledger and then aggregated by the control plane, keeping the execution trace clearly visible.

Cross-Node Scheduling: Steps, Not Chat​

The key to cross-node collaboration is scheduling at the granularity of Steps, rather than letting nodes forward messages freely. Only then are ownership, cancellation, and auditing guaranteed.

The scheduler weighs required tools, model availability, hardware resources, locality, trust level, and tenant affinity.

Node states include joining, ready, degraded, quarantined, and draining, with automatic quarantine of high-risk nodes.

The Core Primitive: the Execution Ledger​

This is the most important piece of the entire system. Every event — run, flow, step, side effect, policy, and so on — is bound to a runId, forming a unified, queryable ledger.

An operator should be able to easily answer:

  • Which agent is executing?
  • What side effects have occurred?
  • Which step is it currently stuck on?
  • Is this failure safe to retry?

The Relationship with Kubernetes​

Kubernetes continues to own the infrastructure capabilities: Pod scheduling, liveness, service discovery, storage, and RBAC.

The AI OS layer expresses objects like HiveRun, HiveFlow, HiveStepLease, and HiveNode through CustomResources (CRDs), with Operators implementing the reconciliation logic.

A Suggested Evolution Path​

Start small:

  1. Phase 1: on a single node, build out the run ledger, flow graph, and side-effect visualization
  2. Phase 2: implement the single-cluster step scheduler and node management
  3. Phase 3: add lightweight role recommendation
  4. Phase 4: implement adaptive cluster behavior

The first goal is not full autonomy, but a single-node AI runtime with first-class observability. Make execution visible first, then make side effects governable, and only then tackle cross-node scheduling.

Wrapping Up​

The goal of the Kubernetes AI OS is to make Kubernetes the true operating-system foundation of the AI era: unlocking multi-agent collaboration while staying safe and controllable. It doesn't reinvent the wheel — it stitches together OpenClaw's southbound integrations, golutra-style execution traces, and Kubernetes's scheduling and recovery. The entire design revolves around a single thread: execution must be visible, inspectable, and attributable. And you don't have to get there in one leap — start with a single-node execution ledger, then move step by step toward cross-node scheduling and adaptive clusters.

COMMENTS