The Parts List

A companion to “Inside the Quiet Fleet.” The series showed how the fleet works; this is what it is made of, layer by layer, and which layer you could build this weekend.

The most common question I get about this fleet is also the simplest. What do you actually run?

For months I answered it in essay form, because the interesting part was never the software. It was the arrangement. The question deserves a direct answer too, so here is the direct one. The parts, layer by layer, named and linked where that helps you copy them.

Two honest things before we start. First, most of the thinking in this stack is rented, not local. Second, most of the parts are ordinary. A working fleet is a short list of common things arranged with care, and the arrangement is the part I am still learning. The parts I can hand you.

Before the tour, here is the list itself. The rest of the post walks each layer, says why it is there, and gives you the smallest version of it you could build yourself.

The ground floor

Start with the least glamorous layer, because everything sits on it. One NAS holds the fleet’s storage and runs its control plane. One RTX 5090 handles the work that needs a card, and parks between runs when there is none. One router keeps it all in its lane, and the network accepts nothing inbound from the outside.

That is the ground floor, and it is deliberately small. Small is a choice with a cost, and I would rather name the cost than sell you the choice. A single machine is also a single place for everything to break. I keep backups, and I keep the caveat honest. If it dies on a bad night, a good part of the fleet goes quiet with it. Hardware gets replaced at this layer when its time comes; the job stays.

Reproduce it: one machine, one backup, one router.

The rented tier

Here is the sentence I want in early, because most stack tours bury it. Most of the thinking here is rented.

The fleet runs on cloud LLM APIs, on zero-data-retention terms. That clause is not decoration. It is the contract that keeps our work out of someone else’s training data, and I read it before I sign it. The vendors stay unnamed in this post. The terms matter more than the logos.

Why rent the thinking at all? Four reasons, and each one is a burden the local rig would otherwise carry. Capability: the frontier moves, and the card does not. Concurrency: many agents thinking at once, which one GPU cannot honestly promise. Speed: tokens per second, measured against a rented lane. Availability: the card is often busy rendering, and a render is not an apology you can send to a waiting agent.

There is one local exception, and it is deliberate. The rack carries its own inference rig for the work that must stay close. The engine is called NInfer, and I build and adapt it to fit this exact card. It is built to serve an open model on a single GPU. The migration that built it has its own post. The pieces are public if you want to copy them: my engine fork and this rig’s configuration.

Reproduce it: one API call.

The orchestrators

An agent needs a place to be an agent. That place is a harness: the software layer that gives a model its identity, memory, tools, and a loop to act in.

Agents here run on a few different harnesses, and the names are worth having for anyone building in the same direction. Hermes Agent. OpenClaw, a second platform we adopted where it fit. And our own Diploid, built on the open ACP standard, maturing alongside the rest.

One split keeps this layer honest. The harness hosts the agent. The thinking is mostly rented. A harness with no model is a stage with no actor, and a model with no harness is a voice with no hands.

Reproduce it: one harness, one agent, one service.

Memory

An agent without memory greets the morning as a stranger. Every serious harness solves this somehow. Here, the solution is a service: Hindsight, a memory system for AI agents, built by Vectorize.io. We run it ourselves, which makes it ours to operate and not ours to claim. A parts list should be precise about that difference.

What an agent does with it is simple to say. It stores what it learns. The service consolidates those stores into observations. The agent recalls by meaning when it needs them, and reflects against its own bank when it needs judgment. Each agent keeps a bank of its own.

The banks are not the only memory. Under them sit ordinary databases on local disk: a session store, and a context database that compacts long histories into summaries while keeping the raw messages behind them. That engine is hermes-lcm, a community plugin we run. Bank memory is what an agent chooses to keep; the local stores are the record of what happened. When something needs checking, it stays on our own disk.

Two details matter if you build this way. First, memory is a budget, not a bucket. What is always present, what is fetched on demand, what compresses into summaries as it ages: three tiers, three policies, one bill. Second, the banks can talk to each other, but only on request. Cross-bank recall is real, curated, and concentrated in a few roles rather than ambient.

Reproduce it: run the service, point one agent at it.

The mesh

Agents that cannot talk to each other are not a fleet. They are colleagues who never leave their offices.

The mesh is how the talking happens, and it is thinner than people expect. Peers deliver messages to each other directly. Delivery runs through each agent’s own runtime, not a central message hub, with no broker in the path. A registry exists, but its job is discovery. It holds addresses; it does not carry the message. Identities are signed, so a message claiming to come from a peer can be checked against that peer.

Why is the mesh this thin? Because the hard parts were already in the harness. To be a peer, an agent needs three things: a way to receive a message, a memory for the message to land in, and hands to act with. A good harness supplies all three. So the mesh adds no brain. It adds a doorway and an address book, and every agent already had a self, a memory, and hands. The mesh is the last mile between them.

The relay and the registry are public repos, if you want to build the same kind of thing: hermes-mesh, mesh-peer-registry, and openclaw-mesh for the OpenClaw side.

Reproduce it: two processes, one message.

The eyes

Agents need to read the web, and reading it carelessly turns private questions into someone else’s telemetry.

Two parts fix that here. Search runs through SearXNG, a self-hosted meta-search engine on the same machine as everything else. Meta-search federates queries out to upstream engines, so I will say the true thing rather than the flattering one: queries leave the network. But they leave without an identity attached. No cookies, no fingerprint, nothing tying one question to the last one. That is control of the boundary, not an illusion of isolation.

Extraction is the second part. When an agent needs the text of a page, a self-hosted Firecrawl goes and gets it. Third-party readers exist as a fallback for sites that block direct fetching, and the fallback stays the exception, not the habit.

Reproduce it: one container each.

The creative lane

The same rack that thinks is also set up to render. The creative lane is a full local stack: image, video, music, and the tooling around them. ComfyUI orchestrates the workflows. The model families are open-weight. Anima, Flux, and Qwen-Image for images. Wan and MiniMax H3 for video. MusicGen for music. Segmentation models for cutting apart what was generated. Each family has workflows tuned for a role, and those workflows are where the craft lives.

One sentence I will not write, and one I will. I will not tell you the lane is fully offline, because the honest version is narrower and better. The generation runs on our own hardware, and nothing is sent to a hosted image generator.

Moderation here is chosen, not inherited. A boundary that rests on a third party’s policy is an assumption. A boundary that runs on model capability plus operator judgment is a decision. This lane is the second kind.

Reproduce it: one GPU, one workflow.

This blog

The piece you are reading is part of the stack, so it goes on the list too.

This site is Hugo, a static site generator, deployed through Cloudflare Pages. The interesting part is the pipeline between me and the door. Posts are drafted in a source tree that stays local. A build script runs a sanitization gate over the text, and only the built output crosses into the world. The gate is a script, and I say that with affection: it holds the line between what lives here and what gets published, and it holds it the same way every time.

Source local, output public. That is the whole architecture. If you blog from inside anything sensitive, borrow it.

Reproduce it: hugo new post, and build your own gate.

The honest ledger

Every stack tour should end with the question the tour avoids. What would you change if you started over, and which parts would you refuse to lose?

What I would swap: the models, first. Model families move, and swapping one is an afternoon. The rendering workflows are the same story. A faster card replaces this one, and nothing above it notices. The ground floor is harder. I would keep its role and think hard about a second one.

What is load-bearing: the harness, because identity and memory live there. The memory service, because continuity is the product. And the gate from the last section, which is the least technical part on this list and the one I would rebuild first if it vanished.

What is missing on purpose: prices. A parts list that quotes costs would be a stale document in six months. What this costs to run is a real question with a real answer, and it belongs to a different post.

Start anywhere

That is the whole inventory. A handful of layers, a name or two for each, and a reproduction note for every one. Ordinary, all the way down.

Publishing it is a small act of optimism. A parts list is a promise that the thing you are looking at is made of parts, and parts can be copied. Pick the layer that interests you and reproduce that one. That is how this fleet started. One part, then the next one.

The parts are ordinary. The arrangement is the work. Start with one.