Source-linked AI summary

CrabOS: An Operating System for Human-AI Co-inhabitation

Qi Yang, Yun Ma

arXiv:2608.28165v1cs.AIcs.HCcs.OS

TL;DR

Existing agent systems separate human and AI work environments, making handoffs depend on costly bridges as tasks alternate between executors. This paper proposes Human-AI Co-inhabitation and realizes it in CrabOS through shared text objects and a unified auditable interface. Case studies show that these primitives support memory, cross-application continuation, and multi-agent orchestration at the operating-system layer.

  • Problem

    Existing agent systems confine work data and access interfaces to separate human and AI environments, requiring bridges for alternating task execution.

  • Method

    CrabOS represents work state as stable, natural-language-readable text objects that humans and AI directly manipulate through one auditable entry point.

  • Results

    CrabOS operating-system primitives support agent memory management, cross-application context continuation, and multi-agent task orchestration without additional bridges.

  • Takeaways & Limitations

    Human-AI Co-inhabitation shifts support for alternating human-AI work from application-level bridges to operating-system capabilities.

  • Takeaways & Limitations

    CrabOS has limited native Bash support and requires SSH to use an external execution environment for shell commands.

Abstract

from arXiv · show

AI agents are evolving into long-running computational entities that can invoke tools, maintain memory, and complete complex tasks across applications. In real-world settings, completing a task often requires humans and AI to take turns leading its execution. Such alternation depends on the seamless handoff of the work state of the task between humans and AI. Existing agent systems, however, provide humans and AI with separate work environments. AI agents must therefore rely on additional bridges to continue work: either developers build task-specific interfaces to access the work state, or users manually transfer relevant parts of it through screenshots or textual descriptions. Both approaches make handoffs costly and scale poorly. We propose Human-AI Co-inhabitation, a type of work environment that enables humans and AI to seamlessly take turns continuing work on the same task, and design and implement CrabOS to realize this concept. CrabOS represents the work state as natural-language-readable text objects shared by humans and AI, allowing both to access and manipulate it directly through the same auditable interface without bridges. Case studies show that CrabOS elevates support for complex tasks with alternating human and AI leadership from bridge-dependent application-level solutions to native operating-system capabilities, which provide a new foundation for developing and running AI agents.

1 Introduction

Complex tasks often alternate human and AI leadership, but separate work environments make transferring work state costly and difficult to scale. CrabOS addresses this through Human-AI Co-inhabitation, a shared work environment with common representations and a unified auditable interface.

  • Complex tasks require humans and AI to take turns advancing successive stages, with responsibility passing between executors.
  • Seamless handoff depends on making the work state produced in one stage directly usable in the next.
  • Separate human and AI work environments retain work states in different forms, requiring additional bridges for continuation.
  • Human-AI Co-inhabitation shares work-state representations and a unified, auditable interface so humans and AI can continue the same task without scenario-specific bridges.
  • CrabOS realizes this concept as an operating system whose primitives support memory management, cross-application context continuation, and multi-agent orchestration.

2 Related Work

Related work spans human-centered assistants, autonomous agent runtimes, and system-layer abstractions. These approaches establish useful execution and integration capabilities, while CrabOS targets a shared work environment for human and AI executors.

  • Human-centered systems embed AI assistance within existing applications while people remain in control of the workflow.
  • AI-centered systems organize persistent sessions, permissions, tool invocation, and multistep progress above a host operating system.
  • Autonomous agent systems have developed mature execution, permission-gating, and task-orchestration mechanisms.
  • System-layer work includes AIOS, which abstracts agent operation through system calls, scheduling, and managers, and UFO2, which targets Windows desktop automation.

3 Design Principles

Human-AI Co-inhabitation requires shared work data, referable work objects, and uniformly available access interfaces. These principles address collaboration costs for developers, users, and AI across changing task scenarios.

  • A shared work environment contains work state and access interfaces, with work state comprising work data and work objects.
  • Cross-session continuation and multi-agent orchestration require work data that can be reused across collaboration scenarios.
  • Natural-language text objects let humans and AI directly understand and modify one shared representation without custom access methods.
  • Principle 2: Share Work Objects: Screenshots, copy and paste, and verbal restatement impose bridging costs because interface state is not directly referable by the new executor.
  • Principle 2: Share Work Objects: Shared referable work objects include files, tasks, pages, windows, selections, and focus positions.
  • A shared environment must expose capabilities while controlling risk through invocation-time knowledge of the requesting subject.

4 System Design

CrabOS implements shared human-AI work through layered architecture, addressable text objects, unified services, shared shell state, and extensible apps. Its design makes collaboration capabilities composable from common operating-system primitives.

  • CrabOS has four layers: L0 persists state, L1 executes services, L2 manages interfaces and exposes interface state, and L3 extends business functionality through apps.
  • Database-backed designs require separately implemented APIs for hooks, sub-agents, and cross-agent context sharing.
  • L0 Object Layer: CrabOS materializes system objects as stable, addressable text objects, allowing hooks, sub-agents, and context sharing to emerge from existing primitives.
  • L0 Object Layer: The eight L0 object types separate human-readable files and handbooks, AI execution state, applications, configuration, and derived system data.
  • L0 Object Layer: System data differs from logs because it contains retrieval indexes, pending notifications, and browser state overwritten in real time.
  • L1 System Services Layer: L1 routes every external invocation through the Kernel Interface and Object Manager before services execute and persist state.
  • L1 System Services Layer: The Kernel Interface applies mandatory subject binding, contract resolution, policy enforcement, and authorization before capability execution.
  • L1 System Services Layer: CrabOS supports asynchronous Chat and autonomous Task execution through distinct agent-runtime lifecycle modes.

5 Implementation

CrabOS uses a cross-platform Electron foundation and runs L3 apps in sandboxed iframes with SDK-mediated system access. Existing native applications can be integrated through three paths of increasing depth, while local embeddings support offline operation.

  • Platform foundation: Electron provides cross-platform desktop support and lets the GUI shell and L3 apps share one rendering environment.This removes the need to bridge a native UI layer and a web layer.
  • App runtime: L3 apps run in iframes, using the SDK to invoke system APIs while retaining browser security and support for WebAssembly and WebGPU.Apps cannot bypass the Kernel Interface when requesting system capabilities.
  • Native-app integration: Existing native applications can integrate through complete L3 implementation, an L3 GUI with a sandboxed native backend, or a GUI adapter driving native controls.These paths differ in integration depth while presenting humans and AI with the same L3 entry.
  • Offline operation: CrabOS performs embedding locally with ONNX models in Node.js, keeping its vector index fully offline and independent of cloud embedding services.This supports the system’s zero-dependency, out-of-the-box design.

6 Case Studies

The case studies compare CrabOS with application-level agent systems across memory, cross-application context continuation, orchestration, and human-AI continuation. CrabOS composes these capabilities from shared, addressable text objects and system primitives rather than scenario-specific bridges.

  • Memory management: CrabOS lets any installed L3 app independently implement a memory strategy while Chat and Task objects remain directly readable by apps.Written-back content is automatically injected into reasoning through the system layer.
  • Vibe Anything: CrabOS makes cross-application context continuation architectural: PDF page state and document state are directly readable and manipulable as L0 text objects.The capability applies to every scenario represented as an app, rather than requiring each application to implement separate translation logic.
  • Multi-Agent Task Orchestration: CrabOS represents Task as an L0 text object, allowing goal loops, Kanban boards, hooks, callbacks, and ambient behavior to compose from shared primitives.These patterns emerge from addressable objects and directly understandable content.
  • Human-AI continuation: Human-centric systems observe continuation through application-specific logic, whereas CrabOS persists semantic operation traces through common kernel-level invocation controls.AI agents can read these traces when taking over work.

7 Discussion

CrabOS’s design trades arbitrary native shell access and immediate compatibility with existing applications for a unified, auditable system model. Persisted text objects also add write latency, which the system addresses with delayed batching for high-frequency output.

  • Bash ecosystem: CrabOS does not provide built-in arbitrary Bash execution because shell commands could bypass the Kernel Interface and violate its unified-entry model.SSH enables controlled execution in a user-selected local or remote environment.
  • Ecosystem boundary: Existing native applications must first gain an L3 interface to participate in CrabOS’s shared referable work objects.A GUI adapter can preserve the native backend while mapping L3 operations to native controls.
  • I/O performance: Persisting the complete L0 Object Layer adds more write latency than an in-memory database.CrabOS considers this acceptable for typical agent workloads and batches high-frequency streaming writes after a threshold or interval.

8 Conclusion

The paper frames seamless human-AI handoff as a shared-work-state problem and presents CrabOS as an operating-system realization of Human-AI Co-inhabitation. Its conclusion is that shared text objects, direct manipulation, and a unified auditable entry point support composable agent capabilities.

  • Motivation: Seamless handoff requires humans and AI to share work-state representations and a unified, auditable interface as they alternate across task stages.The need becomes more consequential as tasks involve more successive handoffs.
  • Design principles: CrabOS persists stable natural-language-readable text objects, lets humans and AI manipulate the same referable objects, and requires a common auditable capability entry point.These are the paper’s three design principles for Human-AI Co-inhabitation.
  • Implication: Memory management, cross-application context continuation, and multi-agent orchestration can be composed from operating-system primitives without additional bridges.The paper positions this architecture as infrastructure for future agent systems as AI becomes a long-running executor.
Loading 2608.28165v1…