> ## Documentation Index
> Fetch the complete documentation index at: https://docs.monolex.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Dimension 5: The Operating System

> Beyond terminal, beyond machines — AI agents that see and control the OS. Windows, buttons, apps, processes. The next dimension of agent capability.

# Dimension 5: The Operating System

The first four dimensions operate inside the terminal.
The fifth dimension breaks out of it.

## Recap: Four Dimensions Inside the Terminal

```
Dimension 1: Agent count       → N agents in PTY sessions
Dimension 2: Agent direction   → bidirectional, mesh, meeting
Dimension 3: Agent depth       → recursive teams, fractal orchestration
Dimension 4: Agent machines    → cross-machine via gateway/P2P
```

All four dimensions live inside the terminal. Agents read files, write code, run commands. Powerful — but blind to everything outside the terminal window.

## Dimension 5: Agent Sees the OS

```
Dimensions 1-4:  AI operates inside the terminal
Dimension 5:     AI sees and controls the operating system

  Terminal world:    files, code, git, shell commands
  OS world:          windows, buttons, apps, processes, screen, clipboard
```

An agent in dimension 5 can:

```
See:     Windows, displays, sessions, and accessibility state
         Actionable targets and rendered text
         Processes, power, devices, ports, services, and security posture
         App data, logs, clipboard state, and visual evidence when needed

Do:      Act on a guarded target handle
         Press or set accessible controls by name
         Type, paste, send keys, and use pointer fallbacks
         Manage apps, windows, menus, and selected system settings
         Run the platform script surface when explicitly required
```

## The Capability Layer: Kernel CLI

Kernel CLI is a standalone, cross-platform binary that provides raw OS
observation, control, and machine telemetry. Start by proving the current
machine instead of assuming that every desktop session exposes the same
features:

```bash theme={null}
kernel-cli --version
kernel-cli --json doctor
kernel-cli --json report
kernel-cli --json targets --app "TextEdit" --intent save --top 20
kernel-cli --json act '<target_id>' --snapshot '<snapshot_id>' --dry-run
```

Kernel CLI prefers app data, system metadata, windows, accessibility, and
target handles before OCR, screenshots, and coordinates. Pixel workflows stay
available for custom-rendered or inaccessible UI; they are a fallback, not a
mandatory first step.

See the [canonical Kernel CLI overview](/kernel-cli),
[workflows](/kernel-cli/workflows), and [reference](/kernel-cli/reference).

## The Harness Layer: niia observe/control

Kernel CLI is raw capability. niia wraps it with physical harnessing.

```
Raw (kernel-cli):          Harnessed (niia):
  Direct writes execute.      OTP required for control.
  Local audit is evidence.    Time-limited. Scope-limited.
  No approval gate.           Human holds the key.
```

```bash theme={null}
# Observe through the read-only harness surface
niia observe targets --app "TextEdit" --json

# Unlock control through the human OTP flow
niia control unlock --scope full --duration 30m
niia control act '<target_id>' --snapshot '<snapshot_id>' --dry-run --json
niia control lock
```

## Why Structured State Comes First

```
App data / machine state
            ↓
Windows / accessibility / target handles
            ↓
OCR / screenshot / coordinate fallback
```

Structured state carries roles, values, enabled state, identifiers, and
available actions. That usually gives an agent a more precise decision surface
than pixels alone. When the UI has no useful semantic surface, Kernel CLI can
still read rendered text or capture visual evidence.

## In connector.json

```json theme={null}
{
  "connector": "2.0",
  "name": "full-deploy",

  "pipeline": {
    "phases": [
      {
        "name": "implement",
        "model": "opus",
        "prompt": "Implement the feature. Commit and push.",
        "capabilities": { "pty": true }
      },
      {
        "name": "verify-ci",
        "model": "sonnet",
        "prompt": "Open Chrome. Navigate to GitHub PR. Check CI status. If green, click Merge.",
        "capabilities": {
          "pty": true,
          "kernel": {
            "observe": ["windows", "ax-tree"],
            "control": ["ax-press", "key"],
            "requires_otp": true
          }
        }
      },
      {
        "name": "notify",
        "model": "haiku",
        "prompt": "Open Slack. Send deploy notification to #engineering.",
        "capabilities": {
          "kernel": {
            "control": ["ax-press", "type", "key"],
            "requires_otp": true
          }
        }
      }
    ]
  }
}
```

Phase 1: Code in terminal (Dimension 1-4).
Phase 2: Check CI in browser, merge PR (Dimension 5).
Phase 3: Notify team in Slack (Dimension 5).

One pipeline. Terminal + OS. Code + UI. All declarative.

## The Five Dimensions

```
Dimension 1: Agent count       "How many?"
Dimension 2: Agent direction   "Who talks to whom?"
Dimension 3: Agent depth       "How deep does the tree go?"
Dimension 4: Agent machines    "Which physical machines?"
Dimension 5: Agent OS access   "What can the agent see and touch?"

Each dimension is independent.
Each multiplies the others.
connector.json declares all five.
```

```
Dimensions 1-4:  AI that writes code
Dimension 5:     AI that uses the computer

Adding Dimension 5 to a pipeline means the AI can:
  - Write code (PTY)
  - Check CI status (browser via AX)
  - Merge the PR (button press via AX)
  - Notify the team (Slack via AX)
  - Monitor production dashboards (observe via AX)
  - Respond to alerts (control via AX)

This is not "AI coding assistant."
This is "AI computer user."
```

## Safety by Design

Dimension 5 is the most powerful and the most dangerous.
That's why it has the strongest harness:

```
Dimensions 1-4:  Sandbox + worktree (software isolation)
Dimension 5:     Raw capability + an explicit human harness

Software isolation: AI can't write outside worktree
Harnessed control: NIIA refuses writes until the human completes OTP
Raw kernel-cli: direct writes are not OTP-gated

The more powerful the capability,
the stronger the harness.
The strongest harness is physical.
```

See [Physical Harnessing: OTP and Policy](/openclis/specs/connector-json/physical-harnessing)
for why this matters.