CHOTEK

No servitor in this field has a documented biography, and the name attached to this one is no different. What follows is therefore a management framework rather than a profile: how to design a servitor, how to decide whether it should exist at all, what the realistic ceiling on simultaneous deployments is, and how the feeding and dismissal steps work once you accept that the servitor is a pattern rather than a person. The name is a handle. The framework is the actual content.

Why a Management Framework and Not a Profile

The instinct is to look up a name and find out what it wants. That lookup will produce either nothing or a description derived from a category rather than a source, and in the second case you will be working from a template with a name attached. Neither outcome tells you how to design a servitor, which is the only decision actually facing you.

A management framework answers the operational questions instead. What is this for. How narrow can the job be. How long will it be active. What does it cost me to keep it alive. What happens when I stop. How do I know whether it is working. None of those require a biography, and all of them are answerable.

The Concept Is Older Than Its Vocabulary

The servitor as a consciously commissioned attendant is a twentieth century framing of something much older. The protective attendant spirit appears in Roman practice as a genius, in medieval Christian material as a guardian assigned at baptism, and in ceremonial literature of the nineteenth and twentieth centuries as a construct deliberately built and deliberately fed. The vocabulary of charge, feeding and dismissal is inherited rather than invented.

What the later literature added was the mechanism: the idea that an entity is a displaced part of the practitioner, available for tasks, and that the practitioner is therefore responsible for what it does. That framing is the useful part and it is a design constraint rather than a metaphysics. A construct made of your own attention can only be as capable as the attention you actually give it.

Design Starts by Deleting

Almost every servitor that fails, fails at the design step, and the failure is always the same: the job description is too wide. A request for a servitor that handles money, protection, relationships and correspondence has specified four attention streams competing for one narrow budget, and no amount of charge fixes an underspecified construct.

Work by subtraction. Write the sentence you want to be able to stop doing. Then remove every clause that is not strictly necessary to that sentence. What survives should be expressible in a single imperative with one verb, one object and one condition. If the description needs the word and anywhere in it, the servitor has two jobs and should be two servitors, or one servitor with a priority order written into it.

The Attention Budget Is the Real Ceiling

Old sources place a hard limit on how many may be maintained, and modern practice has mostly dropped the number while keeping the constraint. Practitioners report three to five as a workable maximum, occasionally more for trivial tasks, and the mechanism behind the ceiling is not metaphysical. It is that each active servitor occupies a slot in working attention that never fully empties.

This is testable in the ordinary sense. A person maintaining eight constructs will report forgetting to feed them, will be unable to say what any of them is for, and will find that the maintenance is itself the activity filling the time. The number that works is a personal figure determined by how much rehearsal attention you actually have, and it is usually lower than the number you would have guessed.

Feeding Is a Memory, Not an Offering

The feeding step is described in classical sources as a transfer, and the modern reading is considerably less mystical. A feeding is a visualisation of a task already completed, performed with attention on the work the servitor did. The mechanism claimed is that the visualised memory strengthens the pattern; the mechanism that certainly operates is that recalling the completed task in detail rehearses the behaviour you are trying to make automatic.

That is worth stating plainly because it makes the practice honest and it makes it skip-resistant. If you cannot recall a specific completed task, there is nothing to feed, and the honest response is to find out why nothing has been completed. Several months of feeding without a single completed task is a signal about the servitor, not a failure of your visualisation.

Deployment Has Three Failure Modes

Three failure modes account for nearly all reported servitor problems. The first is scope creep at the call site, where a working servitor is asked for something outside its design, and the usual result is a general sense of nothing happening. The second is drift, where the pattern loses its shape over months of partial use and the construct has to be rebuilt rather than refreshed.

The third is the one nobody names, which is that the attention you spend checking whether the servitor is working is the attention it needs in order to work. Practices that generate frequent signs of activity generate an enormous amount of interpreting, and the interpreting is itself a replacement for the behaviour the construct was built to support. A construct that reduces the number of things you check is doing its job; one that increases them is not a servitor at all.

Dismissal Is Part of the Design

Classical sources treat dismissal as the most important operation, more important than creation, and the reason is structural. A construct that is never formally ended tends to persist as a background obligation, and the practitioner accumulates a set of half-finished relationships with things they no longer use.

The modern reading is that the habit fades on its own once the behaviour it was tied to stops recurring, and there is nothing dramatic in either frame. What is true in both is that an explicit ending is cheap and a drifting one is not. Write the ending at the design stage, with a condition rather than a date, because conditions are the only kind that survive a change of schedule.

What You Actually Need

The material requirements are small and the list is usually inflated. A written statement of the job in one sentence. A reduction of that sentence to a single glyph or sigil, which serves as a retrieval handle rather than as a container. A private hour. And a written record of what you want it to do, so that the specification survives the six weeks in which you forget it.

Everything else on the list - the specific candle, the particular arrangement, the consecrated tool - is downstream of those four. The tradition's apparatus is not the technique. A practitioner who has the four will do the work, and a practitioner who has the apparatus and lacks the four will collect objects and feel increasingly unmotivated, which is the most common way this subject produces a permanent hobby that never starts.

How Many, Honestly

Three is a defensible starting point and five is where most people discover their own ceiling. The figure is not a rule and it is not a target. The practical test is whether you can answer three questions about each active construct without consulting your notes: what it is for, when it was last fed, and what would tell you it had stopped working.

If any construct cannot answer all three, it is not being managed. Either the specification is too vague, the feeding has lapsed, or the verification point was never defined - and the last of those is the common one, because a construct with no observable output is indistinguishable from one that has quietly stopped existing. Define the output first, and the ceiling takes care of itself.

A Framework Card

Delete until one imperative remains. Reduce it to a glyph that means the imperative and nothing else. Charge it in a private hour with the written specification in front of you. Deploy only within the specification and treat anything else as a design bug. Feed by recalling a completed task in detail. Record the output, not the signs. Retire on a condition you wrote down at design time.

The name on the header of this framework is a handle, in the same way a filename is a handle. The framework is what is reproducible, and it will work with any name at all, which is a useful thing to know before concluding that a particular name is doing work.

Frequently Asked Questions

Should I tell other people about my servitors?

The older material treats silence as a rule. The practical modern version is narrower: tell people who will hear it as a description of a practice, and do not tell people who will hear it as a cry for help. That distinction is about knowing your audience, not about secrecy for its own sake, and it is easier to apply than either the traditional rule or the casual habit of explaining yourself to strangers.

What is the realistic number to keep active at once?

Three is a sensible start and five is roughly where most people find their personal limit, with some managing more for trivial tasks. The limit is the amount of rehearsal attention you actually have, not a property of the entities, which is why it varies so much between people with demanding lives and people who do not. Add a construct and watch whether the others still get fed before deciding the ceiling is wrong.

What happens when I stop feeding one?

Nothing dramatic, in either available reading. The classical frame has it weakening and eventually dispersing; the modern frame has the habit simply fading, since a pattern that is not rehearsed does not persist. The practical consequence is that the construct stops responding and you may not notice for weeks. If you intend to stop, do the dismissal properly rather than relying on attrition.

Does a servitor have to look like anything?

No, and a design that depends on an image is usually a design that has not been thought through. A form helps some people hold a construct in mind and is close to irrelevant for others; the retrieval handle, usually a glyph, is the part that has to work. If you cannot state the job in one imperative, no amount of visual design will save the construct, because the picture will be doing the work the specification failed to do.

Is this any different from a sigil?

They share a mechanism and differ in duration and scope. A sigil is a one-shot commitment, designed for a single outcome and then released. A servitor is a standing arrangement for a recurring class of task, and the recurring part is what creates the maintenance obligation and the attention cost. A person who wants a sigil for one specific thing should build a sigil, because the servitor machinery adds nothing to a single commitment.