What is Queen?

The plain-language introduction to Queen: what it is, the problem it solves, and who it is for. Queen is in active design; this describes what it does by design. Written for people who will run the Apiary across many machines.

What is Queen?

The plain-language introduction to Queen: what it is, the problem it solves, and who it is for. Queen is in active design; this describes what it does by design. Written for people who will run the Apiary across many machines.

Related:


#Status

Queen is in the specification stage. The architecture is decided and the design is written; enrollment opens as the first releases land. This page describes what Queen does by design.

#The problem: one machine is simple, a fleet is not

The Apiary is clean on one machine: four daemons behind one portal, everything on your own loopback. The trouble starts when the stack spreads across machines, teammates, and orchestrators that spin up throwaway workers. Nobody can answer the questions a single machine cannot: which daemons are alive and where, who is allowed to add a new device and who just did, how an admin sees fleet-wide ROI without remoting into someone's laptop, and, when a machine is stolen or an engineer leaves, what gets cut off and how fast.

#The idea: a control plane that never reads your memory

Queen is the cloud orchestrator for when the stack outgrows a single machine. It sits beside your memory, not inside it. Your memory and skills stay on the data plane you already own. Queen carries what that plane was never meant to carry: liveness, identity, enrollment, signed commands, coarse usage facts, and fleet-wide reporting. By policy it never holds your memory content, your prompts, your session text, or your plaintext credentials.

#What it does

  • A read-only fleet view. Every agent in your org, with health derived from heartbeats, scoped so you only ever see your own fleet.
  • Per-agent identity. Every agent, including throwaway sub-agents, gets its own attributable, revocable identity. No shared forever-key. Revoke one and you cut off one, not the fleet.
  • A second machine in minutes. Add a machine with a short-lived join token. No browser on the server, no credential pasted into a config file, no shared key.
  • Signed commands. One authority signs every command and workers verify it. If that authority is down, workers keep doing local work and keep reporting in. They degrade to autonomous, not dead.
  • Fleet-wide ROI. Per-org, per-team, and per-user leaderboards over a shared spend ledger, with measured and allocated costs kept honestly separate.

#The promise it keeps

Most fleet tools start by grabbing your credentials and end up being the thing you have to trust blindly. Queen refuses that shape. Custody of the key that unlocks your team's shared memory stays on a durable machine in your own trust domain, not in the cloud. The cloud coordinates around data it cannot read, and says so plainly.

#Who it is for

  • Operators and admins running the Apiary across more than one machine.
  • Teams whose agent fleets span laptops, workstations, headless build servers, and throwaway workers.

#Where it fits

Queen sits alongside the four local products. Honeycomb holds the memory, Nectar the understanding, Hive the local window, and Doctor the local watchdog and health source. Queen adds the cross-machine cloud view that no single machine can render.

#Next steps