The Compute Layer

If Command is the brain, Compute is the muscle. It's the AI turning on at night. Cloud Code running scheduled tasks. Your Mac M4 running Olama with Google Jemma 4 for offline work. Cloudflare Workers staying always-on. MCPs handling APIs you don't want to build from scratch. Compute is the work, executed under Command's authority.

What's actually in mine

My current compute layer, mid-2026:

• Local: MacBook M4 Pro, 64GB RAM. Runs advanced AI models offline (Olama with Google Jemma 4, others). Limitation: I travel, so always-on local jobs are unreliable.
• Always-on cloud: Cloudflare Workers handle most always-on work. Tiny cost, edge-deployed, scales to zero when idle. Plus DigitalOcean VPS for jobs that need persistent state. Plus Railway for things that need a longer-running container.
• Scheduled AI work: Claude Code runs research and content jobs on cron. Switched from local always-on to OpenClaw API after local jobs kept breaking on travel, costs about $1/month for the kind of nightly research we do, and it just works.
• MCPs for friction-rich integrations: Social posting (Zernio API, handles the maintenance burden of staying approved on Facebook, TikTok, Instagram, LinkedIn). Linear, Granola, Google Workspace, Cloudflare itself. Anything where the maintenance burden of building it from scratch outweighs the cost of a good MCP.
• Frontier-model access: Claude Opus and Sonnet for the heaviest reasoning. Cheaper models for the volume work. Choose by job.

The decision tree: code vs MCP vs worker vs SaaS

Honestly, it depends. But here's the heuristic I use:

• Code it from scratch if the logic is unique to my business and I'd want to control it indefinitely.
• Install an MCP if a well-maintained one exists for the integration. Don't recreate Linear's API surface; use the Linear MCP.
• Deploy a worker when I need always-on, low-cost, edge-fast execution. Cloudflare Workers are my default.
• Just use a SaaS if the maintenance burden of self-hosting outweighs the cost. Zernio for social scheduling is the canonical example: I could build it, but the API maintenance against five different platforms isn't worth my attention.

The decision criteria: why do you need it, what's the urgency, what does it touch, what's the security surface, and the underrated one, do you actually like doing this work? Nothing's worse than making yourself do coding you don't want to do. Stay in your zone of genius. Let compute take care of the rest.

Hierarchy of trust

Not every agent should run autonomously. The hierarchy I use:

1. Fully autonomous: Read-only research, content drafts that go to a queue, scheduled refreshes of cached data. No risk to live systems.
2. Autonomous-with-PR: Agents that can write code or content but only via a pull request I review. The HBOT Finder nightly research bot lives here.
3. Captain-approved: Anything that touches money, customers, or production. Send draft to me; I approve.
4. Captain-only: One-way door decisions (per Bezos's framework), strategic pivots, hiring, pricing changes. The captain owns these. Agents don't get to make them.

The deletion test for Compute

Before adding a new tool, agent, or worker, I run a deletion test on the existing one. If I delete this thing, what breaks? If the answer is "nothing worth caring about," it goes. If "lots of dependencies," I think harder before adding the new thing on top.

Three questions to ask before adding anything to Compute:

1. What dependencies will this affect? Are we coupling things that should stay decoupled?
2. What does it contribute that nothing else does? If the answer is "convenience," that's not enough.
3. What new risk does it introduce? Security surface, ENV file exposure, data movement, vendor lock-in.

I've deleted plenty of agents and been glad I did. Most of them were "cool but not load-bearing." The compute layer should feel spare. Every component earns its slot.

Captain managing 20+ agents without going crazy

The trick is not to manage agents. It's to manage the feedback layer.

Healthy operators don't watch their agents work. They give the agents something to start with, let the agents deliver something, then engage at the review point. Judge the output, not the keystrokes. If you're orchestrating each agent step-by-step, you've left the captain's bridge and become a violin teacher correcting individual notes, meanwhile the audience is walking out.

This transitions naturally to the Cadence layer, where the feedback layer lives. Cadence is what makes Compute compound. Without Cadence, your 20 agents produce 20 streams of output you can't keep up with. With Cadence, those 20 streams converge into briefs that get sharper every rotation.

What stays out of Compute

The most important thing the captain doesn't outsource is reasoning.

What people like Sam Altman seem to be selling, wait for AGI, then ask the AI what to do, is a trap. If I just dream of automating everything, I have zero moat, zero defendable skill, zero defendable unique value as an operator. The captain's edge is having an opinion. Compute can do a lot, but it can't have an opinion.

Compute does not make:

• Executive decisions (pricing, strategy, hiring)
• One-way-door decisions (irreversible commitments, per Bezos)
• Customer-facing judgment calls (the "should we even reply to this" decisions)
• Anything that requires understanding what makes your business different from the next one

Compute does make:

• Two-way-door decisions (reversible, content drafts, research summaries, draft replies)
• Repeatable execution under clear rules
• Scheduled work where the brief is already specified
• Fast pattern-matching across large data

Beginner's 80/20 starter kit

If you're starting from scratch with no compute layer, here's what I'd build first:

1. Claude Code on your local machine. The $20/month Pro subscription handles most operator work.
2. One Cloudflare Worker for always-on. Build the smallest one, a webhook receiver, a scheduled cron, a tiny API. Get familiar with `wrangler deploy`.
3. One MCP wired to your most-used tool. Linear, Granola, Google Calendar, whichever costs you the most context-switching.
4. One scheduled AI job. Pick something boring and recurring. Have Claude do it nightly. Watch it work for a week. Adjust.

That's it. Four pieces. You'll outgrow them inside three months, but you'll know which directions to grow because you'll have run real cadences. Premature optimization is worse than no optimization.

When Compute breaks

Mine has broken in mostly predictable ways:

• Local Claude jobs failing during travel (fixed by moving to OpenClaw API on a VPS).
• An MCP version-bumping and silently changing behavior (fixed by pinning versions).
• An agent recursively calling itself due to a bad rule (fixed in CLAUDE.md, not in the agent).
• A Cloudflare Worker hitting CPU limits because I wasn't watching the metrics (fixed by splitting work across multiple Workers).

Notice: most of those fixes happened in Command or Cadence, not in Compute. The compute layer breaking is usually a downstream symptom of a Command articulation gap or a Cadence cadence problem. Fix upstream.

What changed since I wrote this (updated August 2026)

What held up

The decision tree survived intact, and I still run it verbatim. So did the deletion test, and so did the core claim that compute is disposable while Command is not. Moving scheduled AI work off my laptop because travel kept breaking it turned out to be the right call for a reason I only half understood at the time, which the first lesson below covers.

1. Compute got a scheduler and a brain

In May this layer was a pile of independent jobs: some cron, some agents, some services, each doing its own thing and reporting nowhere. It now has a spine. A single daily loop reads every signal, reasons over it, and stacks drafted work behind one approval gate, which I wrote up separately in the executive deck piece.

The structural lesson is small and useful: a dozen scheduled jobs with no shared output is not a system, it is a to-do list that runs itself. The moment they wrote into one place with a common shape, the whole layer became something I could reason about instead of maintain.

2. Never put the always-on thing on something that can die with a bill

The most useful architectural decision of the last few months was choosing where the loop lives. It could have moved to a rented virtual server with more freedom and a nicer runtime. It stayed on edge functions instead, for one blunt reason: an always-on system should not be able to stop because a subscription lapsed or a card expired.

Scale-to-zero and a flat low bill are nice. Not being able to quietly die is the actual feature. Heavier or stateful jobs still live on a server, and that server is explicitly allowed to be non-critical.

3. Secrets moved out of environment variables

The original advice, keep keys out of the repo, is necessary and not sufficient. Once several agents and services need the same credentials, plain environment variables become a place where nobody knows what is set, what is stale, or who last touched it.

They now live in a managed secrets store and reach the running code through bindings. The browser layer receives configuration and health information and never a stored value. Credential replacement is write-only: you can install a new one, you cannot read the old one back out. The gain is not secrecy in the dramatic sense, it is that rotation and auditing stop depending on memory.

4. Pin the account you are deploying into

A small operational scar worth passing on. Once your credentials can see more than one account, deployment tools cannot always work out which one you mean, and in an automated context they cannot stop to ask. The failure is confusing rather than loud: a deploy goes somewhere unexpected, or fails with an error that does not mention the real cause.

Name the target account explicitly in the config of every project, even when you only have one today. It costs one line and removes an entire category of "why did that not go live" afternoons.

5. An open pull request is not a deployed state

This one cost me the most and is the most embarrassing, so it is the most worth writing down.

A change to our homepage lived on a branch. The branch was never merged. Every subsequent deploy from the deploy branch quite correctly shipped a homepage without it, which looked like a recurring bug that kept undoing my work rather than what it was: a merge that never happened. I lost real time treating a process failure as a technical one.

6. The hierarchy of trust needed teeth

The four tiers above are still how I think about delegation. What I got wrong was believing they could live as a written policy. A model reads instructions and then reasons under pressure to finish the task, and reasoning can walk around a paragraph.

The tiers are now enforced by hooks that intercept commands before they run: the genuinely dangerous ones are blocked by the harness rather than declined by the model. I have expanded on that in the captain and agents piece, because it turned out to be a governance lesson more than an infrastructure one.