Three-Tier Setup

Complete Cross the Diff-vs-Code Threshold first; this lesson builds on calibrated trust so you can assign human/supervisor/worker roles with the right confidence levels.

Here is the before and after: You need to add input validation to 12 API endpoints. You could prompt an agent 12 times. Or you could write one supervisor prompt, dispatch it once, and come back to a summary table. The difference is the three-tier architecture.

Three tiers: you (human) set the goal and approve the final output. A supervisor agent coordinates the work, enforces quality, and decides what to surface. Worker agents each handle one task with no awareness of the larger system.

The middle tier is what makes this work. Without a supervisor, you become the coordinator. You track which agent is on which branch, review every intermediate result, and manually dispatch retries. That is more work than doing it yourself. The supervisor absorbs all of that. It creates the worker tasks, dispatches them in parallel, reads each result, runs the checks, and reports back with a summary.

The supervisor prompt is the critical artifact. It defines: what workers are allowed to do, what quality criteria a worker result must meet before it is accepted, how to handle worker failure, and how to report back. Most teams underestimate this. A vague supervisor produces vague outputs at 12x the cost.

Tier separation also maps to blast radius. Workers never touch external APIs or production state without supervisor approval. The supervisor never pushes to production without your approval. The hierarchy is not bureaucracy. It is a safety boundary.

Paste this into Claude:

I want to set up a three-tier architecture for a multi-step task. Here is a task that has multiple parallel subtasks: [describe a task with at least 4-6 parallel components, e.g. 'add input validation to 6 API endpoints', 'update the docs for 8 public functions', 'add error handling to 5 service files']. Help me: (1) Write a supervisor prompt that specifies the goal, the quality criteria each worker result must meet, how to handle worker failure, and how to summarize results. (2) Define what each worker receives as its task prompt. (3) Describe how the supervisor reads and evaluates each worker output. Do not run the workers yet. Just set up the architecture.

What good looks like:

• You wrote a supervisor prompt with explicit quality criteria, failure handling, and a reporting format
• Each worker task is fully specified and isolated from the others (no shared mutable state)
• The supervisor criteria are binary and checkable, not subjective
• You can describe what happens when one worker fails and the others succeed
• The architecture separates concerns: workers execute, supervisor evaluates, human approves

Paste this into Claude:

Now run your three-tier setup on the task you designed. Dispatch the supervisor. Let it coordinate the workers. When it reports back, review only the supervisor's summary, not the individual worker outputs. Check: (1) Did the supervisor's quality gate catch anything a worker got wrong? (2) Was the summary enough to decide whether to approve the batch? (3) What would you change in the supervisor prompt for the next run?

What good looks like:

• You reviewed the supervisor summary without reading every individual worker output
• The supervisor's quality gate caught at least one worker result that needed revision
• You made at least one specific change to the supervisor prompt based on the run
• Your total active time (not agent run time) was less than doing the tasks manually