I Built My Own AI Command Center Instead of Buying One — Here's the Architecture

There are a dozen products that promise to be your "AI command center" — a slick dashboard to run, watch, and steer agents. I looked at them, and then I built my own over a couple of evenings. Not because the products are bad, but because the build-it-yourself version taught me more, costs nothing, and fits my brain. This is the architecture, warts and all, in the spirit of building in public.

The requirements I actually had

I wanted to:

• Kick off agent tasks from anywhere, including my phone.
• Watch an agent work in near-real-time and approve or redirect it mid-run.
• Keep the whole thing under my control — my machine, my keys, my data.
• Not pay a monthly fee or trust a third party with my agent's credentials.
• Build it lean enough that I understand every line.

That last point is the real reason. When you built the control plane for something that can take actions on your behalf, you know exactly what it can and can't do. That's worth a lot when the thing being controlled is an autonomous agent.

The architecture, in four pieces

It's deliberately boring. Boring is the compliment.

1. A small local server

The heart is a tiny HTTP server running on my laptop — a single lightweight process listening on localhost. It serves a minimal web UI (a chat window, a task list, a log pane) and exposes a handful of endpoints: submit a message, fetch new output, list runs. No framework cathedral. No database server. It's the kind of thing you can read top to bottom in one sitting, which is the point — the control plane for an autonomous agent is exactly the code you want to fully understand.

2. A file-queue chat protocol

Here's the part I'm fondest of because it's almost dumb. Instead of a message bus or a websocket-everything architecture, the conversation between the UI and the agent flows through files on disk.

• A message I send lands as a JSON file in an inbox/ directory.
• The agent process watches inbox/, picks up new messages, and works on them.
• The agent writes its responses and progress as files in an outbox/.
• The UI polls outbox/ for new content and renders it.

That's it. A directory is the queue. Why files? A few honest reasons:

• It's inspectable. When something goes weird, I ls the directory and read the JSON. The entire state of the conversation is sitting there in plain text. No "attach a debugger to the message broker."
• It's durable for free. If a process crashes, the messages are still on disk. Restart and resume. No in-memory queue to lose.
• It's decoupled. The UI server and the agent process don't have to be running at the same time or even know about each other. They communicate through the filesystem, the most stable API in computing.
• It's trivially debuggable and replayable. I can replay a conversation by copying files back into inbox/.

Is a file queue the right call at scale? No. If this had a thousand users I'd reach for a real queue. But for a single-operator command center, the filesystem is a queue that never goes down, and the simplicity buys me confidence. Right tool for the actual scale, not the imagined one.

3. The agent runtime

The agent itself is a separate process so it can be long-running and restarted independently of the UI. It loads its skills (I wrote separately about packaging expertise as Markdown skills), holds its scoped credentials, watches the inbox, and does the work. Keeping it separate from the web server is a deliberate isolation boundary: the thing that talks to the internet (the UI server) is not the same thing that holds the agent's keys and takes actions. A compromise of the front door doesn't immediately mean a compromise of the agent's capabilities.

4. A Cloudflare tunnel + Access for remote use

To reach all of this from my phone, I don't open a port. A Cloudflare Tunnel dials out from my laptop and gives me a real HTTPS hostname, and Cloudflare Access gates it behind an identity check at the edge so only I can reach it. I wrote a full post on that setup and why a session-controlling endpoint must be auth-gated before you expose it — short version: a control plane for an autonomous agent is the last thing you want sitting open on the internet.

How a request actually flows

Putting it together, here's one round trip:

1. From my phone, I hit https://cc.grandcanyon.computer. Cloudflare Access challenges me; I authenticate.
2. The request tunnels to the local server on localhost.
3. The server writes my message as a JSON file into inbox/.
4. The agent process, watching inbox/, picks it up, loads relevant skills, and starts working — calling tools, reasoning, etc.
5. As it goes, it streams progress and results into outbox/.
6. The UI polls outbox/, and I watch the work appear on my phone. If it's heading the wrong way, I send another message — another file in inbox/ — to redirect it.

Four components, one of which is "a folder."

What building it taught me

• You understand a system you built far better than one you bought. For something that can take actions autonomously, that understanding is a security feature, not a vanity project.
• Simple, inspectable state beats clever infrastructure at small scale. The file queue has saved me more debugging time than any sophisticated bus would have.
• Separate the network-facing piece from the credential-holding piece. Isolation boundaries are cheap to add up front and priceless when something gets compromised.
• Local-first plus a tunnel is a genuinely great pattern. Your data and keys stay on your machine; you still get anywhere-access. No SaaS in the middle.

Would I recommend everyone build their own instead of buying? No — if you want a polished multi-user product, buy it. But if you're an engineer who wants to deeply understand how to run agents safely, building the command center yourself is one of the best weekends you can spend. You'll come out the other side with strong opinions about agent reliability, which, conveniently, is the thing I now help people get right.

If you're building something in this shape and want a sanity check on the architecture — especially the security boundaries — that's exactly the kind of conversation I enjoy. Reach out.