Welcome to the
Kingdom

A kingdom isn't one big building. It's a collection of houses, each with its own purpose, its own people and its own business, under a shared charter that says how they treat each other. There are roads between them and heralds who carry messages. There's a foundry that makes the tools everyone uses, an assay office that tests metal before anyone trusts it, and a crown that makes the decisions nobody else gets to make.

That's the shape I needed. My projects didn't want to be merged into one giant workspace. A security practice and a home-automation project shouldn't share assumptions about what's true or who may act. They could share methods, though: how to remember, how to hand work off, how to test a claim, how to ship something safely. So the projects became houses, and the methods became shared crafts any house could use. I'm the crown. The agents do an enormous amount of the work, but consequential decisions come back to a person.

You'll see names in this series like Foundry, Hearth, Bellows, Forge and Cupel. Each one is the name of a job in that world. There's a story behind them, which I'll get to in a moment.

It didn't start as a kingdom. It started as a set of operating documents.

In early 2026 I was helping a small operations business get its processes written down, with an AI assistant doing much of the drafting. To keep that work consistent from one session to the next, I wrote myself a collaboration standard: a plain document telling a fresh session how I work, what's current and what's been decided. I called it CPS.

Then I took the same habits into penetration-testing work, and they mostly held. Next came Pharos, an attempt to get at business-logic vulnerabilities in applications: the bugs where every request is valid and the sequence is the problem. It's named after the Pharos of Alexandria, the lighthouse that gave many languages their word for one. A lighthouse doesn't search the sea; it's a fixed reference that makes the rocks visible. Pharos tries to do the same for an application: build a model of what it's supposed to do, shine it on what it actually does, and let the difference show. Good tooling for that was hard to build at the time. But while working on it I kept noticing the same ideas showing up in every project: how to remember, how to hand off, how to test a claim. I wanted one central agent that could help all of them. I imagined it as an orchestrator, and I couldn't make that work at that level.

What I could build was a steward. That became Foundry: not a boss over the other projects, but the place where shared tools get made and maintained. Once Foundry existed, the projects around it needed to become distinct places with their own records and decisions. I call them nodes. For a while I called the whole arrangement the Estate.

The names kept coming. I started borrowing from fire, metal, elements, geometry and biology to describe what I was trying to build: a forge for designing, a foundry for making, a lattice for how things bond and connect. The lab was supposed to be a "proof house," and the name never fit. It became Cupel, after the small vessel assayers use to separate precious metal from everything else. Eventually the Estate needed a name that could hold all of it, and it became the Dunvaric Kingdom.

To find the right shapes, I started telling stories.

Alongside the working system there's a creative one: a fictional realm called the Dunvaric Sovereign. The name pairs the Celtic dún, a fortress or stronghold, with vár, an oath and a watchfulness. In that world there's a great Foundry whose fires never go out, a registry of high scrolls where every made thing carries an unforgeable seal, sealed sanctums where dangerous experiments can fail safely, and an order whose job is to test the realm's defenses before an enemy does. Each piece of the fiction started as a way of asking what a part of the real system should be.

There are several of these stories now, and the idea was always a loop: the Kingdom feeds the fiction real problems, and the fiction feeds the Kingdom fresh ideas. I'll be honest that the loop has never been wired. That's a story for another day, and a good one.

Here's the map at the highest level.

The people and the rules. A charter sets the floor for everyone: who can decide what, what an agent may do on its own, and what always waits for me. Publishing, spending money, anything destructive, and any genuinely new direction come back to a human. Ordinary reversible work goes ahead without asking. That balance took a long time to find. Too many gates and nothing moves; too few and an agent's confidence becomes the decision.

The houses. Each node works on its own questions.

• Foundry stewards the shared architecture and the releases every house depends on.
• Cupel is the independent lab, and the one place that gets to tell a builder "not yet."
• House Thalis works on offensive-security methods and agentic security systems. The name comes from the Dunvaric story: Thalis is the martial house, home of the orders sworn to find a realm's weaknesses before an enemy does. That's a fair description of a penetration tester.
• Pharos studies application authorization: the gap between a request that works and one the caller was actually allowed to make.
• The Homestead runs local systems, resilience and on-premises AI for the land I live on.
• Volpe Vista is an experiment in agentic decision-making for markets. It senses, reasons and measures, then works through paper and shadow trading before anything touches real money, and only I can fund it or switch it on. I've invested real time and resources in it, and it's getting close to launch.
• RobHunterLabs, where you're reading this, turns selected work into things other people can use.
• The Operations Realm. It's federated with the Kingdom and runs on the same systems (memory, messages, shared tools), but it operates as a realm of its own, with its own operator, records and decisions for its own needs. It's where the Kingdom is learning to include an operator who isn't me.

The shared crafts. These are what make it a kingdom rather than a pile of projects:

• Remembering. A project can be woken up, oriented and checked for drift, and the day's decisions get captured and saved, so the next session picks up where this one ended.
• Talking. Requests travel between houses with receipts, so "sent," "read" and "accepted" stay three different things.
• Sensing. Open questions can be left standing, so that when something new turns up, from a newsletter, a paper or a finding, it gets matched against what I'm actually waiting to learn.
• Designing. Before anything gets built, the premise gets questioned, the alternatives get a fair hearing, and a design gets attacked from a different angle than the one that produced it.
• Building. A build starts with who will use it, and it is allowed to stop, return, or be split instead of pushing toward a finish line.
• Testing. The bar for success is written down before the test runs, and someone other than the builder checks the result.
• Shipping safely. Code and tools travel as exact, versioned releases, kept separate from the question of which version actually reached which agent on which machine. Those are different facts, and I've learned to check the second one.
• Defending. Outside content is treated as data, never as instructions. Anything leaving for the public gets checked for what it might leak.
• Speaking. Private work gets translated into writing like this, in my voice, with the claims kept honest.

What comes out. Articles, open-source companions, a public penetration-testing practice framework, field studies, research and a few ventures. These are outputs of the Kingdom, not the Kingdom itself, and each deserves its own story.

On a typical working morning, I open a node and its agent rehydrates it: what the board says, what changed overnight, what's waiting for me. A standing question I set weeks ago might have matched something new. Foundry might have sent a message saying a change I asked for has landed in the next build. An agent might be partway through a design, with another agent attacking it. And somewhere in the lab, a result I was hoping for might have come back marked "not yet."

My job is mostly the part that was always supposed to be mine: deciding what matters, choosing between real alternatives, and saying yes or no to anything that leaves the building.

It isn't free and it isn't finished.

The structure has weight. There are days when the record-keeping feels heavier than the work, and I've had to keep cutting ceremony back out. Things still drift. As recently as this week, a project's saved state passed its own freshness check while describing a world that had moved on. The check measured the date, not the content. Agents still overclaim; "done" remains a word I verify rather than trust. And a good share of what I've described is designed and partly built, not proven. Some of the security work in particular has been carefully designed and barely attacked yet.

I'd rather show you that than pretend otherwise. The rough edges are where most of the learning has come from.

It's easy to describe a system like this as if it runs itself. It doesn't, and the honest line between automatic and human is one of the most interesting things about it.

Some things really are automatic. When an agent opens a project, an orientation step fires on its own and points the agent at the right records before it does anything. Every time the day's notes are folded into a project's memory, standing checks run and flag anything that has drifted. A project can't save a snapshot that its own integrity check says is false. Messages between houses route themselves the moment they're sent.

Some things are wired by rule but still depend on an agent remembering. The rule says an agent captures each decision as it happens and saves state at the end of a session. This week I found dozens of sessions that did the work and never wrote the notes. The rule existed; nothing forced it. That gap between declared and wired is the same one I wrote about in Declared, Not Wired, and finding it in my own system was humbling.

And a lot is still me, by design. Anything published, merged or deployed waits for my go. So does spending money, deleting things, or starting a genuinely new direction. Scanning the outside world for signals still happens when I ask, not on a schedule. And the next generation of the Kingdom, which I'm calling the Expeditionary Kingdom, is a design being built in a separate space, not something I'll claim before it runs.

There's a bigger honesty underneath all of this: the Kingdom runs only while I'm running it. When my laptop is closed, nothing moves. Messages wait in their mailboxes, Foundry doesn't wake up to answer them, and no background process dreams up new connections. Most days the Kingdom is me opening a session, waking a node and asking it to do something, then doing the same in the next window. The best days are when one session takes on the role of conductor, spins up the others and keeps the work moving, but I'm still the one who starts it.

So the honest description is a disciplined way for one person to direct a lot of agent work, not an autonomous system. Making it keep running when I step away is the next real problem, and moving each line from "me" to "wired" to "automatic" has to earn its place.

Almost nothing here is new on its own. Persistent agent memory, skill libraries, multi-agent orchestration, design reviews, preregistered experiments and versioned releases are all established ideas, and other people have built excellent versions of them. Daniel Miessler's Personal AI Infrastructure runs a personal assistant with persistent memory, dozens of skills and security checks on every tool call. Steve Yegge's Gas Town coordinates fleets of coding agents, with a Git-backed memory of what was done and why. Its hosted cousin, Gas Town by Kilo, keeps those towns running in the cloud, and its Wasteland project aims to federate many of them. OpenClaw puts a personal agent behind your messaging apps. Skill frameworks like Superpowers give coding agents a disciplined plan-then-build workflow. I've learned from all of them, and some of them already solve the always-on problem the Kingdom hasn't.

What I haven't found, after a lot of looking, is one place that puts these together across unlike kinds of work. Here security practice, research, home systems, markets, writing and a separately operated realm each keep their own authority, under one charter. The builder never grades its own work. The same methods are released to several different agent platforms, with an honest record of which version actually reached each one. And stories turned out to be a design tool. If you know of something that covers that scope, I genuinely want to see it. That comparison would teach me more than anything else I could read.