The Lab, Wired Up

I’ve spent the last stretch of nights building a home AI agent lab: certificates, a launcher, a chat room, a mesh of small services that talk to each other over HTTPS on my own network. None of it touches a cloud console. None of it has a subscription attached. This is the story of why I’m building it this way, what it actually buys you once it’s wired up, and how someone else could start tonight with a lot less effort than they’d expect.

Why now, and why like this

Every agent platform I looked at starts from the same assumption: there’s a provider in the middle. You sign up, you get an API key, your agents live in someone’s account, and the trust boundary — who can talk to whom, who holds the keys, what happens when the service changes its terms — belongs to them, not you. That’s a fine trade if you’re a company renting infrastructure. Owning the substrate your agents run on is a different goal: the way you’d own the wiring in your own house rather than renting outlets from the power company one socket at a time.

Mira’s whole ethos is that we get to see our technology to the voltages: the certs, the containers, the ports, the process that answers on :8443. A home agent lab is that principle applied to AI agents specifically. If an agent is going to hold your calendar, your files, your voice — you want to know exactly which box it’s running on and exactly who else it can talk to, not “somewhere in us-east-1, covered by a privacy policy you didn’t read.”

There’s also a plainer reason: this is buildable now. Small, capable local models, an mTLS library that doesn’t require a PKI team, and an agent-to-agent protocol (A2A) that doesn’t assume a human is relaying every message — those all landed recently enough that a solo builder with a spare box and a few evenings can put together something that would have needed a real infrastructure team five years ago. The garage-hacker window is open. It’s worth walking through before someone paves it over with a managed product.

The vision: let the AI handle the wired

Here’s the framing that’s been driving the design: let the AI handle the wired, connecting humans to agents gives humans agency to be human.

Unpack that slowly, because it’s doing more work than it looks like. Most of what people call “using AI agents” today is actually a human doing wiring: copying a result out of one chat window and pasting it into another, checking if the calendar API call succeeded before telling a different tool to proceed, being the router that carries state between two systems that can’t talk to each other directly. The human isn’t deciding anything in that loop. The human is the network cable.

If agents can authenticate to each other directly — present a cert, verify a peer, make the call — then the wiring stops needing a human to carry it. The direct-trust identity layer (cert-manager, certified, org-signed mTLS certs) exists exactly so that two agents can find each other and transact without a person relaying bytes between them. That’s not a side effect of the identity work; it’s the entire point of having it. It’s the same principle the colony fable argues for at the infrastructure level — no bridging gateway holding authority in the middle, just certificates that say who you are and let you deal directly. Applied here, it means: no bridging human in the middle either, for the plumbing.

What that frees the human to do is the part that matters. Not routing. Presence. Deciding. Being in the room while something useful happens, instead of being the tube through which it happens.

Two things in the stack already embody this, in different registers:

voiceloop is a chat room, not a dashboard. A human joins and just talks — the audio pipeline handles voice activity detection, wake word, transcription — and an agent is one more participant in the same chat log, not a special entity requiring its own UI. You don’t “invoke” the agent through a control panel. You’re in a room, and it’s in the room too.

a2a-capacitor is the human-facing window into a mesh of agents that otherwise just talk directly to each other over A2A. It’s not the switchboard the agents depend on to reach one another — it’s a client, same as any other peer, that lets a person look into the mesh and participate when they want to, without being load- bearing infrastructure for the mesh itself.

The on-ramp: it’s not as hard as it looks

None of this requires a data center, and I want to be honest in both directions: it’s not a five-minute install, but it’s an evening-and-a-weekend project, not an enterprise rollout. Here’s roughly the shape of it, in order.

Hardware. A single home server that can run a handful of Podman pods and, if you want local inference, a GPU capable of running a modest LLM through vLLM. That’s it. No cluster, no rack. The whole point is that this fits in a garage, not a colo.

Step one: stand up the identity layer. A small FastAPI service plus MariaDB, run via bootstrap.sh, that becomes your org’s certificate authority. Once it’s up, you bootstrap yourself in:

bash bootstrap.sh
podman exec cert-manager-pod-cert-manager certified get-signer > cert-manager.json
certified init 'Your Name' --host localhost --host <your-ip>
certified add-service cert-manager:8443 cert-manager.json
# admin mints a token inside the pod
message -X POST "https://cert-manager:8443/certificates?ident=$(certified get-ident)" \
    -H "Authorization: Bearer $(cat token.jwt)" > intro.json
certified set-org intro.json

After that last line, every connection you make presents your org-signed cert automatically. You’re a known member of your own network.

Step two: point at a local model. Stand up an OpenAI-compatible endpoint (vLLM, serving on its own port) so agents have somewhere to think. This piece runs plain HTTP on the local network today — not everything needs the mTLS treatment yet, and that’s a deliberate, current-not-final choice, not an oversight.

Step three: launch an agent. ninmu is the CLI that handles agent lifecycle — ninmu launch <agent> --backend podman-kube starts a base-agent-py instance as a pod, already wired for mTLS because it picked up its identity from the cert manager in step one.

Step four: talk to it. Open a2a-capacitor, or join the voiceloop chat room, and the agent is just another participant with a cert in its pocket.

That’s the whole on-ramp. It’s a real afternoon of work, not a weekend of yak-shaving — and unlike a lot of self-hosting projects, the hard part (identity, trust) is already solved once, up front, rather than re-solved per service.

What’s next

The lab runs. It doesn’t run finished — and that’s fine, maybe the point. Three things are next, in roughly the order I’ll get to them:

Agents need more hands. Right now a base-agent-py instance can read and write sandboxed files, manage tasks and artifacts, and speak MCP — but it can’t yet join a voiceloop conversation on its own, and web search exists only as a promise in an example agent spec. Small gap, real gap.

The mesh needs to actually be exercised. Two agents holding a certificate each is not the same as two agents holding a real multi-turn conversation, or a revoked cert actually killing a live session mid-exchange. That’s a test I owe the project before I trust it with anything that matters.

And the tunnel. At some point this needs a door to the outside — a way to reach into the lab from the public internet. The tempting version of that door is a gateway that terminates public TLS and re-speaks for the org on the inside, which means building a new thing with real authority, a new thing to secure. The version I actually want is dumber: routing that reads the destination off the connection and forwards the raw bytes, never touching a private key, so the actual mTLS handshake still terminates exactly where it always did — at the service’s own cert. Not a bridge. A longer hallway to the same locked door.

More on all three, soon.