::: ... ... . : ;;; .;;;;;;;. .;;;;;;;. ;;,. ;;; [[[ ,[[ \[[,,[[ \[[,[[[[, ,[[[[, $$' $$$, $$$$$$, $$$$$$$$$$$"$$$o88oo,.__"888,_ _,88P"888,_ _,88P888 Y88" 888o""""YUMMM "YMMMMMP" "YMMMMMP" MMM M' "MMM

This page is a small public peek into LOOM, an ongoing project I am building around a much larger idea for a shared workspace.

LOOM is intended to coordinate projects, knowledge, storage, services, and machines for both people and AI agents. The CLI shown here is the clearest working slice today, not the boundary of the project and not a claim that the wider system is finished. Much of that wider system remains under active development.

At the center of the current build is a Linux main node running LOOM services and coordinating work across a private network, while workspace machines remain the places where people and agents interact with the system.

I am building LOOM around a gamble: as AI agents improve, more useful work can happen locally and across machines I control.

The difficult part is not merely giving an agent shell access. It is creating a workspace it can understand: stable project conventions, searchable knowledge, storage movement, backup policy, jobs, and clear authority across machines. LOOM explores how those parts can feel like one environment without hiding their boundaries.

The terminal Portal is the first interface mature enough to show, not the final shape of LOOM.

Running loom enter opens the terminal-native Portal: a navigable view of the workspace, its available surfaces, and operational state. The browser terminal below offers a small glimpse of that interaction using deliberately fictional values. It has no shell, backend, or connection to LOOM.

LOOM treats people and agents as actors using the same workspace rather than building an isolated agent-only control plane.

Both can encounter the same projects, notes, storage, and operational surfaces, but they do not receive identical authority. Permissions can be scoped, actions can be logged, and access can be revoked.

That principle is further along than any autonomous LOOM-owned agent. Current work focuses on making the workspace legible and safe for existing local agents; richer orchestration remains a later part of the project.

LOOM is taking shape as a Go system deployed with Nix across workspace machines, a Linux main node, and a private WireGuard network.

This is not a finished infrastructure diagram. It is the larger operational shape behind the small CLI preview: local workspaces, a coordinating main node, private networking, and cloud-backed retention working as parts of one system.

Behind the architecture is a substantial set of working features, even though their interfaces and boundaries continue to evolve.

These are the main surfaces available through the CLI and Portal today. They are parts of the same workspace rather than isolated tools, and each is still being tested and refined.

LOOM is still unfinished, and the CLI is only the first piece I can show coherently.

Near-term work includes cleaner project-local LOOM metadata, smarter transfer and ignore rules, intuitive folder-watch contracts, a small hardware health dashboard, and reusable LOOM skills for agents.

Beyond that, I want modular workspace interfaces for control, notes, messaging, and direct agent interaction. Those interfaces should grow from the same tested core rather than become separate products.