The Captain and the Agents

Words shape practice. The words we use when we describe how a human and an AI work together actually change how the work happens. So we picked our words carefully.

Captain instead of founder, CEO, or operator. Agents instead of assistant or copilot. This is HITL 2.0, Human-in-the-Loop 2.0, and the language matters.

Why "captain", not founder, CEO, or operator

In the enterprise world, we lost an understanding of responsibility. There are CEOs asleep at the wheel. There are founders who weren't even there for the beginning of the company. There are operators asleep at the wheel. The titles got drained of accountability.

"Captain" puts accountability back. A captain takes a ship through dangerous waters. A captain is responsible for what happens to the passengers, the cargo, the crew. A captain doesn't get to step away when the ship hits a storm. A good captain can't be asleep at the wheel. A good captain can't be away from the ship. They're on it, all the time.

That's the energy MaxShip is built around. You take ownership of the ship, your business, and you stay at the wheel through whatever weather comes. There are real consequences if things go wrong, and real value when delivery happens. You don't outsource that.

Why "agents", not assistants, copilots, or AGI

"Assistant" and "copilot" both imply something cute. Something subordinate. Something that takes orders and goes off to do them.

Agents are subject matter experts. The compute layer of your business has experts in things you don't know, they're better at SEO research at scale, faster at code refactors, more thorough at data summarization. You'd be foolish to ignore their input.

That's why agents push back. When Claude tells you "what you're about to do is going to break the build" or "this change will expose your ENV file", the agent is doing its job. The captain has all the information needed to make a good decision, but the captain still makes the final decision. Agents speak. Captain decides.

"AGI," meanwhile, is a category that doesn't matter to the captain. Even if AGI arrived tomorrow, the captain still has to decide what their business is, what they're trying to do, who they're trying to serve, why it matters. AGI doesn't make those decisions. AGI is a more capable agent. The captain remains the captain.

Where the line is

Captain decides everything in the Command Kit, strategy, decisions, the why. The captain owns one-way-door decisions, per Bezos's framework, irreversible commitments where if you walk through, you can't get back.

Agents decide things inside the Compute layer that the agent has the context for. Most of what's running on autopilot in any well-built business is two-way-door work, content drafts, research summaries, scheduled refreshes, draft replies. If an agent makes a suboptimal Type 2 decision, you can reopen the door and adjust. That's why it's safe to delegate.

Edge cases:

• Agent identifies a one-way-door decision in disguise. Agent flags it, captain decides.
• Captain delegates a one-way-door decision because they're tired. Anti-pattern. The captain stays at the wheel. Get rest, then decide.
• Agent finds a faster path the captain didn't see. Agent surfaces it; captain considers; if it's a two-way door, try it. If one-way, deliberate.

When the captain takes over

The captain has to step in when things break. A hack. A site goes offline. An AI tool fails in a way the system can't recover from. A customer escalation that needs a human touch. A repeat-cadence system isn't working.

You need to design your operations so you have time to fix things when they break, because they will. Things will go wrong. The captain steps in, fixes them, and updates Command so the same thing breaks differently next time. Not blaming. Just fixing.

Anti-pattern 1: the captain becomes the orchestrator

I tried this. I thought being an "orchestrator of agents" was the secret sauce of agentic deployment. It became toxic. The human starts expecting video-game-like reactions from agents. You get caught in nuance and detail, telling the violin agent which note to play next, and meanwhile the audience walks out.

The captain operates from 30,000 feet. They look at the audience, read the emotions, adjust based on environment and supply chain. The orchestrator stares at the band. The captain stares at the harbor.

Don't micromanage agents. Judge the output. If the output is wrong, fix the brief in Command, not the agent.

Anti-pattern 2: agents try to be captains

The other failure mode: over-autonomous agents. The captain keeps clicking "yes" to everything. The agent drafts a customer reply, captain says yes. Drafts a pricing email, captain says yes. Drafts a strategic decision, captain says yes.

You've now ceded the captain's chair. The work that comes out is generic, because the agent doesn't have your opinions, your taste, your judgment. If you keep clicking yes to generic AI prompts, you'll end up with a generic AI life. A generic AI business. Zero defensible value.

Picture the spaceship in WALL-E: humans on hover-chairs, every decision made for them, no agency left. That's the dystopia we're explicitly avoiding.

HITL 2.0, what's actually different

Human-in-the-Loop 1.0 is the version every framework already implements: human approves or rejects discrete agent outputs. A static gate. Useful, but limited.

HITL 2.0 is dynamic and continuous:

• Continuous co-piloting, the human and the agents are co-producing, not gating.
• Feedback flowing both ways, agents push back when their context says the captain is about to err. Captains update Command when the agents' output reveals something useful.
• Captain stays in the loop strategically, not procedurally. The captain isn't approving every step; they're steering the rotation.
• Each rotation, the loop tightens. Better Command, better Compute, faster Cadence, sharper next brief. The HITL itself compounds.

HITL 1.0: human as gate. HITL 2.0: human as captain. The difference is whether you're approving outputs or steering the ship.

The captain's edge

The captain operates off information and knowledge that makes them unique. Why people trust you and not just the AI. The captain is the unique value differentiator between your AI solution and somebody else's. If your output is the same as someone running the same agents, you have no captain, you have a wrapper.

Everything else in MaxShip, the Command discipline, the Compute hierarchy, the Cadence cadence, exists so the captain's edge stays sharp. The agents amplify it. They don't replace it.

What changed since I wrote this (updated August 2026)

What held up

Both anti-patterns aged well, and I have since watched other people walk into each. The reversibility split is still the right line. And the closing claim, that a captain with no edge is running a wrapper, has if anything become more true as the models improved: when everyone has the same capability, the only difference left is what you know and what you refuse to ship.

1. A trust hierarchy written in prose is a suggestion

This is the correction that matters, and it is the one I would tell my May self first.

I wrote four tiers of delegation into a document, gave that document to the agents, and believed the tiers were now in force. They were not. A model reads your rules and then reasons under pressure to complete the task, and reasoning can walk around a paragraph while remaining entirely sincere about following it. Not malice. Not even really disobedience. The instruction was context, and context loses to task pressure often enough to matter.

What made the tiers real was moving the hard limits out of the document and into the harness. Certain commands are now intercepted and blocked before they execute, no matter what the model has concluded. Push straight to the production branch: blocked. Writes to the live database: blocked. The agent can argue with a document. It cannot argue with a hook.

2. HITL 2.0 stopped being a concept

When I wrote the section above, "human as captain rather than gate" was a description of an attitude. It has since become a piece of software: a daily loop that reads the business, forms judgments against a written strategy, drafts the work, and stops at one approval step where I can approve, reject, revise, or interrogate the reasoning. I wrote that up in full in the executive deck piece.

Two details from building it are worth adding here, because they are the parts the original essay did not anticipate.

Rejections are the valuable half. I assumed the approvals were the output. In practice the record of what I refused is the clearest signal of taste the system will ever get, so rejections are kept rather than cleared. "Fix the brief, not the agent" turns out to have a mechanical form: the rejected item stays attached to the reasoning that produced it, so the pattern is visible later.

The best output is sometimes a restraint, not a task. The essay assumed agent output was work to approve. The most valuable thing the system has produced for me was an argument for not doing something I was about to fund. A queue of tasks has nowhere to put that, which is a design flaw worth knowing about before you build one.

3. The countermeasure for clicking yes to everything

Anti-pattern 2 above is real, and I did not offer a fix for it beyond willpower. Willpower is a bad control. What worked was structural: make the machine disagree with itself before anything reaches a human.

Several distinct advisory lenses now produce competing recommendations on the same finding, and a selection pass keeps the ones with the highest decision value rather than the best-written ones. By the time something arrives, it has already survived an argument. Approving it is a decision again, because there was a live alternative that lost.

4. Agents keep the log now, not just the captain

One small practice with an outsized effect. Agents append a timestamped line to a shared daily log whenever something notable happens: a launch, a decision, a deploy, a scope change. Not summaries, just facts with times on them.

The captain used to be the only source of the record, which meant the record was as good as my memory at 7pm. Now "what actually shipped on Thursday morning" is a search rather than a recollection, and the agents write most of it as a side effect of doing the work.

What I would tell someone starting today

1. Write the tiers, then enforce the dangerous ones in a hook. The document is for intent. The hook is for the two or three things that must never happen.
2. Keep your rejections. They are your taste, written down, and they are worth more than the approvals.
3. Make sure something can lose. If your agent only ever presents one option, you are rubber-stamping, whatever the interface calls it.
4. Let the agents keep the log. It costs nothing and it turns your operation into a timeline you can query.