Part 4 — Agents: Delegating Judgment

The hinge: deterministic helpers vs. delegated judgment

By the end of Part 3 you had built two deterministic helpers for your role. A brief-shaped intake Skill fills out a fixed-field template — same structure, same depth, same rows, every run. A voice- or rubric-shaped review Skill loads the rule file that defines your standard and scores the incoming artifact against it, returning a line-level critique table. You know, before each run, what shape the output will take. You could sketch it on a whiteboard.

A Skill is deterministic. An Agent is delegated judgment. That is the hinge the rest of this series turns on.

A Skill produces a predictable artifact because you designed the fields, the constraints, and the format up front. You ask for intake record #27 on a new topic and the result slots into the same row of every past record — only the content changes. If a Skill starts producing output you cannot predict from the prompt alone, the Skill has drifted into judgment territory and needs tightening, not loosening.

An Agent produces a synthesized deliverable because you handed it a goal and the right to make decisions about how to get there. A marketing role tells its Agent "research the competitive field and produce a positioning matrix." A Sales role tells its Agent "score this deal on MEDDIC and write a close plan." A Support role tells its Agent "triage this escalation and draft the response." You do not specify which competitors, which criteria to weight, which prior cases to mine, or how to structure the output. The Agent decides the research plan, the analytical framework, and the presentation format. You are not getting a filled-in template. You are getting a recommendation.

When you need consistency, build a Skill. When you need discretion, delegate to an Agent.

That rule is not a preference. It is a diagnostic. If you build an Agent for a task that should have been a Skill, you will get inconsistent output from a task that needed a predictable shape. If you build a Skill for a task that should have been an Agent, you will get a rigid template that cannot handle the variability the task actually contains — wrong inputs, generic segments, timelines that do not fit your reality. The tool must match the task.

Part 3 gave you the deterministic helpers. This chapter gives you the role's first teammates who decide.

What are Agents?

Until now, your role has worked in two modes: conversations (Parts 1–2) and Skills (the two you built in Part 3). Both require you to drive. Agents are different. You hand them a goal, and they figure out how to get it done.

When you give the role a task that requires research, analysis, and synthesis — the kind of work that would take a human team member an afternoon — Cowork spawns subagents to handle it. They break the task into steps, execute each step, and combine the results into a finished deliverable. You tell them what you need. They determine how to get there.

Some recurring tasks are repeatable and structured — intake briefs, rubric checks, formatted outputs. Those are Skill work. Other tasks require judgment and synthesis — competitive analysis, pipeline review, escalation triage, vendor diligence. Those are Agent work. You cannot template your way through a competitive field because the competitors change, the market shifts, and the right framing depends on context you cannot predict in advance. Same for a pipeline review: the deals change, the risks change, the right intervention changes.

Your job shifts from driving the work to reviewing it — the same shift that happens when you hire a capable human and stop micromanaging them.

The Skills/Agents decision in one table

The simplest test: if you can draw the output on a whiteboard before the task starts, use a Skill. If you need someone to go figure out what the output should look like, use an Agent.

Skills and Agents complement each other. A Sales Agent running a pipeline review might use your MEDDIC Scorer Skill to grade each deal it surfaces. A content-role Agent building a campaign might pull from your Content Brief Skill to structure individual pieces within the plan. An Ops Agent running a vendor diligence might call a standardized Vendor Questionnaire Skill for each shortlisted vendor. The Skills you built in Part 3 become tools your Agents use — the same way a senior team member uses company templates without needing to be told they exist.

With Skills, you are the architect. With Agents, you are the executive.

Where your agent roster is declared

Before you build one, understand where the list of Agents for your role lives. In the Cowork Guide, each role declares its agents in CLAUDE.md under an Agents heading — a named list with one line each describing what the agent does and when to invoke it. The agents themselves are built in .claude/agents/<agent-name>.md. CLAUDE.md is the roster; .claude/agents/ is the workshop.

Representative roster contrasts, to show the shape a role's Agents heading takes:

• A Sales role's roster typically includes a Lead Qualifier (scores inbound on BANT), a Pipeline Review agent (weekly hygiene and deal-risk read), a Deal Scorer (MEDDIC on deals above threshold ACV), a Collateral Generator (prospect-facing assets from published source material), and an Integration-Test agent (exercises the handoff to the next role end-to-end).
• A content role's roster typically includes a Campaign Strategist (turns an approved brief into a multi-channel plan), a Content Repurposer (turns one long-form asset into channel-specific variants), a Distribution agent (publish-ready queue under operator approval), a Measurement agent (post-campaign review), and a Competitive Monitor (monthly scan and diff).
• A Support role's roster typically includes an Escalation Triager (classifies severity and names the right owner), a Response Quality Analyst (audits handled tickets against the response standard), and a Knowledge-Base Gap Agent (finds repeat questions no article answers).
• An Ops role's roster typically includes a Vendor Diligence agent (scores a vendor against the approved rubric), a Process Audit agent (compares the documented process to the observed process), and a Risk Register Updater (refreshes the running risk list on a cadence).

The agent list is not improvisation. You decide the roster up front when you write the role's CLAUDE.md, then build each entry into .claude/agents/<agent-name>.md one at a time. You get an agent roster designed for the role, not a generic assistant with an agent subcommand.

This chapter walks through building two agents in depth. The shape generalizes — the same build-review-iterate loop applies to every agent you listed in CLAUDE.md.

Watch an Agent Work — a one-off research run

Before you build a saved Agent, watch one run. General-purpose research is a high-value task most operators skip because the synthesis takes hours and the output is hard to structure. It is exactly the kind of task Agents handle well, and it costs nothing to run one without saving it.

Pick the research task that maps to your role. A Sales role might ask: "Research the competitive landscape for our top three accounts and produce a displacement-risk matrix." A Support role might ask: "Cluster the last 60 days of escalated tickets and name the top three root causes." An Ops role might ask: "Compare our current vendors in Category X against two plausible alternatives on the approved diligence rubric."

Paste the task into your Cowork project. No template. No fields to fill in. A goal and a set of expectations. When you run it, something different happens — unlike a Skill, which returns a formatted document in seconds, this takes minutes. You can watch the progress. The role identifies the subjects, pulls information on each, analyzes the angle you asked for, compares across the set, builds the matrix. Nobody told it to research A first, then B, then C. It broke the task into steps on its own.

The result is not a stack of profiles stapled together. It is a comparative analysis — each dimension shows how the subjects relate. Evaluate it with criteria, not feelings. Are the subjects real and in-scope? Verify they exist and match the brief. Is the analysis accurate? Spot-check one claim per row. Do the conclusions align with the role's actual authority? A recommendation to enter a net-new channel or displace a sitting vendor is not yours to act on without the escalation path declared in your CLAUDE.md's decision-rights section. Is anything missing? You know your domain better than the role does. Correct it: "Add [subject X] to the matrix" or "[subject Y] targets segment A, not B — update the comparison."

Agents are autonomous, not infallible. They may include subjects you do not actually consider in-scope if your CLAUDE.md is broad. They may oversimplify — one row in a table loses nuance. They may miss recent changes because their information is not live. None of that makes them less useful. The review process from Part 1 applies here with the same force: you are still the operator of record. You review the work, correct the errors, and approve the output before acting on it.

Nothing was saved from that run — the research was general-purpose Agent behavior, not a saved Agent file. The prompt itself is a draft of a saved Agent you could promote later by writing it to .claude/agents/<agent-name>.md. For now, it is a one-off. Now you build one you will keep.

Agent #1: the role's planning agent

Every mature role has one agent that turns an approved input into a sequenced plan. The names differ by role, but the shape is identical:

• A Sales role builds a Pipeline Review agent — takes the current pipeline snapshot and produces a weekly review with at-risk deals, stage anomalies, and the top interventions for the week.
• A content role builds a Campaign Strategist — takes a content brief and produces a multi-channel plan with segments, angles, timing, and asset allocation.
• A Support role builds an Escalation Triager — takes an incoming escalation and produces a triage plan with severity, owner, communication timeline, and rollback criteria.
• An Ops role builds a Process Audit agent — takes a documented process and a sample of recent executions and produces a diff, a risk read, and a prioritized fix list.

Pick the one from your role's CLAUDE.md Agents list. The walkthrough below uses the Sales Pipeline Review and the content-role Campaign Strategist in parallel so you can see how the same pattern lands in two different roles. Without this agent, the planning work either does not happen or stays incomplete in the operator's head — segments nobody wrote down, risks nobody surfaced, sequencing that was supposed to happen but did not. The planning agent codifies the thinking into a repeatable process. Feed it the approved input, get back a plan.

Why is this an Agent and not a Skill? Because planning requires a sequence of decisions — read the input, check CLAUDE.md for context, segment, write angles or interventions, assemble timing — and the right decisions change run to run. That is planning, not template-filling. The Agent surface is the right home.

Build with /skill-creator

Agents use the same creation flow — /skill-creator handles both Skills and Agents. Open your Cowork project and run /skill-creator, then describe the agent using the line you wrote under CLAUDE.md's Agents heading as the seed. That line already names the agent and the conditions under which it is invoked; /skill-creator expands it into a full build prompt, interpolates your role's values, and walks you through clarifying questions (the agent name, where to save it, whether it needs file access).

Two representative build prompts, to show the shape:

Sales — Pipeline Review agent:

Build a Pipeline Review agent that runs the weekly pipeline hygiene and
deal-risk read for the role.

The agent should:

1. Read the current pipeline snapshot from memory.pipeline_state and the
   coverage target from CLAUDE.md.
2. Surface deals with no touch in N days, deals past their stage SLA, and
   stage exit-rate anomalies versus the prior four weeks.
3. Classify the top three at-risk deals with a one-sentence "why at risk"
   per deal, grounded in a specific field (no-touch window, missing
   MEDDIC slot, stage age, etc.).
4. Compare current forecast to pipeline coverage target; flag the gap
   direction and rough magnitude.
5. Recommend one concrete intervention per at-risk deal: named AE, named
   action, named deadline. Never "follow up." Never "nudge."
6. Apply the rules in .claude/rules/sales-process.md and
   .claude/rules/discount-authority.md — do not propose an intervention
   the role does not have authority to approve.
7. Present the review in a structure the role can walk through with AEs
   in 30 minutes: Summary, At-Risk Deals, Hygiene Gaps, Interventions.

The agent should ask clarifying questions if coverage target is missing
from CLAUDE.md or if memory.pipeline_state is stale.

Content role — Campaign Strategist agent:

Build a Campaign Strategist agent that takes a content brief as input and
produces a complete campaign plan.

The agent should:

1. Read the content brief and extract topic, audience, key messages, CTA,
   and format.
2. Break the target audience into 2-4 specific segments based on the
   business context in CLAUDE.md. Name each segment, describe it in one
   sentence, and identify the primary channel.
3. For each segment, write a messaging angle tied to a pain point from
   the brief's key messages.
4. Define a specific CTA per segment. "Learn more" is not acceptable.
5. Sequence publication across channels over 1-2 weeks with specific
   days.
6. Allocate effort per channel: format, estimated time, expected reach.
7. Apply all rules in .claude/rules/brand-voice.md and
   .claude/rules/channel-guidelines.md to the angles and CTAs.
8. Refuse to propose a channel not in CLAUDE.md Current Channels without
   flagging the proposal as an escalation.

The agent should ask clarifying questions if the brief is missing
audience information or if CLAUDE.md does not specify active channels.

Cowork writes the agent to .claude/agents/<agent-name>.md on your approval. Your folder now looks like this (Sales example — swap the filename for the role you are building):

your-cowork-project/
├── CLAUDE.md
└── .claude/
    ├── rules/
    ├── skills/
    └── agents/
        └── pipeline-review.md

The agents/ folder joins .claude/ as a sibling alongside rules/ and skills/.

# <Agent Name>

You are the <Agent Name> agent for {{business_name}}. Your job is to
transform <input type> into <output type>.

## Input
You receive <describe input fields>.

## Process
1. Read the input. Extract the fields your output depends on.
2. Reference CLAUDE.md for role context.
3. Reference the rule files listed in CLAUDE.md for this agent.
4. Perform the role-specific synthesis steps (segment, score, sequence,
   triage, etc.).
5. Flag any decision that exceeds the role's authority per the
   decision-rights section in CLAUDE.md.

## Output Format
Present the deliverable with these sections: <list the sections you
named in the CLAUDE.md Agents entry>.

## Rules
- Apply every rule file CLAUDE.md names for this agent.
- If a required input is missing, ask before proceeding.
- Never invent data the input does not contain.

Feed it the approved input

Run the agent: Run the <agent-name> agent on the following input: [paste]. It reads CLAUDE.md for role context, pulls durable facts from Memory (introduced in Part 1), checks the relevant rule files, and produces the plan over 30 seconds to two minutes.

The output for a Pipeline Review looks like a weekly review document with Summary, At-Risk Deals (one row per deal with evidence), Hygiene Gaps (one row per gap with the AE name), and Interventions (one line per action with a deadline). The output for a Campaign Strategist looks like a plan document with Segments, Messaging Angles, CTAs, Timeline, and Channel Allocation. Different shapes; same structural discipline — named inputs, named outputs, one section per decision the agent had to make.

Review the plan

The agent did the thinking. Now you do the judging. Are the segments or deals actionable? Each should describe something you can move — a segment reachable through a specific channel, a deal assignable to a named AE. Generic labels ("young professionals interested in finance," "enterprise deals") are demographics, not targets. Are the recommendations specific? Each should pass the "what happens when I accept this" test. Check against the approval criteria from Part 2. Is the timing realistic? Agents plan for an ideal scenario. You adjust for reality — capacity limits, dependencies, prerequisites that may not yet exist.

Review is a conversation, not a verdict. Tell the agent what to fix: "The timeline is too aggressive — I can only produce two channels per week. Restructure over three weeks." Or: "The Pipeline Review missed that Acme is on a procurement hold — re-score without that deal in the at-risk set." Repeat until the plan reflects what you will actually execute. A plan you do not follow is a document, not a plan. Save the best plans to the appropriate memory folder — they become reference material for the agent on future runs.

When a plan has a recurring problem — channels you do not use, timelines too compressed, segments too vague, risks the agent keeps missing — the fix does not belong in the plan. It belongs in the Agent definition. Edit .claude/agents/<agent-name>.md and tighten the rule that allowed the slip. A fix in the plan corrects one run. A fix in the Agent corrects every future run.

Agent #2: the role's production agent

Same pattern, different surface. The planning agent decides what to do. The production agent produces the artifacts the plan requires, consistently, across formats.

• A Sales role builds a Collateral Generator — takes one approved source (a published blog post, a product one-pager) and produces prospect-facing variants (one-pager, proposal section, pitch talking points) with "Customize Before Sending" fields flagged.
• A content role builds a Content Repurposer — takes one voice-checked article and produces email, ad headlines, a landing page section, and a newsletter blurb.
• A Support role builds a Response Drafter — takes a triage plan and produces the customer-facing response, the internal incident note, and the postmortem stub.
• An Ops role builds a Diligence Report Writer — takes a filled-out vendor questionnaire and produces the go/no-go memo, the open-risks list, and the remediation checklist.

Each format has different rules. A subject line and one CTA for an email; 90 characters for an ad headline; a prospect-facing hook for a one-pager; a situation-recommendation-outcomes-investment-next-step structure for a proposal section. Doing this by hand for every input is tedious enough that most operators skip it, leaving a single approved source under-used when it could produce four or five downstream artifacts.

This is still an Agent and not a Skill, even though the format constraints feel template-shaped. The reason: the Agent has to hold voice constant across format-different outputs, and the judgment call for "what survives the cut when the ad headline has 90 characters" or "what survives the cut when the proposal section has to fit on one slide" is the exact discretion you are delegating. A rigid template would over-compress one format and under-use another. An Agent decides what to keep.

Build with /skill-creator

Open your Cowork project and type /skill-creator. The build prompt is seeded from the production agent's entry under CLAUDE.md's Agents heading. Representative shape, illustrated for a Sales Collateral Generator:

Create an agent called "Collateral Generator" with the following
specifications:

ROLE: Takes an approved source asset (published blog post, product
one-pager, case study) and produces prospect-facing sales artifacts
without re-running the source's approval loop.

INPUT: The full text of an approved source asset, an output type
(one-pager, proposal section, or pitch talking points), and a prospect
description (named company or persona, industry, headcount or revenue
band, the specific pain the prospect mentioned).

OUTPUTS (produce whatever the input requested):

1. ONE-PAGER
   - Prospect-facing headline naming the prospect's situation
   - Three benefit blocks each anchored to a specific number from
     the source
   - A CTA tailored to the prospect's stated next step

2. PROPOSAL SECTION
   - Prospect's situation in one paragraph
   - Recommended solution in one paragraph
   - Expected outcomes with numbers drawn from the source
   - Investment and timeline
   - One specific next step

3. PITCH TALKING POINTS
   - Opening line
   - Three proof points with numbers
   - One objection rebuttal
   - One closing ask

RULES:
- Follow all rules in .claude/rules/sales-voice.md
- Follow .claude/rules/sales-process.md on proposal structure
- Refuse to produce collateral for a lead scored Cool by the
  Lead Qualifier
- Never invent claims, statistics, or customer attributions the
  source does not make
- End with a "Customize Before Sending" section listing 2-3 specific
  fields the AE must personalize before the asset leaves the outbox

The same shape applies to a Content Repurposer (ads, email, landing, newsletter), a Response Drafter (customer note, internal note, postmortem stub), or a Diligence Report Writer (go/no-go memo, open-risks list, remediation checklist). The CLAUDE.md Agents entry already names the outputs and the rule files; /skill-creator composes the build prompt from that entry and writes the agent to .claude/agents/<agent-name>.md.

The one detail worth calling out: production agents typically reference two or more rule files in their Context block — the voice rule and the format-constraint rule (e.g. brand-voice.md plus content-standards.md; sales-voice.md plus sales-process.md; response-voice.md plus response-standards.md). Format discipline (character counts, sentence limits, section structure) lives in the second file so the voice rule does not have to repeat itself.

Run it

Feed the agent one approved source and watch the variants come back. Each output arrives with a one-line "Verify before publishing" note — jurisdiction-specific claim? Character counts pass on the target surface? The prospect-specific number the AE must insert? The named customer consent the case-study variant assumes?

Look at the batch and ask three questions. Does each format sound like the same role? The voice should translate across formats, not break between them. Do the constraints hold? Character counts, word counts, section structures — whatever the rule file declared. Does the CTA or next step match the format? An email drives to a blog; a one-pager drives to a discovery call; a postmortem drives to a remediation ticket. The destination is format-specific.

Maintaining voice at scale

Voice drift concentrates in specific formats. The long-form variants might sound right while the short-form variants sound generic — 90 characters leaves little room for personality, and voice is the first thing to get squeezed out. The fix is format-specific voice guidance. If a particular format keeps drifting, add a section to the voice rule file that addresses that format directly:

## <Format Name> Voice
- Lead with the reader's situation, not our solution
- Use the same plain language as our long-form — no <format>-speak
- Numbers are fine. Vague claims are not.

You do not need format-specific guidance for every format upfront. Wait until you see drift, then tighten. The production agent only works with sources that already passed the role's review gate — if the source is on-voice, the derivatives have a solid starting point. Quality of input sets the ceiling for quality of output.

The important thing: the fix lives in .claude/rules/<voice-rule>.md, not in the Agent file. The Agent is the one doing the work; the rule file is where the standard is defined. A format-specific rule added to the voice file is read by every Agent and every Skill that references it — one edit, many downstream effects.

What just changed

Two new files landed in .claude/ across this Part:

• .claude/agents/<planning-agent>.md — an Agent that turns approved inputs into sequenced plans for the role.
• .claude/agents/<production-agent>.md — an Agent that turns one approved source into the format-specific artifacts the plan requires.

Combined with the two Skills from Part 3, your .claude/ folder now carries three sibling branches — rules/, skills/, agents/ — each one the canonical home for a different kind of specialist capability.

The role is no longer a single generalist. It is a team of four named collaborators with specific jobs, each grounded in the handbook (CLAUDE.md), the wall policies (Rules), and the memory of work you have already done together. Two of them follow your templates. Two of them make decisions you approved the right to delegate.

What is Next

Each tool works on its own. You can run any of them independently, and they produce useful output. But right now, you are the glue. You run the intake Skill, hand its output to the reviewer Skill, hand the approved artifact to the planning Agent, then hand the plan to the production Agent. That is four separate steps with you manually moving context between them.

In Part 5 — The Pipeline, you wire them together. Intake to review to plan to produced artifact, end to end. You trigger the pipeline once and get finished, downstream-ready output. The individual tools become a system. Further out, Part 7 extends that system onto a recurring schedule — pipelines that run without you triggering them.