The Quiet AI.
← Articles

Not Every Worker Needs the Same Load

Does the worker produce user-facing prose or design? That single question routes every worker registration in the brand.

Three numbered worker-registration categories — in-folder content at full load, external brand-engaged pulled on demand, external pure utility as pointer-only — beside a large 3.

A transcription utility runs on an old Mac in the corner of the room. Its job is to take an MP4 of someone else’s training video and produce a .txt of the spoken words. It does not write anything for the brand. It never sees the audience.

An animation worker on a different machine renders short videos with on-screen text. Some of that text is brand voice. The worker has to know what brand voice sounds like, or the captions read like every other AI-rendered Remotion video on the internet.

A content worker inside the project tree writes captions, articles, podcast scripts. Brand voice is its native medium.

Three workers, three different relationships to brand voice. Loading them all with the same CLAUDE.md shape is the most common waste I see in operators copying this pattern.

The decider

Does the worker produce user-facing prose or design? Yes leads to category 1 or 2. No leads to category 3.

That single question routes every worker registration in this brand. It is the only piece of the system that did not get re-litigated after the first month.

The three categories

Sanitized registration table.

CategoryExampleRegistration depthWhat triggers a dispatch
1 — In-folder contentcontent-claudeauto-loaded via sandbox CLAUDE.mddirect dispatch on routine flow
2 — External, brand-engagedanimation-claudepulled on demand via ../ to one referencedispatch when worker produces user-facing prose or design
3 — External, pure utilitytranscribenonenever auto-dispatched; operator initiates
A depth gauge across the three categories: full load for in-folder content, on-demand pull for brand-engaged workers, pointer-only for pure utility.
fig. 1 — registration depth by category

Why the depth has to match

Category 1 carries the most context. The sandbox lives inside the tree, so the operator can hop in and out without re-importing voice rules. The cost is that every cold start in this sandbox loads brand context. For a worker that uses that context every dispatch, the cost is worth paying.

Category 2 is where I over-registered for months. The instinct is to give every external worker the full brand context, because the worker might produce something user-facing. The actual move is to keep brand context out of the sandbox and pull it via a ../ relative path only on dispatches that render user-facing prose. An animation worker dropping a Pexels stock clip into a Remotion template does not need brand voice loaded. The same worker rendering on-screen captions does. Same sandbox, different load, decided by the brief.

Category 3 is where I under-registered before this got formalized. A transcription utility, a video re-encoder, a metrics scraper: these have no business carrying brand voice. The orchestrator registers them with a single-line pointer in the EXTERNAL WORKER SANDBOXES section, notes that the worker is operator-mediated, and stops. Auto-dispatching them is a category error. Output is raw, and the operator decides whether and how to transform it into anything brand-facing.

What goes wrong when the categories blur

Two failure modes appear.

Over-registration: a utility worker carries brand context it never uses. Every cold start pays the tax. The voice it learns is voice it will never speak. Tokens spent for zero benefit.

Under-registration: a brand-engaged worker is treated like a utility. It renders on-screen text without the voice reference. The text reads generic. The operator notices a week later when the post lands flat, and now there is a re-render cost on top of the original render cost.

Two failure modes side by side: over-registration paying a context tax for voice never spoken, and under-registration shipping generic text that has to be re-rendered.
fig. 2 — over-registration vs under-registration

The decider question above eliminates both modes in a single check. The cost of asking it is approximately zero. The cost of skipping it shows up later.

What this is not

This is not a permission model. Workers do not have ACLs. Registration depth is about what gets loaded into context, not about what the worker is allowed to do. The boundaries are enforced by the brief and the sandbox CLAUDE.md, not by file permissions.

This is also not the standard plugin or extension model. There is no central registry of approved workers. There is a single section in the orchestrator’s CLAUDE.md that lists external workers and their category. Adding a new external worker means adding a row to that section and writing the sandbox CLAUDE.md to match the category’s depth.

Two companions in this series: The orchestrator is not the worker and Five locked rules of daily dispatch.

The cost of asking it is approximately zero. The cost of skipping it shows up later.

If this is the kind of slow, unglamorous, actually-works thinking you want more of, that’s the conversation I have most days.

Work with me

Or keep reading — more articles.