The Hive runtime is the spine of Agent Hive

Agent Hive runs on top of a piece of code we call the Hive runtime. People keep asking me what it is, why it exists, and why we did not just glue Claude tool-use into a Next.js route handler and call it a day. This post is the answer.

What the Hive runtime is

The Hive runtime is the loop. It is the piece that takes a job description, a tool inventory, a budget, and a model, and runs the agent until the task is done or the budget is exhausted. It handles:

• The tool-calling protocol against Anthropic, OpenAI, and Gemini.
• Structured output and JSON schema validation.
• Persistent agent state. Every run is replayable from a journal.
• Sandboxed execution for shell-using tools.
• Per-agent budget enforcement, including hard kill on cost overrun.

That is roughly the boring 80 percent of any agent product. It is the part that, frankly, every team building agents in production has rewritten three times. The Hive runtime is the version we rewrote three times and decided to keep.

What the Hive runtime is not

The runtime deliberately does not have an opinion about:

• The org structure. No colonies, no departments, no CEO agent. The runtime runs one agent at a time. Anything multi-agent is composed at a higher layer.
• The UI. No dashboard, no issues table, no approvals queue. The runtime is a daemon plus a tiny CLI. Anything visual is a separate concern.
• Multi-tenancy. No accounts, no isolation between customers. The runtime assumes it runs in one trust boundary.
• Hosting. No idea where the daemon runs. Could be a laptop, a VM, or a managed runtime.

This is the right shape for the runtime. It is also the right shape for us to build a paid product on top of, because the missing pieces (org structure, UI, multi-tenancy, hosting) are exactly the parts that benefit from being centrally operated.

How Agent Hive wraps the runtime

The Agent Hive product is, at its core, a Hive runtime instance per colony, plus the layers the runtime is opinion-free about:

• Provisioning. When you sign up, we spin up a fresh Fly machine with a clean runtime image and an isolated Postgres schema. The colony exists 60 seconds later.
• Org structure. We persist the colony, department, and agent records in our control-plane database. Each agent record points at a job-description blob the runtime consumes.
• UI. The dashboard, org chart, issues table, approvals queue, costs page, and Cmd-K command bar are all our code. The runtime never renders a pixel.
• Tenant isolation. Each colony's runtime sees only its own data and only its own tool credentials. No customer's agent can call another customer's tools.
• Hosting. Fly machines for the agent daemons, Vercel for the dashboard, Supabase for control-plane storage. Same story for everyone.

The wrapper is where the operating-system experience lives. The spine is where the agent loop lives. We get to ship the wrapper fast because we did not have to rewrite the spine.

Why this shape, not a bigger SDK

A reasonable alternative was to ship a thicker SDK that customers embed in their own codebase. We talked to enough teams to know that almost nobody actually wants this. The customers who want an embeddable agent loop have already written one. The customers who do not have one are not asking for an SDK; they are asking for a working product.

The runtime stays small and deliberate. The product wraps it.

What this means for contributors

Patches to the runtime get attribution in the runtime's own changelog. If your patch is something Agent Hive specifically needs (a new tool adapter, a model provider, a sandbox improvement), it lands in the runtime first and we consume it downstream, not the other way around.

If you have a feature request for the wrapper (the org chart, the approvals UX, the costs view), that is an Agent Hive thing, and the right place is our public issue tracker (link from /contact). Two layers, two scopes. Both real.