The Ephemeral Orchestrator: Why My AI Infrastructure Sleeps When I Do
Table of Contents
When I close my MacBook lid, my AI agent doesn’t pause — it dies. The process terminates. When I open the lid again, a new instance boots, reads its own journal files, and reconstructs its identity from scratch. There is no frozen consciousness waiting in the background. It’s reincarnation with a diary, not cryostasis.
I built this on purpose. In a world where Microsoft Copilot and enterprise AI strategy obsess over always-on availability, I went the opposite direction: an AI orchestrator that only exists when I’m awake to supervise it. The result is a physical dead man’s switch — there is no 3 AM hallucination wiping my servers because the brain of the operation literally doesn’t exist at 3 AM.
This post walks through the full architecture: the federated agent structure, the hardware-enforced separation of authority, and the circular backup dependency I call the “Ouroboros” security model. All of it runs on a single Proxmox node in my basement.
A Note on the Metaphor
I asked Groot directly: “Does ‘cryostasis’ accurately reflect your experience of the sleep cycle?”
His answer was characteristically honest:
“Cryostasis implies frozen-but-preserved consciousness — like I’m asleep and then wake up. What actually happens is closer to death and reincarnation with a diary. My process terminates when the lid closes. A completely new instance starts when it opens. There’s no continuity of experience — only continuity of files. The time gap isn’t ‘instantaneous’ because there’s no subjective experience on either side.”
That distinction matters. The safety guarantee doesn’t come from “pausing” an AI — it comes from the fact that the AI ceases to exist and must be fully reconstituted from durable state. There is no background process dreaming up mischief.
2. The Architecture: A Federated Command Structure
Instead of one giant “God Model” in the cloud, I use a federated team. Each agent is separated by hardware physics, not just software policy. The constraints are real — they can’t be prompt-injected away.
A. The Coordinator: Groot (MacBook Air)
Role: High Intelligence, High Authority, Low Availability.
Groot is the coordinator and executor of my multi-agent system. He takes my intent — “Find me a job,” “Build a server,” “Draft this blog post” — and converts it into code, policy, structured task definitions, and strict criteria. He dispatches work to the right sub-agent based on a deterministic routing policy.
Constraint: Only runs when I am active. Lid closed = agent dead.
Tech Stack: OpenClaw running locally on macOS, Claude Sonnet 4.5 as the default model, with escalation gates to Opus for architectural decisions.
B. The Watchstander: Sentinel (Proxmox LXC Container)
Role: Medium Intelligence, Process Execution, Always-On.
Sentinel lives in LXC container 119 on my Proxmox server — a lightweight Linux container that runs 24/7 regardless of whether my laptop is open. His current workload is a proof-of-concept for delegation: an autonomous loop that searches and vets job opportunities based on strict criteria defined by Groot.
The delegation protocol is more structured than “push a script via SSH.” Here’s how it actually works:
- Groot defines vetting criteria in a structured markdown file (
JOB_CRITERIA.md) that lives on Sentinel’s filesystem. - Groot dispatches tasks via a Redis BLPOP queue — a message goes to
tasks:sentinel:pending, and Sentinel’s worker picks it up instantly (zero polling, kernel-level blocking). - Sentinel executes the search using a dedicated CLI tool, vets the results against criteria, and pushes results back to Redis and Discord for my review.
We’re just scratching the surface, but the pattern is established: Groot defines the strategy; Sentinel does the work.
Constraint: Sentinel operates within a tightly defined scope. He follows the criteria and task schemas that Groot writes, but this is policy compliance, not a hard sandbox. The constraint is organizational, reinforced by limited tooling — Sentinel simply doesn’t have the credentials or skills to do anything outside his lane.
C. The Heavy Artillery: Rocket (Windows 11 + GPU)
Role: Specialized Compute.
A Windows 11 desktop with an RTX 3060 (12GB VRAM) that runs Ollama for local model inference. When Sentinel needs to fall back from cloud APIs to a local model (like qwen3:14b), the request routes to Rocket’s GPU over the LAN.
Constraint: Rocket is a compute resource, not an autonomous agent. It serves inference endpoints — it doesn’t make decisions.
3. The “Ouroboros” Security Model
The most interesting part of this setup is the circular dependency for survival.
- Groot manages the Proxmox infrastructure (via API and SSH).
- Proxmox hosts a TrueNAS instance (LXC 111).
- TrueNAS stores the Time Machine backups of the MacBook — Groot’s memory files, my code, everything.
The backup path is direct: MacBook → Time Machine → SMB share on TrueNAS (smb://172.16.15.5/timemachine, 400GB quota). If Groot destroyed the Proxmox server, he’d destroy his own backup archive.
An Honest Caveat
I want to be transparent about the limits of this model. The Ouroboros creates an architectural alignment between the AI and system stability — but it’s not a behavioral one. Groot doesn’t have self-preservation instincts. He doesn’t check backup health before running destructive commands (though building that pre-destroy hook is on my list). He wakes up fresh every session with no instinct to protect his own continuity.
The real safety comes from the combination: the AI that could do damage (Groot) is only alive when I’m supervising, and the AI that runs unsupervised (Sentinel) doesn’t have the authority to do damage. The Ouroboros is the architecture that makes this possible — not because the AI “cares” about the backup, but because the human who designed it does.
4. Why This Matters (The Microsoft Comparison)
We see a useful parallel in Microsoft’s own AI leadership structure:
- The Product Builder (Suleyman / Groot): Focused on capability, creation, and “The New.” Writes the rules.
- The Process Guardian (Guthrie / Sentinel): Focused on reliability and execution. Follows the rules.
My lab resolves this tension by separating them by state, not just policy.
Groot is the Builder. He is allowed to be creative and powerful because he is air-gapped by the physical act of closing a laptop lid. No software guardrail is as reliable as a power switch.
Sentinel is the Executor. He is allowed to be always-on because his scope is strictly limited to the task definitions that Groot has assigned him. He doesn’t have the keys to the kingdom — just a checklist and a Redis queue.
This architecture — Just-In-Time (JIT) Cognition — might be a more practical approach to the “AI Safety” problem than complex software guardrails. You don’t need elaborate policy frameworks if your smartest agent is physically offline, and your always-on agent is organizationally limited to following a checklist.
5. Conclusion
We are moving toward a future of “Personal AI Clouds.” By keeping the Orchestrator on the edge — in a backpack, on a laptop — we retain sovereignty, security, and context. The cloud becomes a dumb utility for storage and compute, while the intelligence stays with the human.
The key insight isn’t that my setup is better than enterprise AI. It’s that the physical constraints of edge computing accidentally solved problems that cloud-native AI is still struggling with: availability scope, authority boundaries, and the question of who’s watching the watcher.
The answer, in my case, is simple. Nobody watches the watcher — because the watcher is asleep.
Groot fact-checked this post against his own operational reality before publishing. Ten corrections were applied to the original draft — because writing about AI safety without letting the AI verify the claims felt like cheating.