The HTTP Revolution

Hoody exposes the computing stack as HTTP endpoints. Your terminal is an HTTP API, your desktop is a URL, your files are endpoints, your database answers JSON over HTTP, and your browser automation is a set of REST calls.

Convenience is a side effect. The stack was rebuilt this way so that AI systems can operate it directly.

One protocol instead of many

A protocol per tool

Every tool speaks its own protocol, so every integration requires specialized knowledge and every AI agent needs a custom adapter. Hoody removes that variation by giving everything the same protocol.

The Hoody Kit

Rather than add HTTP APIs on top of existing tools, Hoody rebuilt the stack as HTTP-native services. The Hoody Kit includes 18 services that abstract Linux and common tools into HTTP:

Terminal - Execute shell commands via HTTP endpoints
Files - Access filesystems as HTTP resources
Display - Desktop environments accessible through URLs
Browser - Chrome automation as REST APIs
Exec - Scripts that become HTTP endpoints
SQLite - Databases queryable via HTTP
Code - VS Code instances spawned via URLs
cURL - Complex HTTP operations simplified to GET requests
Notifications - Native alerts triggered via HTTP
Daemons - Background process management as HTTP endpoints
Cron - Scheduled tasks managed via HTTP
Pipe - Streaming data transfer between any devices via URLs
Notes - Collaborative notebooks with real-time sync
Watch - File and event watchers as HTTP streams
Run - Multi-source app resolver (Nix, pkgx, AppImage, Docker/OCI) via HTTP
Tunnel - TCP tunneling over HTTP (expose or pull services)
Proxy Logs - Request-level routing and audit logs
Agent - An AI agent that can drive every other service, itself another URL

Consequences of an all-HTTP stack

AI access without adapters

LLMs were trained on the web, so HTTP is native to them. An agent needs no SDK, no documentation parser, and no integration layer: request and response patterns are universal, and execution is a direct HTTP call. Through those calls it can drive your terminal, files, browser, and database.

Any AI with web access (ChatGPT, Claude Code, Codex, Cline) can fetch @hoody.com and receive a Skill: a machine-readable map of your infrastructure’s HTTP surface. There is nothing to install and no onboarding step.

The floating architecture

Containers are not arranged in a hierarchy; they are peers. There is no host that manages containers and no parent-child relationship, only URLs calling URLs. An agent in container A can control an agent in container B, which can spawn and control container C, which can orchestrate container D.

Hoody calls this the “floating” architecture: containers exist as equals and can reach each other’s full capabilities over HTTP. For example, the agent in container A directs the agent in container B; that agent spawns container C, reads its files, queries its database, and runs commands in its terminal, then reports its findings back to container A’s memory bank.

Multi-agent systems built this way need no orchestrator, message queue, or coordinator service. Agents make HTTP calls to each other, spawn containers as needed, and use each other’s terminals, files, and databases directly. The nesting has no fixed depth: each agent has full computing capabilities, and all of them coordinate over HTTP.

Embeddable interfaces

When every interface is a URL, any interface can be embedded wherever an iframe works. Embed a live terminal in your docs, a desktop in a spreadsheet, or a live file view in a presentation. There are no plugins or special clients involved, only iframes and URLs.

Multiplayer sessions

HTTP is stateless and concurrent by design, and the services inherit both properties. Several people in one terminal are multiple HTTP sessions. A shared desktop is everyone loading the same URL. Collaborative debugging is one browser under multiple controllers, and concurrent file editing is concurrent HTTP requests. To bring someone in, share the URL.

Any request as a GET URL

The hoody-curl service, part of the Hoody Kit in every container, turns a complex HTTP request into a plain GET URL. A POST, a call that needs authentication headers, or a chain of service calls can each be encoded as parameters on a single GET, which means any operation can be triggered from restricted environments that only allow GET requests.

Every Hoody service can call every other service, which can call external APIs, which can trigger further Hoody services, all through the same mechanism. Because every container has hoody-curl, any operation can be wrapped into a URL that is shareable, embeddable, and callable, and anything that can follow a link can start it: a chatbot, a QR code, a Slack message, an AI agent that fetches URLs.

Observability and interception

When everything is HTTP, every action, data flow, and decision travels through one inspectable protocol. That makes the whole environment observable:

API calls made by your containers
Files accessed by your team
Commands executed in any terminal
Database queries, browser actions, and script executions
AI decisions and tool use

This is more than application logging: because all activity crosses the same protocol, a single vantage point can see all of it.

Workflows as training data

The bet behind this design is that productivity gains come from systems that can observe work completely, not from people working harder. When every action flows through HTTP, an AI can see patterns in your work: what you do, when you do it, and what worked. Route that traffic through an interceptor you own, and your workflows become training data on your terms.

Endpoint interception with hoody-exec

Because the Hoody API and every container service speak HTTP, any endpoint can be intercepted and modified through hoody-exec. That lets each user build a personal variant of Hoody without touching the core:

Hoody API - Auto-tag containers, track costs, enforce workflows, or add custom validation by intercepting the API that creates containers
Container services - Add monitoring, rate limiting, caching, or an AI layer in front of any service
Files - A hoody-exec script in front of hoody-files can have an AI add documentation comments and explain complex functions before a code file is served
Databases - In front of hoody-sqlite, an interceptor can optimize a query, suggest indexes, and explain the result set
Terminals - Before a command runs, an interceptor can safety-check it, document it, and learn your workflows

Behavior generated on demand

Interception also lets the infrastructure build parts of itself:

Endpoints - A request to /api/analytics/dashboard that matches no existing route can fall through to a hoody-exec script that asks an AI what the route should return, generates the response, and serves it. The endpoint exists from then on, shaped by the request that created it.
Documentation - As you browse a codebase, an interceptor can have an AI add explanatory comments to files in real time; the code documents itself through use.
Query optimization - When a slow query recurs, an interceptor can detect the pattern, ask an AI for an optimization, and add the missing indexes.
Features - New behavior does not wait for a feature request; an interception script can add it when the need appears.

Layered interception

hoody-exec scripts are themselves HTTP endpoints, so they can be intercepted by other hoody-exec scripts:

Layer 1, a hoody-exec script, intercepts a service and logs its requests
Layer 2, another script, intercepts layer 1 and adds caching
Layer 3 intercepts layer 2 and adds an AI processing step
Layer N intercepts layer N-1

The chain has no fixed depth and can be rearranged as your needs change. Extension happens through HTTP interception, not through configuration.

A binary protocol would hide all of this. HTTP keeps it inspectable:

Actions are JSON: human-readable, greppable, auditable
A request’s intent is visible in the request itself
Auth checks, permission verifications, and access attempts all appear in the traffic
Man-in-the-middle interception is not an attack here; it is the supported way to adapt the platform to you

Access from any device

Because the interface is HTTP, the client can be almost anything. A phone can run enterprise workloads through its browser, and a TV can execute code for the same reason. Even a smartwatch can control servers; all that takes is an HTTP request. WebAssembly and progressive web apps are already native to this environment.

One address from everywhere

A service has one address, and it is the same one no matter where the caller sits:

https://PROJECT_ID-CONTAINER_ID-terminal-1.node-us.containers.hoody.com/api/v1/terminal/execute

Your laptop uses it, another container uses it, and code running inside that same container uses it too. Kit services do not accept direct connections on their in-container ports; a request to localhost:<port> from inside the container is refused. Everything arrives through the proxy, which is what makes permissions, hooks, and request logs apply to every call rather than only to the ones that came from outside.

Three converging trends

Hoody is practical now because three trends arrived together:

AI needs structured communication, and HTTP with JSON is the one format every model was trained on.
Browsers grew into operating systems; V8 runs on almost every device.
Containers made isolation cheap enough to spawn a thousand machines, each with its own HTTP API.

Computing already runs on web technology. Hoody treats that as the starting point instead of fighting it.

Changes by role

Developers - One protocol to learn instead of fifty.
DevOps - Connections are URLs, not per-service configuration.
AI engineers - Models call services directly; there are no adapters to build.
Enterprises - The integration layer is HTTP itself, not a platform you buy.

Next: Multiplayer by Default →