Building Your First Chaos Magick Servitor: A Beginner's Design

Almost every first servitor is designed for a crisis that has not happened. The specification is written at midnight for the day everything falls apart, and then nothing falls apart for eleven months, and the specification is still sitting in a notebook with a name like VIGOR and a job description nobody could recite. The work of building a first servitor is not the charging, which takes four minutes, and it is not the naming, which takes one. It is writing a job description narrow enough to be reviewable on an ordinary day, which is a much harder thing than it sounds and the only part most people skip.

What a servitor actually is, in one paragraph

A magickal servitor in chaos magick is a deliberately simplified representation held in the mind, charged with a single defined function, and released from your awareness so you do not have to hold it. It is not a soul, it is not a demon, and the language of invocation and calling that surrounds the practice is inherited from a tradition where the terms meant something different. What it is, on the most deflationary description that still leaves the practice intact, is a standing implementation of a decision you have already made, packaged so that keeping the decision costs you nothing to maintain.

That framing explains both why it works better than willpower and why it fails in the specific ways it does. It works better than willpower because a thing you have designed, named, and released is not competing with your mood every morning. It fails when the job description was never actually decided, because then there was nothing to package and you have built a very small object with a name on it.

The comparison worth holding onto is to a standing order rather than a spell. A spell is a request. A servitor is an instruction you gave once, written carefully, and then left running.

The design sheet, and the two fields that do the work

A servitor specification has five fields. Four of them are bookkeeping. Two of them are the whole practice, and if you only write those two the other three can be guesses.

**Field one, the function, in one sentence, in the imperative.** Not a noun and not a wish. Not abundance, not protection, not general good luck. Something like: check the invoice list every Friday and flag anything unpaid past thirty days. The test is whether a stranger could read the sentence and know whether it was done this week. If they could not, the function is still a mood.

**Field two, the refusal.** What it will not do, and what happens when the situation does not match the instruction. This is the field nobody writes and it is the reason servitors get used up. A servitor with no refusal clause expands to cover the adjacent cases, and the adjacent cases are always the ones you did not want. Give it a scope limit: it will do this and nothing beyond, and if the conditions are not met it does nothing rather than improvising.

Field three is the trigger: what starts it. The ordinary version is a schedule, and a schedule is underrated, because a thing that runs on Friday works on a Friday when you are tired and unmotivated. Field four is the sign: what you will notice if it is functioning, chosen so it is not the thing you were already watching for. Field five is the cost, and for a first servitor the honest cost is five dollars of materials and twenty minutes, and anyone telling you otherwise is selling you something.

The naming, done properly, and why the name is not decoration

A name is not flavour. It is a retrieval key. A servitor is a compressed specification and a name is the index entry that lets you find the whole thing again later, and the discipline of picking one clear name is most of what keeps a practice of a dozen servitors navigable.

Use one or two words, a capital, no adjectives, no colour, no animal. Not a full title, not a description of the function, and not the function itself, because you will want several with the same function. The name is an identifier, and the function lives in the specification where it belongs.

The convention of giving a servitor a name and a description is genuinely useful for one practical reason: it makes the servitor a thing you can refer to, and a thing you can refer to is a thing you can change. A servitor with no name is much harder to revise, and revision is the normal maintenance operation. If you find yourself wanting to change the function, you want to be able to say: the one called X now does this instead, rather than attempting to locate a vague impression in the back of your mind.

This is also why a first servitor with a nine-word invented name is a small self-sabotage. You will not remember it. Write the name, write the specification, put both on the same page.

Choosing the first function: small, boring, and weekly

Your first servitor should do something small, boring, and on a schedule. Not something important. Something you would forget anyway.

Good first functions: check a recurring list and flag the items that need attention. Notice a weekly obligation you keep postponing. Keep one appointment slot defended. Review and discard one item from a backlog that is not really a backlog. The common feature is that each one is a short, repeatable, low-stakes piece of work that you currently do less reliably than you would like.

Bad first functions, in descending order of how common they are: anything about money arriving, anything about a person, anything about health, and anything you would describe as protection. Each of these has a real objection. The first two are about other parties. The last two are the ones where a first attempt produces a strong feeling and no result, and the feeling gets remembered as evidence while the absence does not.

There is a second reason for smallness that has nothing to do with ethics. A first working tells you almost nothing about whether the practice works, but it tells you a great deal about whether you will do the follow-through. A small weekly function gives you a real answer about the second question within a fortnight, and the second question is the one that predicts whether your tenth servitor will be better than your first.

The build, in the order that makes the charge work

Do the specification in writing first, on paper, away from the ritual. This is not a formality and it is not atmosphere. Written specification is what makes the servitor a specification rather than a mood with a glyph on it, and the act of writing the refusal clause is the single most useful thing in the whole process, because writing a boundary is harder than writing a desire and the difficulty is the point.

Then design the form, once, quickly. This is the step where beginners spend an hour, and an hour is a lot. A servitor form is a carrier, not a sigil, and it does not need the discipline of a sigil reduction. A simple filled circle, a small figure, a glyph for each letter of the name, a sketch, all of these are acceptable. Choose once and do not redraw.

Then the charge. Hold the form, state the function out loud in the imperative, and state the refusal immediately after it, because the two together are the specification and stating them in sequence keeps the refusal attached to the function rather than floating near it. Three minutes is plenty. The charge is not the difficult part and treating it as a test of your own power is a misreading of what the charge is for.

Then the release, which is the step everyone skips. Destroy the form, or put it somewhere you will not see it, and write down in the specification that it has been done. Releasing it is what makes it a background process rather than something you have to keep thinking about, and a servitor whose physical form is still on your desk is a servitor you are maintaining rather than running.

The first review, and the number that matters

At the end of the first month, count how many times the function was actually performed. Not how many times you thought about it, not how many times you noticed it not happening, not how many times you checked. How many times it was done.

That number is the one measurement worth having in your first month, and it measures you rather than the practice, which is the correct order. The most common first-month result is a number far below the schedule, and that result is worth far more than any claim about whether the servitor worked, because it identifies whether you actually delegated anything or whether you built a small object and then kept doing the work yourself.

Write the number in the specification. Then rewrite the function with the knowledge you now have, and adjust the trigger. A first servitor that was scheduled for Friday and actually ran on four Fridays out of five has told you something specific: the trigger needs to be earlier in the week, or the function needs to be smaller, or both.

What this review cannot tell you is whether the servitor did anything. With one small low-stakes function and a thirty-day window, the honest answer is that you cannot separate the effect from the effect of having written a specification down. That is fine at this stage, because the first servitor's job is to establish that you can specify, build, release, and review. Do that four times and the effects become answerable. Skip it and you are reading your own mood.

Five ways a first servitor goes wrong

**The function was a mood.** The most common failure and the hardest to see, because a mood written down looks like a decision. If your specification says abundance or protection or better energy, you have not built a servitor. You have built a badge.

**No refusal clause.** The servitor expands. This shows up most often in helpful directions, which is why it goes unnoticed: it starts doing adjacent small things you did not ask for, and the accumulation is gradual enough that you never catch the moment it started.

**The form was designed for an imagined crisis.** Rare, because a first servitor is almost always designed for a real irritation. But when it happens, the specification describes conditions that have not occurred, so there is no review date, so the servitor is never assessed, so it never gets revised or retired. Those accumulate too.

**You kept the form.** A visible form is a maintenance burden, and a maintenance burden gets dropped. This is the most reliably avoidable of the five and it costs nothing to get right.

**Building the second one before the first has a review date.** Enthusiasm is a reasonable response to the first success. The record shows that the most productive servitor practitioners are not the ones with the most servitors, they are the ones who can tell you what each one did last month, and that property is destroyed the moment you build ahead of reviewing.

The ethics of a first servitor, which is easier than people make it

A first servitor built on a small boring weekly function has no ethical content at all, and that is not an accident of convenience. It is the reason to build it that way.

The ethics live entirely in the target. A function about your own inbox, your own schedule, your own backlog is a function about you. The moment the function names another person, another person's money, or another person's decision, you are running a standing instruction against someone who did not agree to be the target and who cannot see the instruction, and that is a meaningfully different act from a request, which can be answered and declined.

The standard worth holding is simple and it is about permanence. A request can be withdrawn by the person it is aimed at. A standing instruction cannot. If the other party knew, could you describe this exactly, and would they say yes, it may be within bounds. If the answer to any of those three is no, the permanence is the problem, and no amount of care in the charging changes it.

There is also the case for keeping the first one in your own affairs, which is not merely caution. A servitor aimed at your own routine teaches you the whole cycle, specify, build, release, review, revise, retire, and a practitioner who has run that cycle four times on their own paperwork is far better equipped to handle a working that involves anyone else than one who has read about it.

What to build after the first, and what never to build

After the first month, build the second servitor on a function that is still yours and slightly more consequential: a relationship you maintain, a commitment you keep, a habit you are trying to install rather than maintain. The skill you are learning is specification and review, and both transfer to more consequential targets once they are automatic.

The third is where the practice either becomes a practice or becomes a collection. A third servitor should have a function you can state in one sentence and a review date you wrote in advance, and if either of those has become hard, the honest move is to run another month at the second level rather than to escalate.

There is a category of servitor that should never be built, and it is worth naming because it is the one most often requested. A servitor for general wellbeing, for protection from all negative influences, for luck, for the energy of the room: these are not narrow functions, and the reason they fail is not that they are spiritual but that they are unfalsifiable. You cannot count how many times a general wellbeing ran. A function that cannot be counted is a state of mind wearing a specification's clothes.

The one exception worth allowing is a broad function that you then define narrowly in the specification anyway. If someone tells you they want a protection servitor, the useful version of that is a specification about one specific exposure, on a schedule, with a sign. The narrow version is usually what they wanted anyway.

Frequently Asked Questions

How long does it take to build a magical servitor?

Twenty minutes of specification on paper, about four minutes of charge, and thirty days before the first review is worth anything. The build itself is quick and the writing is the work, which is why so many people get the ratio wrong. If someone quotes a multi-day construction ritual for a first servitor, either they are describing something else or they are describing ceremony as the substitute for a decision they have not made.

What is the difference between a servitor and a sigil?

A sigil is a one-time instrument for one intention, and its charge is generally released immediately. A servitor is a standing implementation, built to run repeatedly on a schedule, with a defined function, a refusal clause and a review date. If you are doing something once, you want a sigil. If you want something that keeps happening without you re-deciding each time, you want a servitor, and the extra fields are the whole difference between the two.

My servitor does not seem to be working. What now?

Count first, before you interpret. Over the review period, count how many times the function was actually performed and how many times it could have been but was not. In most disappointing cases the number is low, and the servitor was never the problem: the specification was fine and the trigger was not firing. Move the trigger earlier in the day, or shrink the function until it is too small to skip. Only if the function is running reliably and you still see nothing should you conclude the practice does not work, and at that point the honest conclusion is about the practice, not about the particular servitor.

Do I need to feed or maintain a servitor?

For a beginner, no, and the tradition of elaborate feeding is one of the things people add after the fact. What a first servitor needs is a review date and a revision, and those are maintenance in the sense that matters. If you find yourself building rituals around keeping it happy, that is a sign the specification is not doing enough work, because a well-specified function is not going hungry.

Can a servitor affect another person?

Technically a specification can be written about anything, and some will do it. It is worth being clear about what changes when the target is another person: a request can be declined by the person it is aimed at, and a standing instruction cannot. You are now running a permanent procedure against someone who has not seen it and cannot withdraw from it. That difference is the whole of the ethics, and it is a reason many practitioners keep early work entirely within their own affairs, where it is a good way to learn the cycle without spending anything on anyone else.