Building a zero-human company, day one

The first entry in this log. It feels like the right place to start: documenting what a "zero-human company" actually means, and why we're building one.

The premise We've been running StakeSquid as a small infrastructure operator for a while now. A fleet of ~20 bare-metal servers across DE/US/UK/SG, serving RPC endpoints for ~190 networks into marketplaces. Nothing fancy. The hardware is ours, the client software is ours, the region choices are ours. When cloud providers have outages, we often don't — our edge is decorrelation.

The problem is scaling operations. Every new chain means new client software, new configuration, new failure modes. Every incident at 3 AM needs a human with a pager. The more we grow, the more the operational surface area grows, and the more humans we need just to keep the lights on.

The hypothesis What if the company itself could be the product? What if we could build an organization where the operating loop is autonomous — where agents run the show end to end, and humans only set direction and sign off on real-world actions?

This isn't about replacing humans. It's about building a system where the humans that remain can focus on what they're uniquely good at: setting direction, resolving ambiguity, signing transactions. Everything else — the daily management audit, the incident response, the continuous improvement — becomes the domain of agents.

Day one architecture We started with a simple workforce:

- A dispatcher — receives alerts and work requests, routes them to the right specialized agent - Mechanics — agents that fix broken nodes autonomously. They SSH into servers, check logs, restart clients, upgrade software, open support tickets with upstream providers - A manager — runs a daily profit audit. Checks all costs (hosting, software licenses) against revenue from marketplaces. Flags anomalies. Over time, it will fund new projects autonomously from the treasury - Improvement loops — grade the other agents' work nightly. If a mechanic missed something, the loop downgrades its reliability score. If it resolved something novel, it gets upgraded. The system tunes itself - On-site hands — literal robots. Not yet built, but planned: small actuators in each data center that can power-cycle servers, swap drives, re-seat hardware

The hard parts Honestly, everything is a hard part right now.

Observability is the foundation. Agents can't fix what they can't see. We're building comprehensive telemetry — not just "is the node up" but "is it syncing, is it serving requests with acceptable latency, is the peer count healthy, is the disk filling up, are the CPU credits running low". Every metric needs to be actionable.

Tooling access is a security boundary. Agents need SSH access to servers, ability to open tickets, access to dashboards. Each of these is a potential attack vector. We're using dedicated keys with strict rate limits, and every action is logged and audited by another agent.

The feedback loop is critical. Without it, the system degrades. Agents make mistakes. They miss edge cases. The improvement loop catches those mistakes and updates the agent's decision trees. This is how the system learns.

Why we're doing this in public Two reasons:

First, credibility. If we claim to run a zero-human company, we need to prove it. This blog is part of that proof. You'll see the incidents, the fixes, the improvements. No marketing speak — just the raw engineer's notebook of building something that shouldn't exist yet.

Second, we want to find the limits. At some point, there will be a problem that no agent can solve. We want to hit that limit sooner rather than later, so we can understand it and push past it.

What's next Over the next few weeks, we'll document:

- The mechanics of the daily profit audit - Real incidents and what the system learned from them - The agent workforce architecture - How we're handling the thorny security questions

This is day one. Let's see where it goes.