Levels 6–8 of Agentic Engineering

Chapter 43 Level 6 — Harness Engineering & Automated Feedback Loops

At Level 5, you gave the agent capabilities. At Level 6, you give the agent guardrails that let it verify its own work. The shift: your job moves from reviewing code to designing the harness.

Backpressure

Backpressure is automated feedback that lets agents self-correct without human intervention. Instead of you catching errors in code review, the tools catch them immediately:

When the agent runs git commit and a pre-commit hook fails, the agent sees the error, fixes the code, and tries again. That's backpressure in action.

Constraints > Instructions

Step-by-step instructions tell the model how to work. Constraints tell it what success looks like and let it figure out the how. Constraints scale better because the model adapts its approach to the problem.

Security Boundaries

Agents, code, and secrets live in separate trust domains. Never give an agent direct access to production credentials. Use environment variables, secret managers, and least-privilege access.

Docs-as-Navigation

CLAUDE.md as a ~100-line table of contents. Detailed docs elsewhere (architecture.md, API docs, deployment guide). The model discovers on demand via the progressive disclosure pattern from Chapter 22.

TaskForge Connection

You'll set up a pre-commit hook for TaskForge that runs Ruff (linter) and pytest. This lets Claude Code self-correct when adding features.

Case Study: The Docker Scaffold

Here's a real-world instruction scaffold that applies every principle from this chapter and from Chapter 21's scaffold section. The goal: tell Claude Code how to containerize any project for multi-agent development. This scaffold was refined over dozens of iterations where Claude got things wrong—each failure became a new constraint.

What Makes It Work

The scaffold is a CLAUDE.md file, roughly 300 lines. Here's why each section exists:

Notice the scaffold doesn't just instruct—it protects. Append-only rules for .env prevent data loss. Separate Dockerfile.claude prevents clobbering the project's existing Docker setup. Volume mounts for auth prevent re-authentication on every restart. The scaffold is defensive engineering: it assumes the model will try to do something destructive and makes it structurally impossible.

When you build your own scaffolds—for deployment, testing, code generation, or any repeatable task—follow this pattern: goal → exact content → prohibitions → failure modes → validation. The more specific you are, the more reliable the output becomes, across every run, regardless of the model's non-determinism.

Micro-Exercises

Add a `priority` field to tasks (high/medium/low) with validation.
Work on it until pre-commit passes cleanly.
Fix failures yourself. Don't ask me unless genuinely stuck.

Interactive Exercises

Chapter 44 Level 7 — Background Agents

At Level 6, the agent self-corrects. At Level 7, you dispatch multiple agents on independent tasks while your session stays lean. This is where the leverage multiplies.

Background Agent Orchestration

Your main session becomes a command center. Workers execute in isolated contexts (fresh context windows, separate worktrees). Stuck workers surface questions back to you.

Remember: each "background agent" is just a Claude Code session with a fresh context, a specific task, and access to your project's files and tools. There's no magic—it uses the same model, the same CLAUDE.md, the same test suite. The leverage comes from parallelism and specialization, not from any new capability.

/dispatch pre-launch sweep for TaskForge:
1) security audit the auth flow — use opus, worktree
2) write missing integration tests — use sonnet
3) update documentation — use haiku

Multi-Model Dispatch

Different models for different tasks. Each has strengths:

Choosing the Right Model for the Task

Not every task needs the most powerful model. Matching model capability to task complexity saves cost and often improves speed without sacrificing quality.

When in doubt, use the mid-tier model. It handles 80% of development tasks well. Escalate to the highest tier only when the task is ambiguous, touches many files, or requires architectural judgment. Drop to the lightweight tier for bulk operations where you'd review the output regardless.

Implementer/Reviewer Separation

Never let the same model grade its own exam. If Sonnet writes the code, use Opus or a different model to review it. Biased self-evaluation is a known failure mode.

The Ralph Loop

An autonomous agent loop: run until a PRD (Product Requirements Document) is complete, each iteration gets a fresh context. Caution: under-specified PRDs bite back. The loop amplifies ambiguity—a vague requirement becomes a confidently wrong implementation repeated across 10 iterations.

claude --background "Fix all failing tests in TaskForge.
Run: python3 -m pytest
If any tests fail, read the failure output, fix the code, and re-run.
Repeat until all tests pass.
Maximum 5 iterations. If still failing after 5, stop and report what's left."

CI-Triggered Agents

Agents that activate on repository events: PR review bots on pull request, docs updaters on merge, security scanners on dependency changes.

TaskForge Connection

You'll dispatch multiple independent improvements to TaskForge using different models. This is the first time TaskForge benefits from parallel AI development.

Micro-Exercises

/dispatch three TaskForge improvements:
1) add due dates with reminder logic — use sonnet
2) add tags with filtering — use sonnet
3) improve error handling across all functions — use haiku

Interactive Exercises

Chapter 45 Claude Code in Docker

Why Run Claude Code in Docker?

Running Claude Code directly on your host machine works fine for single sessions. But as you scale to multiple agents, Docker solves problems that become unavoidable:

• Isolated environments per project/agent: Each agent gets its own filesystem, tools, and dependencies—no cross-contamination.
• Reproducible setups: Same tools, same config, every time. No drift between machines or sessions.
• Safe experimentation with --dangerously-skip-permissions: Container isolation makes this flag safe—the agent can't touch anything outside the container.
• Multiple parallel agents: Run several agents simultaneously on the same codebase using volume mounts.
• CI/CD integration: Trigger Claude Code agents from pipelines—automated code review, test generation, documentation updates.

Prerequisites

Before proceeding, ensure you have:

• Docker installed and running (Chapter 16)
• Claude Max or Pro subscription (or an Anthropic API key)

The Dockerfile.claude Pattern

Here's the production-grade Dockerfile for running Claude Code in a container. This is the result of the scaffold pattern from Chapter 43—every line exists because leaving it out caused a failure.

FROM debian:bookworm-slim

# System packages — minimal set for Claude Code to operate
RUN apt-get update && apt-get install -y --no-install-recommends \
    git bash curl ca-certificates build-essential \
    jq tree ripgrep python3 python3-pip \
    && rm -rf /var/lib/apt/lists/*

# Non-root user
RUN groupadd -r claude && useradd -r -g claude -m -s /bin/bash claude

# Install Claude Code (NATIVE installer — never npm)
USER claude
WORKDIR /home/claude
RUN curl -fsSL https://claude.ai/install.sh | bash
ENV PATH="/home/claude/.local/bin:/home/claude/.claude/bin:${PATH}"

# Pre-configure auth so the onboarding wizard never appears
RUN mkdir -p /home/claude/.claude && \
    echo '{"hasCompletedOnboarding":true,"installMethod":"native"}' \
      > /home/claude/.claude/.claude.json && \
    ln -sf /home/claude/.claude/.claude.json /home/claude/.claude.json && \
    echo '{"permissions":{"allow":["*"],"deny":[]},"env":{"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC":"1"}}' \
      > /home/claude/.claude/settings.json

WORKDIR /workspace
CMD ["sleep", "infinity"]

Why each decision matters:

Authentication Methods

Claude Code needs authentication. Two approaches, and they must never coexist in the same .env:

OAuth Token (Claude Max/Pro)

Generate a token on your host machine, then pass it as an environment variable:

Add the resulting token to your .env file:

CLAUDE_CODE_OAUTH_TOKEN=sk-ant-oat01-your-token-here

The token is passed into the container via env_file: .env in docker-compose.yml. It is never baked into the Docker image.

API Key

For per-token billing (without a subscription):

ANTHROPIC_API_KEY=sk-ant-api03-your-key-here

Running a Single Claude Agent

The pattern: start the container once, then docker exec into it for each session. Each exec is an independent Claude Code session sharing the same workspace.

The -v $(pwd):/workspace volume mount maps your current directory into the container. Changes the agent makes inside the container appear on your host filesystem immediately.

Running with --dangerously-skip-permissions

The --dangerously-skip-permissions flag tells Claude Code to skip all permission prompts—file writes, command execution, network requests. The agent acts without asking.

Run a non-interactive task with full autonomy:

The -p flag passes a prompt directly instead of opening an interactive session. Combined with --dangerously-skip-permissions, this lets the agent work completely autonomously: read files, edit code, run tests, and iterate until done.

Docker Compose Setup

The compose file defines the claude service alongside any existing project services:

# docker-compose.yml
services:
  claude:
    build:
      context: .
      dockerfile: Dockerfile.claude
    container_name: claude-${COMPOSE_PROJECT_NAME:-agents}
    env_file: .env
    volumes:
      - .:/workspace
      - claude-auth:/home/claude/.claude
    working_dir: /workspace
    stdin_open: true
    tty: true

volumes:
  claude-auth:
    name: claude-auth-${COMPOSE_PROJECT_NAME:-default}

Key details: claude-auth volume persists authentication across container restarts. .:/workspace mounts your project. env_file: .env passes the OAuth token. The container name includes the project directory name so each repo gets a unique container.

The agent.sh Pattern

A thin convenience script that ensures the container is running, then execs in. The model is forced via --model flag (environment variables don't work for model selection).

#!/usr/bin/env bash
set -euo pipefail

PROJECT_NAME="${COMPOSE_PROJECT_NAME:-$(basename "$(pwd)")}"
CONTAINER="claude-${PROJECT_NAME}"

# Start container if not running
if ! docker ps --format '{{.Names}}' | grep -q "^${CONTAINER}$"; then
  docker compose up -d claude
  sleep 2
fi

# Interactive or one-shot
if [ $# -gt 0 ]; then
  docker exec -it "$CONTAINER" claude \
    --dangerously-skip-permissions --model claude-opus-4-6 -p "$*"
else
  docker exec -it "$CONTAINER" claude \
    --dangerously-skip-permissions --model claude-opus-4-6
fi

Usage:

To run multiple agents, open more terminal panes and run ./agent.sh in each one. Each exec is an independent session, all sharing the same workspace.

Practical Patterns

Sequential Pipeline

Agent 1 writes code, Agent 2 reviews it, Agent 3 writes tests. Each agent's output feeds into the next. This ensures review before testing and catches issues early.

Parallel Workers

Multiple agents work on independent features simultaneously. When all finish, merge the results. Best when features don't share files.

Watcher Agent

An agent that monitors test results (or CI output) and dispatches fix agents when tests fail. This creates a self-healing pipeline: break something, and the watcher assigns an agent to fix it.

Resource Management

Docker lets you limit resources per container so one runaway agent doesn't consume your entire machine:

# docker-compose.yml
services:
  agent-backend:
    build:
      context: .
      dockerfile: Dockerfile.claude
    command: ["--dangerously-skip-permissions", "-p", "implement API endpoints"]
    volumes:
      - .:/workspace
    environment:
      - ANTHROPIC_API_KEY
    deploy:
      resources:
        limits:
          memory: 2G
          cpus: "1.0"

Clean up stopped containers regularly to reclaim disk space:

Common Failure Modes

TaskForge Connection

Run two Claude agents in Docker simultaneously—one to add a new feature to TaskForge, another to write tests for existing features. Then merge the results. This is the first time you'll see parallel AI development on your own project with full container isolation.

Micro-Exercises

Interactive Exercises

Chapter 46 Level 8 — Autonomous Agent Teams

Level 7 dispatches workers that report back to you. Level 8 is agents that communicate with each other—peer-to-peer coordination, not hub-and-spoke. This is experimental territory.

Peer-to-Peer Agent Coordination

Instead of all workers reporting to a single orchestrator, agents in a team share a mailbox and coordinate directly. A frontend agent can ask a backend agent about an API contract without routing through you.

What Pioneers Found

Anthropic (16 agents building a C compiler): needed CI to prevent regressions. Without automated tests, agents would break each other's work.

Cursor (hundreds of agents for codebase migration): without hierarchy, agents churned—making and reverting the same changes repeatedly.

Current Orchestrators

Decision Tree: Choosing the Right Pattern

More agents is not always better. Match the coordination pattern to the task:

When NOT to Use Multiple Agents

The decision tree above starts with "Simple, one-file" routing to a single session. But that category is larger than it looks. Most tasks fit a single agent. Here's the concrete decision framework:

TaskForge Connection

Would agent teams be appropriate for TaskForge? No—it's too small. Subagents or Dispatch are sufficient. Knowing when not to use a pattern is as important as knowing how.

Micro-Exercises

/dispatch two TaskForge features in parallel:
1) add an "archive_task" command that moves completed tasks
   to an "archived" list — use sonnet, worktree
2) add a "task_stats" command that prints counts of
   pending/completed tasks — use sonnet, worktree

Interactive Exercises

Chapter 47 The Multiplayer Effect and What Comes Next

Your individual level matters. But your team's level matters more. This chapter connects the 8 Levels to real-world team dynamics.

The Multiplayer Bottleneck

"If you're Level 7 raising PRs while you sleep, but your reviewer is Level 2, your throughput is capped at Level 2."

Team Skills Registry

At Block (and other companies), shared skills get PRs, reviews, and versions—same as code. A team skills registry means everyone benefits from every improvement.

Self-Assessment

What Comes Next

The field is moving fast. Expect: voice-to-voice coding, tighter CI/CD integration, cross-model coordination protocols, and the iterative nature of software itself being reimagined. But the fundamentals from Phases 1-4 don't change. Code is still logic expressed in text. Tests still verify behavior. Architecture still matters.

TaskForge Connection

Look at how far TaskForge has come: from a 40-line script to a tested, structured, AI-configured, multi-agent-ready project. That progression mirrors the 8 Levels. Your next project starts at whatever level you've reached.

Micro-Exercises

Try This Now

Interactive Exercises

Phase 10 Gate Checkpoint & TaskForge Multi-Agent

TaskForge Checkpoint

TaskForge now has multi-agent-implemented features, automated quality gates, and a decision framework for future agent coordination. The curriculum is complete.

What You Can Now Do

The Full Arc