8x8 OS: Human-Controlled AI & Web3 Operating System

8x8 OS unifies specialized AI agents, tools, memory, messaging, monitoring, and approval-gated Web3 automation across devices through one secure, human-controlled operating system.

Comment

8x8 OS: Human-Controlled AI & Web3 Operating System

Quick Judge Overview

8x8 OS is a human-controlled operating layer for coordinating specialized AI agents, tools, memory, messaging, monitoring, and approval-gated actions.

For the fastest evaluation:

  1. Open the repository: https://github.com/horbolsi/8x8
  2. Read the root README.md (Judge quick start, Installation, Testing, Safety gates).
  3. Run the commit-gated test suite: python3 -m pytest tests/ scripts/ops/tests/ -q — 27 passing.
  4. Read MASTER_ARCHITECTURE_v4.md and SYSTEM_MAP.md for the system design.
  5. Read AGENTS.md for the agent roster, authority model, and gate matrix.
  6. Confirm that sensitive actions remain blocked or require explicit human approval.

The demonstration environment does not execute trades, move assets, publish content, change credentials, or modify production systems.

Inspiration

AI agents are becoming increasingly capable, but operating several agents safely remains unnecessarily fragmented. A developer may have one agent writing code, another watching infrastructure, messaging bots on Telegram and Discord, local models on different devices, cloud services, databases, scheduled automations, and Web3 tools. Each component has its own interface, memory, permissions, and version of reality. The result is not an operating system — it is a collection of powerful tools held together by terminals, browser tabs, scripts, and optimism.

I created 8x8 OS to explore a different model: one human-controlled operating system where specialized AI agents can collaborate through a shared control plane while remaining observable, permission-aware, and accountable. The central idea is simple: "Give AI agents useful capabilities, but never confuse autonomy with unlimited authority."

What it does

8x8 OS coordinates specialized agents, tools, memory systems, communication channels, monitoring services, and approval-gated actions through one unified interface.

Its primary product experience is a browser-based control surface (frontend/index.html, "Command Center v15.0") that gives an operator a truthful view of the system. Operational areas include: owner and human-agent communication; agent fleet management; system and service monitoring; model and provider routing; long-term memory and knowledge; gates, approvals, and audit evidence; content and media production; Web3 and trading research; devices and external integrations.

Instead of displaying every service as healthy merely because a process exists, 8x8 OS distinguishes between different kinds of evidence: LIVE, LAST-KNOWN, SIMULATED, INFERRED, STALE, UNKNOWN. If a live backend is unavailable, the interface clearly identifies that it is operating with fixtures rather than quietly presenting simulated data as reality.

Human-controlled agentic automation

Every agent has a defined identity, purpose, capabilities, memory references, runtime status, and authority boundary. Low-risk operations can be automated. Sensitive operations remain deny-by-default and require explicit approval gates. Examples of gated operations: publishing public content; sending external messages; changing credentials; modifying production services; executing financial or Web3 transactions; moving assets; performing destructive file operations; expanding an agent's permissions; changing models or providers in sensitive workflows.

How it works

8x8 OS is organized around several connected layers:

  • Agent network: specialized agents handle research, software development, cybersecurity, OSINT, automation, system monitoring, communications, data analysis, and content production. Tasks can be routed to the most appropriate agent or model.
  • Control plane: a canonical view of agents, components, tasks, evidence, system state, and approval gates. Recommendations are separated from actions.
  • Truth and observability layer: tracks where information came from, when it was verified, and whether it represents live, stale, inferred, or simulated state.
  • Memory and knowledge: persistent memory, structured system records, project documentation, agent histories, and retrieval workflows.
  • Tools and integrations: APIs, databases, files, GitHub workflows, messaging bots, local services, cloud applications, Model Context Protocol tools, and external devices.
  • Web3 safety layer: Web3 and market capabilities are treated as high-risk tools. Agents may analyze, research, simulate, and prepare proposed actions; any real transaction or financial execution remains behind explicit controls, risk limits, fresh-data validation, and human approval.

How I built it

8x8 OS combines a browser-based interface with backend services, structured schemas, APIs, automation scripts, databases, messaging integrations, and local Linux environments. The architecture uses explicit contracts for agents, events, components, tool calls, artifact receipts, approval gates, runtime truth, and API responses. The interface is data-driven and designed to work with a live backend while maintaining an honestly labeled fixture mode for demonstration and offline development.

OpenAI Build Week work

8x8 OS existed as a broader experimental agent ecosystem before OpenAI Build Week. For this submission, the Build Week work focused on transforming that foundation into a bounded, testable, and judge-friendly product experience using Codex with GPT-5.6.

Build Week implementation focused on:

  • Converting fragmented system capabilities into one coherent control-plane experience.
  • Creating a reproducible judge-testing path (README judge quick start, commit-gated tests).
  • Connecting GPT-5.6 to the defined agent workflow (active Hermes route: gpt-5.6-terra via openai-codex).
  • Documenting the distinction between pre-existing work and new Build Week implementation.
  • Producing clear setup, security, and testing instructions.
  • Preserving approval gates around sensitive operations.

Codex is used for repository analysis, implementation planning, code generation, refactoring, test creation, debugging, documentation, and review. The owner remains responsible for product direction, authority model, architecture decisions, acceptance criteria, and approval of changes.

Codex usage (verifiable)

Local Codex CLI sessions (codex-cli 0.141.0) that operated inside this repository (/root/8x8-os) include:

  • 019ee44e-272c-7080-9f72-965791d0e997 — full safe audit and verified live map of the 8x8 OS / HERMES ecosystem
  • 019ee484-d45b-7231-8ad1-d036a63259d9 — repository analysis / implementation
  • 019f4bca-fde3-7b02-88fa-4611e1a01974 — Build Week refinement

GPT-5.6 usage (verifiable)

The active orchestration model is configured as gpt-5.6-terra, routed through the openai-codex provider (recorded in SYSTEM/PROVIDER_MODEL_PLATFORM_CAPABILITY_INVENTORY_20260713.md and SYSTEM/HERMES_CLI_CONTINUITY_AND_UNATTENDED_WORK_AUDIT_20260713.md). The local Codex CLI sessions above ran on gpt-5.4-mini / gpt-5.5 configurations; both are reported honestly so judges can verify the exact model used per workflow.

Honest status notes

  • Demo: the previously listed Replit demo (https://8-x-8.replit.app) currently returns HTTP 404 and is not a working public instance. The runnable surface is the local backend (main.py, port 8086) plus frontend/index.html, which require a local environment. No live public demo is claimed.
  • Media: earlier copy referenced a "Sovereign Command Deck" and screenshots (Command Deck / Agent Fleet / System Atlas / Gates / GPT-5.6 workflow / Audit receipt / Mobile view). As of this update, those screenshots/media assets are not committed artifacts; only frontend/index.html exists. This description has been corrected to reflect what actually exists. No UI screenshots are claimed.
  • /feedback Session ID: Devpost requests a shareable Codex /feedback Session ID. At submission-update time, no /feedback share link was generated for the local sessions above. Local session IDs are listed for transparency but are not cloud-shareable feedback IDs. A valid /feedback Session ID must be supplied by the owner before final submission.

Challenges I faced

Fragmented environments: the system spans local Linux, Android Termux, Ubuntu, web services, and mobile devices, so the control plane must represent a distributed system that does not always have every device or service online. Honesty about evidence provenance (LIVE vs SIMULATED vs STALE) was a core design requirement, not an afterthought.

Built With

Share this project:

Updates