We keep trying to make LLMs reliable by writing the perfect prompt.
Lay out every step. Number them. Anticipate each branch. Specify the
output format, the edge cases, the tone. Build the plan so completely
that the model has nothing left to do but execute it.
And it half works. Until the work changes slightly, or the input arrives
in a shape you didn't foresee, and the plan that was supposed to guarantee
the result is suddenly the thing getting in the way.
I spent a long time building harnesses this way. Rich function
descriptions, clear specs, every primitive exposed and well-named. The
system was brittle anyway. Sometimes the model reached for the right tool;
sometimes it didn't. Change one thing and something that had worked
stopped working. The information was all there. The reliability wasn't.
The problem was not that the plan was incomplete. The problem was
that I was treating the plan as the engine of action,
rather than as a resource for action.
Plans don't cause action
In 1987, Lucy Suchman made a distinction that has aged better than almost
anything written about computers since. Plans, she argued, do not cause
action. They are a resource we draw on while acting in a situation. The
real work happens in situ — moment to moment, reading where you are, what
is at hand, what would count as a sensible next move. The plan is a story
we tell before and after. It is not the thing that does the work.
A skilled practitioner doesn't follow a plan. They have situated
awareness: a working grasp of the practice as it unfolds. A carpenter
faced with a knot in the wood doesn't consult a flowchart. They know what
the wood affords, what the tools offer, what the job is for — and they
respond.
That is what the LLM was missing. Not a better plan. Situated awareness.
What you give instead of a plan
There is a long body of work on how practices actually work — practice theory,
running from Wittgenstein through Schatzki, Reckwitz, Shove.
It describes a practice as a bundle of constitutive elements: the ends and
orientations that give the work direction, the practical understandings that
let someone recognise what to do, the rules, the affordances, the materials.
That bundle is the captured structure of a practitioner's situated
awareness about a kind of work. And it turns out you can hand it to an
LLM.
Not as a script to follow. As a resource to hold while acting. Give the
model the bundle — the purpose, the understanding, the rules, what the
tools afford — and let it be the practitioner. Then point it at the end
result and get out of the way.
The difference is not subtle. A model holding a practice doesn't need
every step spelled out, because it understands what the work is for. It
recognises the situation and responds to it. When the input arrives in an
unexpected shape, it doesn't break — it does what a competent practitioner
does, which is to read the circumstance and meet it.
Competence meets circumstance. That is the whole thing.
What this looks like in a harness
In practice, this means I no longer start by giving the model a long
procedural prompt.
I give it a practice.
A practice bundle might contain:
- Teleo-affective structure: what the work is for, and the stance to take
- Understanding: what matters in this kind of situation
- Rules: what must be preserved or avoided
- Affordances: what the available tools make possible
- Materials: what the model is acting with and on
For example, instead of:
- Read the calendar.
- Check for conflicts.
- Decide whether the event matters.
- Ask for clarification if needed.
- Apply the change.
I give it the structure of calendar stewardship: what the practice is for,
what counts as care, what rules constrain action, what affordances the
calendar tools provide, and what kinds of judgement matter.
The model is still bounded — it still has tools, rules, and checks. But the
centre of gravity moves from procedure to situated competence.
When the situation shifts, it is not trapped inside the original plan; it reads
the circumstance, uses the affordances at hand, and continues towards the goal.
There is no plan
The instinct to over-specify comes from a culture that has taught us to
trust plans over responsiveness — to believe that the confident, detailed,
step-by-step account is the real work, and the messy in-the-moment
judgement is just noise to be engineered away.
It is the other way around. The judgement is the work. The plan was
always just a story about it.
So stop writing the perfect prompt. Give the model situated awareness, and
let it focus on the end.
There is no plan. There was never a plan. Things get built anyway.
The work behind this
This is the short version. The full argument — including a working
implementation, an autonomic self-improving loop, and a worked example
running under a real LLM harness — is set out across four essays, best
read in order:
AI Trust and Situated Awareness: A Practice Theory Reframe
— the reframe, from "meaning layer" to situated awareness.
10.5281/zenodo.20306761Practice Theory — The Apprenticeship and a Strange Loop
— how the practice is transmitted, and how the system maintains itself.
10.5281/zenodo.20354614Practice Theory — The Implementation
— a walk-through from a real practice to running code.
10.5281/zenodo.20405699Practice Theory — A Worked Example (Calendar Stewardship)
— a single practice, enacted end to end under a live harness.
10.5281/zenodo.20406162
Companion software:
practice-theory-implementation
— 10.5281/zenodo.20405235
Monyet Batu — symagenic.com ·
ORCID 0009-0007-9002-5381
Top comments (2)
Give the model a practice is a great reframe, and the reason it works is that examples are an executable spec while instructions are a description, and the model follows the spec more faithfully than the prose. A paragraph of rules is something the model partially attends to and interprets; two or three good demonstrations pin the output shape, the format, the tone, the edge-case handling, concretely, because it pattern-matches the demonstration far more reliably than it parses please always do X. Show, don't tell, but for inference. Two nuances I'd add from doing this a lot. First, example selection is the new prompt engineering: a few representative examples that cover the tricky cases generalize, but a few narrow ones cause overfitting to the demo pattern, the model latches onto a surface feature of your examples and reproduces it where it shouldn't, so the failure mode just moves from vague-instructions to wrong-examples. Second, there's a cost tradeoff, few-shot pays those example tokens on every call forever, while an instruction is cheaper per call, so for high-volume paths it's worth seeing if you can distill the practiced pattern back into a tighter prompt once it's stable. Demonstrate the pattern, but curate the demos like a test set. That examples-are-the-spec instinct is core to how I think about Moonshift. When few-shot overfits to the examples, are you fixing it by diversifying the demos or by adding a guardrail instruction on top?
I agree examples often work better than prompts. Prompts describe what should happen; examples demonstrate it. In your terms, examples are closer to an executable spec than ordinary instructions.
I think that is very close to what I mean by giving the model a practice. Examples can provide situated awareness because they show the model how the task is enacted in context, not just what rule to obey.
I think examples carry part of the practice but may underdetermine the principle. Any finite set of demos is consistent with many principles, and the model has to guess which one you meant from too few points. Overfitting isn't the model failing to be situated — it's the model resolving that ambiguity toward a surface feature instead of the one you intended. Examples can show the principle; they can't state it. A practice bundle tries to give the model a wider situated awareness. The teleo-affective structure, understanding, rules, affordances, and materials tell the model not only what has been done before, but what matters, what is being protected, what objective is being served, what tools are available, and how those tools may be used within the practice.
I went and looked at Moonshift. We're working different ends of the same problem: you're making a fleet of agents ship reliably at volume; I'm asking how you give a single agent enough situated awareness, through practice theory, to act well where the examples run out. The seam between those two ends is the edge case.
So, to your question: neither, mostly. Diversifying demos is just a denser spec — more surface to overfit. A guardrail instruction is back to brittle prose the model half-parses. What I'd do is different in kind: state the principle as principle, in the bundle, and let the examples illustrate it rather than carry it. Then in a context no demo covered, the model isn't reaching for the nearest matching case — it recognises the situation, sees which tools the practice makes available, and composes a route that honours the objective. It acts from the orientation, not from resemblance to something it was shown.
Your distill-back point marks the boundary nicely, though. Where you can compress the pattern to a tight stable prompt, you didn't need a practice — you needed a function. The practice earns its token cost exactly on the open-ended paths where no distilled rule holds.
A plan is fixed rules of engagement; being fixed, it breaks. Examples are a softer plan, but still a plan. The practice is what survives the case you didn't demonstrate.