Four primitives, one deliberate choice

▸MODULE 1 / PRIMITIVE CHOICE

What we are talking about

Before you build a single autonomous loop, you make a decision that determines whether it succeeds or fails silently: which form of repetition does your task even need? A loop, meaning a task that keeps kicking itself off again and again until a goal is reached, is only one of four tools. Skip this, and you often build a heavy machine for something a single run would have handled.

You come from multi-agent orchestration and you command the tool in the terminal. That is exactly why we do not start with setup, but with thinking. This lesson hands you a decision grid with four axes that lets you assign any new task to the right primitive in seconds. A primitive here is simply a basic building block, a mode of operation in which your tool runs a task.

The four axes, explained at a workshop

Picture a workshop where four different kinds of work come up. Each kind wants to be handled differently, and that is exactly how it is with the primitives.

The finite-objective primitive is work with a clear end. You say what should be done, and the tool runs toward it until it is reached. That is the board you saw until it is the right length. In Claude Code this is the /goal mode: a goal that gets steered toward, not a plan you dictate step by step.

The stream primitive is listening. You do not wait actively, you get woken up when something happens. That is the doorbell that rings, instead of you walking to the door every few minutes to check. Technically this means reacting to an event that a running process reports, instead of polling it blindly.

The periodic primitive is the recurring round. Something runs on a beat, again and again, as long as you keep it running. That is the inspection round through the workshop, the same check every few minutes. This is the loop in the narrow sense, the /loop.

The durable primitive is the fixed appointment. Something happens reliably at a set time, even when no one is watching and no terminal is open. That is the trash that gets taken out every Tuesday. Technically these are Routines or a cron job, meaning a time-controlled entry that the system itself kicks off.

One criterion and one everyday case per axis

You do not have to memorize the distinction, you have to be able to decide it. For each axis there is a single question that leads you there.

Ask for finite-objective: is there a state where the work is verifiably done? Example: all tests are green, then it stops. Ask for stream: are you waiting right now for a specific event? Example: a long build is running, and you only want to act once it reports whether it passed. Ask for periodic: should the same check repeat on a beat until a state changes? Example: as long as a deploy has not gone through, fetch the status every few minutes. Ask for durable: does this have to run even when your machine is closed? Example: every morning a report, whether you are sitting at your desk or not.

The anti-pattern: loop-by-default

The most common mistake is not picking the wrong primitive, but picking one at all where none is needed. Loop-by-default means out of habit packing every task into a loop, because loops look like skill. Often a single, well-led run is enough. If your task has a clear end and needs no waiting and no beat, then it is not a loop. It is a single /goal run or simply a normal job you give once.

This restraint is not a detail at the margin. It is the most expensive lesson of the whole course, pulled forward: an unnecessary loop costs you tokens, meaning paid model usage, and it can run silently in circles without you noticing. A single run cannot do that.

Assign your own tasks

Pick three real tasks from your everyday work and assign them. You copy the prompt below into your AI tool, and it walks you through the decision.

I am deciding which primitive three of my tasks need.
Ask me these four questions one at a time for each task and name at the
end the matching primitive with a short justification:

1. Is there a state where the work is verifiably done?
   (If yes, that points to finite-objective.)
2. Am I waiting for a specific event, instead of asking actively?
   (If yes, that points to stream.)
3. Should the same check repeat on a beat until something
   changes? (If yes, that points to periodic.)
4. Does this have to run even when my terminal is closed?
   (If yes, that points to durable.)

If no question is a clear yes: it is probably not a loop at all,
but a single run. Tell me that honestly.

If at the end you can say for each of your three tasks which primitive it needs and why, you have reached the goal of this lesson. And if one of them needs no primitive at all, that is the most valuable answer.

The honest assessment

The four primitives themselves are not hidden away. Which modes your tool knows and what their syntax looks like you will find in its documentation, and you should read it as of now, because tool surfaces change every month. What this course delivers is not the list of modes, but the decision logic in front of it: knowing when you take which one, and when you take none at all.

This grid does not replace judgment. There are mixed cases, for instance a task that checks periodically and, on a specific event, tips over into a finite-objective run. You solve such cases by combining the axes, not by ignoring them. And the temptation to make everything a loop persists even once you know the grid. The discipline to sometimes build nothing is a matter of practice.

In the next lessons of Module 1 we look at each axis on its own, with one typical case per primitive, and after that you build your first real finite-objective goal.