Tier 6

Tier 6 — Supervise: Put agents into production, so they work without you

Reach for this tier when runs die because your laptop slept, or every run still waits for you to start it — and the team needs agents to pick up tickets and open PRs without anyone babysitting a terminal. Get this right and a run survives your laptop closing and keeps going while you're away.

Once runs go longer than you'll sit and watch, where they run and who starts them becomes its own engineering problem. Two steps take you from your box to the team's system:

Your box — runs that survive you leaving

6.1 Host long runs on a box that doesn't sleep; persist with tmux.

Instead of: a run that dies the moment your laptop sleeps or wifi drops.

Prefer: run on a small always-on server and wrap each agent in tmux.

How:

tmux new -s claude-auth        # one named session per task
claude                          # run the agent inside it
# detach: Ctrl+b then d   → the session keeps running on the server
tmux attach -t claude-auth     # reattach later, from any device

Why this works: Claude Code is API-bound, not compute-bound — inference runs on Anthropic's servers; your machine just holds the thread. A box that doesn't sleep keeps the agent moving. A 4 GB VPS handles one agent; budget 16 GB+ for dynamic workflows or many parallel subagents (heavy orchestration OOM-kills small boxes, and that takes the tmux session with it). Caveat: tmux survives disconnects, not crashes or reboots.

6.2 Drive the fleet from your phone — clear blockers from anywhere.

Instead of: being chained to a desk to answer one permission prompt.

Prefer: SSH in from a mobile client and clear decision points from anywhere.

How: Tailscale for a private network, Termius/Blink as the SSH client, tmux attach to look in on a run and unblock it.

For unattended runs, give an explicit stopping condition ("work until the tests pass, then stop and notify") so it doesn't loop, and consider a Telegram/notification bridge.

(Claude Code's built-in Remote Control still runs on your local machine — the server + tmux setup is the only true close-the-laptop persistence.)

6.3 Secure the agent server like production.

Instead of: root login and API keys in a committed file on an internet-facing box.

Prefer: non-root sudo user, SSH-keys-only, firewall, secrets in env / a secrets manager.

How: disable password and root SSH login, UFW-allow only SSH, keep ANTHROPIC_API_KEY in the environment (never committed).

If you run unattended with --dangerously-skip-permissions, put it behind a PreToolUse guard hook that blocks destructive commands — that's the layer the model can't talk its way past.

Next level up is the managed version of all this: Warp's Oz and Claude Code's dynamic workflows run agents in the cloud on schedules/triggers with central tracking — the same fleet ideas, hosted.

The execution layer — the team's system

While running a local loop is perfect for individual spec-driven development, enterprise agentic loops require a dedicated Agent Execution Layer. It's the layer beyond your own server (the box above): loops run hosted, isolated, and event-triggered.

Less new than it looks — it's the same loop you already built. Everything from Tier 3 (act → test → fix against a Definition of Done, commit every green step) and Tier 4 (gh, CI) is unchanged.

The execution layer only answers three new questions: where does it run, what triggers it, and how do many agents avoid colliding?

You adopt it gradually — start fully managed, self-host only when you need the control.

Start here — a real execution layer with zero infra

You don't build anything to begin. The managed on-ramps give you a production loop on Monday:

• GitHub. Run /install-github-app, then @claude in any issue or PR to implement or fix; switch on automatic Code Review to get a review on every PR. On Agent HQ you can assign Claude (or Codex/Copilot) to an issue and get a draft PR back — reviewed like a teammate's, no new dashboard to learn.
• Linear. Assign an issue to the Linear agent and it runs a cloud coding session (powered by Claude Code/Codex), grounded in the ticket, history, and linked context, and returns a diff for review. Linear uses it on its own incoming bug reports, landing the correct fix roughly a third of the time on failing background tasks alone. Want your own harness instead? Cyrus (open-source) makes Claude Code an assignable Linear agent via Linear's Agent API.
• Anthropic-managed. Claude Code on the web runs sessions in isolated cloud VMs; Routines run scheduled jobs on Anthropic's infra with no local machine.

Wire one trigger, keep a human approval gate, and you have an execution layer. That's the whole "try it" step.

The stack — what it's made of when you build your own

When you outgrow managed (control, data residency, custom tools), the layer has four parts:

A trick worth stealing: make the tracker the agent's memory. The conversation is disposable; the Linear/GitHub workflow state (Todo → In Progress → In Review) is the durable state machine the loop reads on every event.

The loop — from ticket to merged PR

This is just Tier 3's loop, hosted and gated:

flowchart TD
  Tk[Ticket → Agent Todo] --> Pl[Plan: spec sub-agent]
  Pl --> G1{Human approves spec?}
  G1 -->|yes| Ex[Isolated execution<br/>sandbox + own worktree]
  Ex --> Loop[Build & test loop<br/>until green · capped ~3–5 strikes]
  Loop --> PR[Commit & open PR via gh]
  PR --> Rev[Review agent posts findings]
  Rev --> Fix[Execution agent fixes]
  Fix --> G2{Human merges}

1. Trigger & context. A human moves a ticket to "Agent Todo"; a webhook fires. The agent reads the ticket (MCP) and pulls only the relevant files (code intelligence) — not the whole repo.
2. Plan (spec sub-agent). A planning subagent drafts a short spec and posts it back to the ticket; the loop pauses for a human "Approve." Keep this gate.
3. Isolated execution. The execution agent spins up a sandbox, clones, and works in its own git worktree/branch — so ten agents on ten tickets never touch each other's files.
4. Build & test loop. It writes code and runs the suite in the sandbox. On failure the orchestrator feeds the raw error back; it loops until green, capped at ~3–5 strikes so a stuck agent can't burn tokens forever. (Your Definition of Done is the exit condition — and the cap is the give-up condition.)
5. PR. It commits and opens a PR via gh, under your identity so git blame stays useful.
6. Review agent. A separate review agent triggers on the PR (below), posts findings, and the execution agent fixes them before a human looks.

The review-agent pattern (most teams' first loop)

PR review is where to start: high value, low risk. The pattern:

• Feed the diff, not the codebase. Pull only the changed lines + surrounding functions. Dumping the whole repo destroys the reviewer's context.
• Load the rulebook. Inject your ARCHITECTURE.md or a code-review Skill ("always use the repository pattern for DB access") so it reviews against your standards.
• Prompt adversarially. "Identify side effects this diff introduces that are not covered by the modified tests." (And per Tip 3.6: ask for all findings, severity-labeled — never tell it to be conservative.)
• Use a different model than the author. A cross-lab reviewer catches blind spots a self-review shares — see multi-model use.

Instead / Prefer — the decisions that matter

6.4 Sandbox the loop; never run autonomous agents on a dev box or prod.

Instead of: an unattended agent with write access on your laptop or a shared CI runner.

Prefer: an ephemeral sandbox (E2B/Modal/Daytona/Northflank, or Claude Code's web VMs) — a runaway loop burns a throwaway container, not your environment.

6.5 Gate the plan, not every keystroke.

Instead of: full autopilot from ticket to merge, or approving every edit.

Prefer: auto-run the loop but pause for human approval at the spec and before merge. Gate the irreversible; automate the rest.

6.6 Cap the strikes — a stuck agent shouldn't burn tokens forever.

Instead of: "loop until the tests pass," unbounded.

Prefer: "loop until green, max 5 attempts, then stop and summarize what's blocking." An exit condition needs a give-up condition too.

6.7 Make the tracker the state machine — the agent forgets; the board remembers.

Instead of: holding workflow state in the agent's conversation (it gets archived/compacted away).

Prefer: store state as ticket status/labels (Todo → Planning → Approved → In Review). It survives restarts, and a human can override by moving the card.

6.8 Certify the evidence instead of reading the diff — review the proof, not every line.

Instead of: reading every line of every PR the agents open, until your review is the bottleneck the agents were meant to remove.

Prefer: have every run attach its evidence — test and e2e output, a screenshot of the changed UI, coverage of the changed lines, the mutation score, the review agent's findings — and certify that: does it cover the change, and does it prove what the ticket asked for? Open the code only where the evidence is thin.

This is the Big Idea at full scale: confidence comes from the gauntlet the output survives, not from reading it. Each piece of evidence is a tip you already use — 3.5, 3.10, 3.11, the review agent above — now read by you at the merge gate (6.5). Put the time you no longer spend on diffs into the system: add the missing check, fix the flaky gate, turn a repeated correction into a rule (4.4).

The reality check

Most pilots die before production. IDC found 88% of AI proof-of-concepts never reach wide deployment; Gartner predicts over 40% of agentic AI projects will be canceled by end of 2027 — costs, unclear value, inadequate risk controls. In practice, for a coding agent, that means the boring parts: isolation, governance, least-privilege permissions, audit, data residency.

So treat the execution layer like any production system: scope tools per agent (Tier 5), keep secrets in a manager not prompts, log everything, and use BYOC/on-prem sandboxes if you're regulated.

Start with one managed loop (PR review), prove it, then expand. This is the top of the arc: the agent stops being a chatbot and becomes an asynchronous worker operating inside your org's existing system of record.

That's the point of the whole climb. When the inner two loops run themselves — the agent closes the coding loop (red → green) and you shape the feature loop around it (specify → verify) — your attention is freed for the loop no agent can close for you: the impact loop. What's worth building (opportunities), which bet to make (hypothesis), and whether shipping it actually helped (impact). The tiers automate the how; they hand you back time for the what and the why.