The Essence of Direct Magick

You found my old blog. Thanks for visiting! For my new writing, visit

Amonjinn asked me over dinner, “What’s special about direct magick?” It’s a common question. I’m still figuring out how to answer concisely.

This time I tried a math analogy:

Say you solve a problem with a computer program. You put in some numbers, it spits back the answer. You have no idea how it works, it just does. That’s indirect math, like ritual magick.

Other end of the spectrum: You solve everything by hand, doing long division and all. You understand every step. That’s 100% direct math. Note: It’s often not practical except for figuring out how to solve a problem the first time.

The middle-ground: You understand all the steps, but use a calculator for the division. Or you write a program in Matlab, offloading the repetition to the computer. That’s practical direct math.

To bring this back to magick: Systems (the forces you channel, that help you do magick) are like magick computers. If you let them, they can do magick for you, without you needing to understand what’s going on.

Direct magick is mostly about not relying on systems without understanding them. It’s not a matter of “did you do that without a calculator?” but rather “do you understand what calculator did, and can you see why that step goes there?”

Is learning long division worth it? Depends on your goals. If you want to solve one problem once, and never go there again, then no. Just use a system that solves that problem. But if you want to advance the field, create new math equations / magick techniques, then understanding the inner-workings of the old ones is vital.

The other reason direct is worth it: Curiosity. It lets you understand how magick works. Which is probably the best reason of all.

If you liked this post, consider visiting my current blog at


4 Responses to “The Essence of Direct Magick”

  1. Ananael Qaa says:

    Essentially what you call “direct magick” is what I call “ritual magick” in contrast to “ceremonial magick.” As a software developer, a perfect analogy to this can be found in my professional field – the developer versus the end user.

    You don’t need to know how to program a computer to use Microsoft Word. If what you want to do is edit documents you’re good to go without having to code anything. But if you want a better word processing program you need to write it yourself, and that requires much more specialized knowledge about how to create a program.

  2. Yes, that’s right, that’s the analogy I’m going for.

    But usually, rituals work at magick’s interface, and to program, you need to work at magick’s implementation. So I’m curious about what you do when you talk about “ritual magick.” Could you elaborate or refer me to a post?

  3. Ananael Qaa says:

    I touch on the basic idea here, in addition to airing my complaints about Joseph Lisiewski’s system of evocation:

    The idea is that a “Ritual” consists of instructions for performing a “Ceremony.” So “Ceremonial Magick” would refer to taking an existing set of instructions and implementing them (end user), while “Ritual Magick” would refer to developing and optimizing those instructions (developer). It is my own interpretation of the terminology, but it will be published as part of the introduction to my new book on the Heptarchia Mystica which I expect to be out sometime in the next couple of months.

  4. We’re thinking along the same lines. And I’m glad to find some common ground with you, it will let us talk more easily.

    I agree that strictly adhering to the way people did magick 1000 years ago is kind of silly, and reading between the lines, I agree that understanding how each ritual component works so you can build your own “sentences” out of a series of those symbols shows a greater mastery of the material than using a pre-packaged ceremony. Like the difference between someone who downloads a script they don’t understand and a programmer who can write the script from scratch.

    But something has to respond to those symbols. There has to be some interpreter somewhere, turning that program you wrote into magick. Right?

    So here’s the question I pursue: How does that interpreter work? Because if you understand that, you can do magick without it, or use a different interpreter that’s specialized for a different task, or even build your own.

    To add to the “download a script vs write your own” analogy, if you’re writing a SQL script, I want to understand how the database is implemented. If you’re writing JS, I want to understand how routers deliver HTTP messages and how Firefox is implemented. I want to understand the underlying technologies that make writing that script possible, that turn the script from words into executable instructions.

    That’s something I haven’t quite explained yet. Which is part of my purpose in writing this blog and sometimes butting heads with other practitioners — to figure out what I haven’t explained yet, and figure out how to explain it.

    By the way, that interpreter is what I call a “system.” Other mages might call it an “egrigore,” though I haven’t been satisfied with the mechanics of egrigores, since it seems to center around “sending out intent,” which is a non-mechanic. But that’s a post for another day.

Leave a Reply