Skip to content
Hoody.com

Hoody is built for a bet: that within a few years one person will manage what a 50-person team manages today, not through harder work but through a different computing model, in which AI agents execute while humans orchestrate. Picture the workday this produces.

You sit down wherever you like, because every project is a URL. 47 AI agents are already working across hundreds of containers. Your job is to answer their questions: “Should we use approach A or B?” “Is this security pattern acceptable?” “Deploy this to production?” You answer; they execute. The role resembles that of a call center operator, except the calls are decision requests from AI agents. All day, AI drives first and you confirm, guide, and correct: human-in-the-loop, at scale. The shift is that AI executes and humans judge, and the platform underneath has to support that shift with constant AI action and human checkpoints.

Hoody provides that foundation. The sections below break it into seven components.


Seven properties of the platform combine:

Floating Computers
+ Agent
+ HTTP (Everything)
+ Web-Native
+ Embeddability
+ MITM/Observability
+ AI-First Design
────────────────────
= 100x Human Output

A traditional VPS is a per-unit charge: at $40/month each, separate dev, staging, and prod servers cost $120/month for three isolated machines. On Hoody, one bare-metal server runs as many containers as its capacity allows, and the containers share all of its resources.

Containers have no per-unit cost, so experiments have none either. An AI can try 100 approaches simultaneously, each in its own isolated environment, keep what works, and discard the rest.

One person can manage 100+ projects because each project lives in its own container, and the only limit on container count is what the hardware can hold.


The Hoody Agent is one interface for your whole fleet, and it is a URL. A terminal-native program streamed straight into your browser tab, its multi-pane view puts AI chat beside live terminals, files, and a display preview, and its sessions can target any container you own.

New AI tools appear every day: a new code editor, an automation platform, a monitoring tool. On a traditional system, each one means installation, configuration, dependencies, and compatibility checks, 30 minutes of friction before you can even evaluate whether it is useful.

On Hoody, the same evaluation is one prompt:

"Deploy Cursor AI IDE in container 'ide-test'"
→ https://ide-test.node-us.containers.hoody.com (ready to use)
"Try that new AI monitoring tool Langfuse"
→ https://langfuse-demo.node-us.containers.hoody.com (already running)
"Spin up Supabase for project X"
→ https://project-x-db.node-us.containers.hoody.com (database live)
"Try that new AI monitoring tool Langfuse"
→ 45 seconds later: https://langfuse-demo.hoody.com (already running)
"Spin up Supabase for project X"
→ 1 minute later: https://project-x-db.hoody.com (database live)

Nothing installs on your machine and there is no setup step; the tool arrives already deployed at its URL. One view shows everything you are trying: delete the container if a tool disappoints, keep it if it earns its place. Trying one more tool costs a container.

You don’t context-switch between 100 projects; you see them all at once. Every service is a permanent URL, so sharing your setup is just sending links: your team opens the same terminals and displays you have open, live.

One interface replaces the spread of consoles: AWS, GitHub, the Vercel dashboard, monitoring tools. Everything is behind one URL.


Every Hoody service is HTTP itself, not a program with an HTTP API attached:

  • Terminals: Execute commands via HTTP POST
  • Files: Access filesystem via HTTP GET
  • Displays: Desktop environments via HTTP
  • Databases: SQLite queries via HTTP
  • Browser: Chrome automation via REST
  • Scripts: hoody-exec turns any script into an HTTP endpoint

LLMs were trained on web data, so they produce HTTP requests natively; there is no SDK, integration layer, or custom adapter between an AI and the platform. AI agents can:

  • Spawn 10 containers (HTTP POST)
  • Install dependencies in each (HTTP POST to terminal)
  • Deploy code to all (HTTP POST to exec)
  • Query their databases (HTTP POST to SQLite)
  • Check their status (HTTP GET everywhere)

All of it is standard HTTP, and none of it requires custom training.


Every container service has a URL:

https://PROJECT_ID-CONTAINER_ID-display-1.node-us.containers.hoody.com
https://PROJECT_ID-CONTAINER_ID-terminal-1.node-us.containers.hoody.com
https://PROJECT_ID-CONTAINER_ID-files-1.node-us.containers.hoody.com

Your phone has a browser, so your phone can:

  • Run VS Code (desktop display in browser)
  • Execute terminal commands
  • Access any file
  • Control any container
  • Review AI agent progress

A coffee shop, a plane, a phone, a TV: anything with a browser can orchestrate your 100 projects.

Computing is moving past the laptop and the phone: code on smart glasses, deployments triggered from a watch, sensor data flowing into containers, infrastructure rendered in an AR headset. Hoody makes no assumption about the device, because the only requirement is HTTP. Your “computer” might be:

  • Smart glasses rendering displays while you walk
  • Smart watches showing critical alerts and metrics
  • IoT devices feeding real-time sensor data
  • AR/VR headsets immersing you in your infrastructure
  • Voice assistants executing commands across containers
  • Connected cars accessing your work environment
  • Any device with HTTP capability

Because everything is HTTP, everything can communicate: your smart watch triggers a container deployment, the container processes IoT sensor data, results display on your smart glasses, and alerts arrive on your phone. Iteration across devices becomes routine:

1. Smart glasses detect you're looking at a broken sensor
2. Voice command: "Deploy diagnostic container for sensor-12"
3. Container spawns, connects to IoT device via HTTP
4. Results stream to your smart watch display
5. You approve fix with a watch gesture
6. Container updates sensor firmware
7. All devices confirm: "Sensor operational"
Total time: 45 seconds. Zero friction.

When every device speaks HTTP and every capability is a URL, the boundaries between computing platforms disappear. Instead of a phone app, a desktop app, and an IoT integration, you have HTTP endpoints that work everywhere.


Because everything is a URL and web-native, everything can be embedded anywhere:

<!-- Embed a live terminal in your docs -->
<iframe src="https://demo-terminal.hoody.com" />
<!-- Display a desktop in your dashboard -->
<iframe src="https://project-display.hoody.com" />
<!-- Show live data from SQLite -->
<iframe src="https://abc123-def456-sqlite-1.node-us.containers.hoody.com/api/v1/sqlite/query?db=/data/stats.db&sql=U0VMRUNUIC4uLg==" />

A custom dashboard is a composition of iframes: the monitoring page shows the actual services, embedded live, with no API to poll and no sync delay. You get direct visual access to every system.

AI agents can build custom interfaces the same way, by composing container URLs into HTML. The running infrastructure is the UI.


Because everything is HTTP, every action flows through observable endpoints:

  • Every command executed (terminal HTTP calls)
  • Every file accessed (files HTTP requests)
  • Every database query (SQLite HTTP calls)
  • Every AI decision (agent HTTP logs)

Route traffic through an interceptor you own and every call becomes visible and greppable, on your terms; your AI agents can learn from the record. Nothing is intercepted until you set it up.

The interceptor is hoody-exec: write a script, get an HTTP endpoint, and point any client at it to place it in front of any service. From there you can:

  • Intercept file reads to add AI-generated documentation
  • Intercept database queries to auto-optimize them
  • Intercept API calls to add caching layers
  • Chain MITMs with no fixed depth (MITM an Exec with another Exec)

Every layer of the infrastructure is one script away from working the way you want.


Hoody was designed for AI from day one rather than adapted to it afterward. Two design choices show it: the hoody-agent service and the floating architecture.

Every container can run hoody-agent, an HTTP-native AI agent with:

  • 100+ HTTP endpoints for complete control
  • Memory bank for context retention
  • MCP client integration (connect to external MCP servers like GitHub, Slack, Jira)
  • Direct access to all container services
  • Ability to orchestrate other containers

Containers are peers, not a hierarchy. An AI agent in container A can directly control container B, which can spawn container C, which can orchestrate container D. No central orchestrator is required; AI agents discover and coordinate with each other through HTTP.

Multi-agent systems emerge from this structure without orchestration infrastructure to build: you spawn containers with AI agents, give them permissions, and they coordinate themselves. One person describes intent, and 10 AI agents across 30 containers execute it, all coordinating over HTTP.


On the traditional path, projects scale linearly with developers:

1 Developer = 1 Project
10 Developers = 10 Projects
100 Developers = 100 Projects

On Hoody, one person’s project count compounds with the agents and containers they operate:

1 Human + 10 AI Agents + 30 Containers = 10 Projects
1 Human + 50 AI Agents + 150 Containers = 100 Projects
1 Human + 100 AI Agents + 300 Containers = 500 Projects

The human provides:

  • Strategic direction
  • Judgment calls
  • Creative vision
  • Ethical boundaries

AI agents handle:

  • Code implementation
  • Testing
  • Deployment
  • Monitoring
  • Optimization

Containers provide:

  • Isolated execution environments
  • Experimentation space bounded by hardware, not budget
  • Scaling at no marginal cost
  • Instant rollback via snapshots

9:00 AM - You review 47 active projects, each a set of URLs. Embedded displays and terminals show each one’s live status.

9:15 AM - An AI agent in Project #12 requests architectural guidance. You provide direction via chat. It spawns 3 sub-containers to test approaches and presents options in 5 minutes.

9:30 AM - You notice a security pattern working well in Project #5. You tell your meta-agent to apply it everywhere. It rolls the pattern out container by container while you review other work.

10:00 AM - A client wants a new feature. You describe it, and AI agents in 7 relevant projects adapt simultaneously. Changes are live within the hour because the containers are already deployed.

12:00 PM - From your phone at lunch, you pull up a Firefox display showing all 47 project dashboards. You make a strategic decision, and the AI teams implement it across all projects by the time you’re back.

The parts are real: containers, agent sessions, HTTP APIs on every service, snapshots, and proxy logs all exist today. The scenario is where they lead.


You don’t need to wait for better AI models. The current ones are capable; they just need the right infrastructure, and it exists:

  • Isolated environments, as many as capacity allows (containers)
  • A protocol AI already knows (HTTP everywhere)
  • Request-level observability (proxy logs, opt-in interception)
  • No deployment step (services are already live)
  • Rollback (snapshots)
  • Access from any browser (web-native)
  • Peer-to-peer coordination (floating architecture)

For this workflow the limiting factor is usually infrastructure rather than model capability, and infrastructure is the part Hoody addresses.


The point is not coding faster; it is orchestrating hundreds of AI agents while you focus on vision, strategy, and judgment. Hoody is the foundation that makes that possible today.

Next: The HTTP Revolution →