Primitives, Not Rules

Most of the prompts I see in the wild are rule lists. Always do X. Never do Y. If condition Z, do A. Use exactly three bullet points. Avoid em dashes. Don't be sycophantic. Match the user's tone unless they're being rude, in which case stay professional.

These prompts grow over time. Someone notices an edge case, a rule gets added. Someone else hits a different edge case, another rule. Soon the prompt is a stack of patches, each one a tombstone for a moment when the model did something the author didn't want. The prompt becomes a brittle accumulation that nobody fully understands, including the people who wrote it.

This works, mostly, until it doesn't. The rules collide with each other in cases the author never considered. The model satisfies the letter of the rule and violates its intent. A rule that was useful for last quarter's model becomes a leash on this quarter's.

There is a different approach. Instead of enumerating rules, state primitives.

A primitive is the underlying concept the rules were trying to approximate. Consider escalation in an organization. A rule list might say: escalate when the cost is over $10k, escalate when it affects another team, escalate when a client is unhappy, escalate when a timeline changes, escalate when staffing changes, escalate when scope is added. Each rule gets added after someone didn't escalate when they should have, or escalated when they shouldn't have. The list grows. It also produces strange outcomes. People escalate the $10,001 decision they should obviously make themselves, and skip the $9,000 decision that quietly sets a precedent for the whole org. New situations the rules never anticipated produce wrong answers in both directions.

The primitive behind all of those rules is simpler: you need consent from whoever's options you're constraining. If your decision narrows your own future options, decide. If it narrows your team's, the team should weigh in. If it narrows a relationship someone else owns, the owner needs to be in it. If it narrows the organization's direction, leadership decides.

Every case the rules were trying to cover falls out of this. The $10k threshold was a proxy for "big enough to affect other people's options." The team-affecting rule was the same thing at a different scope. The client-unhappy rule was a proxy for the relationship owner's optionality being constrained by something they didn't consent to. Cases the rules never anticipated still resolve correctly, because the primitive describes the actual underlying concern: who has the right to consent to having their optionality reduced.

This sounds simple. It is not. The hard part is that primitives are exposing. You can write a hundred rules without ever knowing what you actually want. The rules give you the illusion of intent. A primitive forces you to articulate the thing the rules were standing in for, and when the primitive is vague or contradictory, you can't hide. The output reflects exactly the quality of the primitive. There is no fluff to lean on.

Internal coherence becomes load-bearing. Rules can quietly contradict each other and nobody notices until a specific case hits the seam. A primitive, if it's internally contradictory, is just incoherent on its face. You either fix it or admit you don't actually know what you want.

This brings up something underappreciated about the rule approach: a lot of it is a workaround for human cognition. Rules exist because the agent reading them, historically a person, is processing through fatigue, context switches, distraction, and their own priors. The rule is a guardrail for an attention system you can't trust to internalize intent in real time across a long task. Standard operating procedures, checklists, style guides, training manuals: these are scaffolding for human cognitive limits, not the actual thing the organization cares about.

Agents do not have the same constraints. A capable model can hold a primitive in working memory across an entire task and derive behavior from it consistently, without the drift you get from a tired human reading the same SOP for the fortieth time. The cognitive overhead that justified rule lists for human operators is increasingly unnecessary. You are paying a precision cost to compensate for a limitation the agent does not have.

That cost is the real tradeoff. Rules give you precision: predictable, repeatable, narrow outputs. Primitives give you fit: outputs that match what the situation actually called for, even in cases you didn't enumerate. Precision is low variance. Fit is high expected quality across an open distribution of situations. When you can't tolerate variance, when the work is compliance-bound or safety-critical or audit-bound, rules still earn their keep. When you can tolerate variance and what you actually want is the right response across situations you couldn't enumerate ahead of time, primitives win.

There's a capability threshold. A weak model needs more scaffolding because it cannot derive correct behavior from sparse principles. As models get more capable, the threshold drops, and the rules you used to need become friction. The prompt that worked beautifully on a 2023 model is a cage on a frontier one. Primitives age better because they describe the goal, not the workaround, and the goal doesn't change as the model improves.

None of this means primitives are easy or automatic. A bad primitive coherently applied produces systematically bad output, and that failure mode is worse than a bad rule, which only breaks in one place. The work shifts from "enumerate edge cases" to "find the actual concept." That's harder intellectual labor, and it's why a lot of prompt engineering still defaults to rule stacking. Rules feel productive. You can add one. You can measure that the new behavior happened. There's a commit history of small wins.

Primitives require sitting with a problem long enough to know what you actually want. There's no satisfying log of patches. There's just the work of getting the idea right.

The bet is that this work compounds. A primitive you got right will keep being right across model upgrades, edge cases, and uses you didn't anticipate. A rule list you got right will be a mix of rules that still earn their keep and rules that were workarounds you can no longer see as workarounds. Sorting that out means deriving the primitive the list was approximating, which is the work you avoided in the first place.