Part 4 of 6

Part 4 — Helpers Built for Focused Work

Created: April 19, 2026 | Modified: May 3, 2026

By now the workspace has its Instructions, its always-on rules, and its procedures. Part 4 is for the work the others cannot cover: the pieces that do not have a fixed shape. You feed in something — a draft, a stack of source material, a thread that ran long — and what you need back is judgment.

A read on what's working. A pulled-out signal. A tightened version of a thing you already wrote. You can describe what you want done; you cannot describe in advance exactly what the output should look like, because it depends on what's in front of you that day.

What earns the name focused helper is exactly that: a single kind of attention you keep paying by hand, scoped narrow enough that you can describe it in a sentence. Each helper is one such piece of attention, captured as a file the workspace runs when that kind of work shows up.

Three different things called "agent"

Cowork calls this product feature Agents. That word collides with two other things: Claude Code subagents (a CLI feature) and cAgents-plugin agents (a plugin built on top of Claude Code). They are not the same thing. This article is about Cowork Agents, and uses focused helper in the prose to keep the distinction clear. The slug stays agents because that's the Cowork surface name. See Agent for the cross-product disambiguation.

When you finish, your workspace has a small set of focused helpers sitting alongside the files you wrote earlier. Each helper takes on a piece of work you used to do by hand. The Instructions get one new line per helper, appended underneath what was already there.

What that buys you:

Pieces of work you currently do every time, handed off to a helper that has the same context you do.
A workspace that grows by addition, not rewrite — the earlier setup stays exactly as you left it, and new helpers slot in beside it.
One more layer in the Instructions tree: short, scannable, every line tracing back to a choice you made.

How a focused helper differs from a procedure

A procedure produces the same shape every time. You hand it input, it produces a structured output, and your third run looks like your first.

A focused helper takes a different posture. You describe a kind of attention. Read this draft and tell me where the voice is drifting. Look at the last week of these threads and tell me what kept coming up. Take this rough cut and tighten it without changing the meaning.

Take the first one. Run it on a draft where the opening has gone formal mid-paragraph and the helper might come back with two flagged sentences and a single comment about cadence. Run it on a draft where one section quietly lost the contraction count of the rest, and it might come back with a paragraph explaining the shift. Run it on a draft that's clean, and it might flag a single line and stop there. Same helper, three different shapes — each one fitted to what was actually in front of it. The shape is not the point; the attention is.

That's what makes a focused helper a focused helper. You're not handing it a template to fill out. You're handing it a goal and the context you've already given the workspace, and trusting it to come back with something useful for what's actually there. The walkthrough draws the kinds of attention you keep paying out from the way you describe the work — you don't have to come in with a list.

A practical implication. Focused helpers benefit more than procedures from the always-on rules. A helper running quietly without those rules can drift in tone or depth. Wrap it in the always-on rules and it stays in voice.

Helpers drift more than procedures — wrap them in your rules

Procedures produce a structured output regardless of tone. Focused helpers run with more discretion, which means they also drift more — a helper running quietly without your always-on rules can lose voice or depth between Tuesday and Thursday. The always-on rules are the cheapest fix. They cost one ALWAYS-read line and they apply to every helper you ever add.

How to run it

Open the prompts panel and paste the Part 4 prompt. It re-reads the Instructions, asks in one sentence what kind of focused work you'd like a dedicated helper to take on, and walks you through naming each one and choosing where it sits — appending the same ALWAYS read [your-file] for [the kind of attention it pays] line the rest of the Instructions use.

If the Instructions file isn't there or doesn't show the Part 1 shape, the prompt halts and tells you to run Part 1 first.

What happens when you paste the prompt

Same shape as the earlier walkthroughs, scoped to focused-attention work.

The prompt opens by reading what's already there: the Instructions, the slots you named, the files already in the layout. Then it asks, in one sentence, what kind of focused work you'd like a dedicated helper to take on. Plain answers are best. If the sentence is thin, the prompt asks a few short multiple-choice follow-ups — what the input usually looks like, what a useful response would feel like, when you want the helper to ask back instead of guessing.

From your answer, the prompt proposes a list of helpers. Each one is a sentence about the kind of attention it pays — no filenames, no folder names yet. You walk through the list and drop one, rename one, add what's missing, or say it looks right. The list does not move forward until you say it does.

Then placement. The prompt fits each helper into the slots you already named, and asks before adding a new slot.

Then it goes one helper at a time. For each one, you name the file. The prompt drafts three things into the helper's contents: what it pays attention to, what it's allowed to assume from the rest of the workspace, and what it asks back when input is thin. The draft for the voice-drift example might land something like this:

# Voice drift check

## What it pays attention to
- Sentences that have lost the cadence of the surrounding draft.
- Vocabulary that's drifted into a register the rest of the piece doesn't use.

## What it can assume from the workspace
- The voice rules in the always-on file at the root.
- The piece in front of it is a draft, not a finished artifact.

## What it asks back when input is thin
- If fewer than two paragraphs are pasted, ask for the section the draft sits inside.

You read, accept, edit, or ask for a different angle. Nothing lands until you say go.

When all the new helpers are on disk, the prompt shows you the exact new lines it wants to append to the Instructions, one per helper, and you approve them. They land underneath what's already there. The trunk is untouched.

When you're done

The workspace has new helpers at the paths you named, and the Instructions show your original shape with new lines below it. Each helper is a file you can open in a text editor. The way it behaves on your work tomorrow is whatever the file says today.

The first time a helper does something off, open its file and tighten the part that allowed the slip. Maybe it flagged too aggressively. Maybe it missed something obvious. Maybe it drifted into a register you don't want. A fix in the file fixes every future run. A fix in the chat fixes only that one.

Fix the file, not the chat

A fix in the file fixes every future run. A fix in the chat fixes only that one. When a helper does something off, open the file and tighten the part that allowed the slip — flagged too aggressively, missed something obvious, drifted into a register you didn't want. That edit is durable; the next chat will inherit it.

Next: Part 5 — Pipelines extends the same workspace by wiring helpers together so they hand off to each other end-to-end.

Part 4 of 6