The 100x Foundation
Section titled “The 100x Foundation”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.
The seven components
Section titled “The seven components”Seven properties of the platform combine:
Floating Computers + Agent + HTTP (Everything) + Web-Native + Embeddability + MITM/Observability + AI-First Design ──────────────────── = 100x Human Output1. Floating computers
Section titled “1. Floating computers”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.
A container per experiment
Section titled “A container per experiment”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.
2. The Agent
Section titled “2. The Agent”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 tools without installation
Section titled “New tools without installation”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.
3. HTTP everywhere
Section titled “3. HTTP everywhere”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
A protocol AI already speaks
Section titled “A protocol AI already speaks”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.
4. Web-native access
Section titled “4. Web-native access”Every container service has a URL:
https://PROJECT_ID-CONTAINER_ID-display-1.node-us.containers.hoody.comhttps://PROJECT_ID-CONTAINER_ID-terminal-1.node-us.containers.hoody.comhttps://PROJECT_ID-CONTAINER_ID-files-1.node-us.containers.hoody.comOrchestration from any browser
Section titled “Orchestration from any browser”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.
Devices beyond laptops and phones
Section titled “Devices beyond laptops and phones”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 sensor2. Voice command: "Deploy diagnostic container for sensor-12"3. Container spawns, connects to IoT device via HTTP4. Results stream to your smart watch display5. You approve fix with a watch gesture6. Container updates sensor firmware7. 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.
5. Embeddability
Section titled “5. Embeddability”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==" />Dashboards from live services
Section titled “Dashboards from live services”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.
6. MITM and observability
Section titled “6. MITM and observability”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)
Traffic AI can learn from
Section titled “Traffic AI can learn from”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.
7. AI-first design
Section titled “7. AI-first design”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.
The hoody-agent service
Section titled “The hoody-agent service”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
Floating architecture
Section titled “Floating architecture”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.
Coordination without an orchestrator
Section titled “Coordination without an orchestrator”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.
The compounding effect
Section titled “The compounding effect”Growth by headcount
Section titled “Growth by headcount”On the traditional path, projects scale linearly with developers:
1 Developer = 1 Project10 Developers = 10 Projects100 Developers = 100 ProjectsGrowth by agent count
Section titled “Growth by agent count”On Hoody, one person’s project count compounds with the agents and containers they operate:
1 Human + 10 AI Agents + 30 Containers = 10 Projects1 Human + 50 AI Agents + 150 Containers = 100 Projects1 Human + 100 AI Agents + 300 Containers = 500 ProjectsThe 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
A sample workday
Section titled “A sample workday”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.
What Hoody provides
Section titled “What Hoody provides”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 →