A jig is a purpose-built harness around a model. It gives the model the context, tools, constraints, workflow, and verification needed to do one class of work well. The model stays adaptable and can still reason its way through an unfamiliar problem, but the system around it makes the path to a useful outcome explicit.

I started uncovering this idea in The Runtime Is the Product. The Model Is a Component. , where the argument was that the runtime should own the workflow, the guardrails, the tool boundaries, and the verification. That is still the argument. This post is where I put a name to it.

The name is The Jig.

Large language models are powerful, and power is not the same thing as reliability. Give a model an open-ended brief, filesystem access, a shell, and a blank workspace, and it may produce something remarkable. It may also take an appealing shortcut, skip a constraint, declare victory too early, or solve a problem adjacent to the one you actually asked about.

A better prompt does not fix that.

In manufacturing, a jig guides a tool so the work can be repeated accurately. It does not replace the tool. It makes the tool worth pointing at production work. The same idea applies to LLMs.

The model is not the system

We often talk about an LLM as though it is the product. Pick the model, write the prompt, add a few tools, and hope the intelligence carries the rest. That framing asks a probabilistic system to guarantee an outcome.

A model can interpret language, generate alternatives, recognize patterns, and make useful leaps. Those are extraordinary capabilities. What it does not have is your domain: which constraints matter most, which actions are safe to take, what has to be verified before anything is called finished, and what “done” means for this particular kind of work. None of that is in the weights, and restating it at the top of a conversation does not make it binding.

A Jig makes those decisions first-class. It turns a vague instruction such as “build this feature properly” into a defined sequence of valid operations, observable evidence, and meaningful gates.

The goal is not to make the model deterministic. Its reasoning is probabilistic, and part of its value comes from exactly that. The goal is to make the outcome dependable even when the reasoning wanders.

A reference implementation

I have been building one example: spec , a spec-driven BDD and TDD harness for software delivery. It is built around a single problem, getting from a requirement to working, tested software without letting the process quietly lose its way, which is what makes it one Jig rather than the shape every Jig should take.

Here the requirements specification is the source of truth. It is structurally validated, then checked for vague wording, before a scenario or a line of production code exists. Behavior flows from the approved requirement into Gherkin scenarios, step definitions, tests, and implementation, in that order.

Red, Green, and Refactor are enforced as states. A refactor cannot begin while the tests are red. A requirement cannot be marked complete without the evidence that it passed. Every change is staged for review. The model gets no unrestricted filesystem, shell, or dependency-installation access; it reaches the work through a fixed set of tools and nothing else.

That is the difference between a Jig and an agent holding a detailed instruction sheet. The commands do not matter, nor the language it is written in, nor even that the domain is software delivery. What matters is that the harness knows the shape of good work in its domain, and can tell when it is not getting it.

Prompts describe, Jigs enforce

Prompts are still useful. They carry intent and leave the model room to think. They are a weak place to keep anything non-negotiable.

If a requirement must be clear before work starts, validate it. If an action is only valid in a particular state, make the state explicit and refuse the transition. If a change must be reviewed before it becomes real, stage it. If success needs proof, collect the proof rather than accepting the model’s confidence in its place.

The test for what belongs in the Jig is whether the model can skip it. Anything a model can talk its way past is a preference, not a rail.

So the question stops being how we get the model to follow our process, and becomes which parts of that process should never have depended on its discretion. The model spends its intelligence on interpreting intent, proposing solutions, writing code, diagnosing failures, and adapting to what it observes. The Jig holds the allowed actions, the required sequence, the domain context, the checkpoints, and the record.

A Skill is not a Jig

The objection I expect here is that all of this already exists. Skills package the context, the instructions, the reference material, and sometimes the scripts for a class of work. Hand one to a general-purpose agent and surely you have a Jig.

You have a briefing. The Agent Skills specification loads those instructions once the agent has decided the skill is relevant, so the model chooses when the guidance applies and how much of it survives contact with a hard task. Apply the test from the previous section and a Skill fails it by construction, because activation and compliance are both the model’s call. The cost side told me the same thing when I measured it, and what mattered was never the packaging: it was whether the rule ran inside the model or in code .

This is why a generic agent does not turn into a Jig when you attach a better Skill to it. The package can describe good work in exhaustive detail. It cannot hold the state, block a step that should not happen yet, or notice a step that never happened at all. Nobody inside a Skill has the job of saying no.

Tools are the grip

Something has to hold instead, and in a Jig it is the tool surface. MCP is usually sold as reach, a standard way to give a model more capability. Inside a harness the valuable property is the inverse of that. When tools are the only way to touch the work, the set of things the model can attempt is finite, typed, and known before it starts, and every attempt arrives as a call the harness can permit, refuse, or record. A narrow tool list is a clamp. Because MCP is a standard rather than a private interface, the same grip holds whether a general-purpose agent is driving or the harness is sequencing the work itself.

The grip is also how truth reaches the model. Left to its own account of what it did, a model reports the version of events it finds most plausible, and it is fluent enough to make that version sound like a result. A tool returns what actually happened: the validator’s verdict, the color of the bar, the state the workflow is genuinely in.

Which makes the return value as important as the permission. A tool that answers “ok” leaves the model exactly where it was. A tool that answers that an acceptance criterion has no Then clause, and that “quickly” is not measurable, has handed it something to work with. Restraint and evidence come through the same channel, and that is what makes the grip tight without making it stiff.

The model still reasons however it reasons, and it is free to be wrong along the way. What it cannot do is carry a wrong claim about the work past a call that is able to contradict it.

Build Jigs, not generic agents

General-purpose agents earn their flexibility on work with no settled shape, which describes most exploration. A great deal of engineering work is not like that. Shipping a feature, investigating an incident, preparing a release, reviewing a change, running a security assessment, migrating a system: each one has known constraints, known failure modes, and evidence that ought to exist before anybody calls it complete. That is where a Jig repays what it costs, and it does cost more than writing a prompt. Repetition is what justifies the build.

The opposite failure is worth naming too. A Jig that tries to script every decision has stopped being a harness and become ordinary automation with an expensive model sitting inside it. Narrow enough to understand the work deeply, open enough to leave the model everything that cannot be reduced to a fixed script. It should not try to predict the answer. It should create the conditions in which a good answer becomes safe, testable, repeatable work.

So we are not choosing between rigid automation and unconstrained intelligence. We can build systems that use everything the model is good at and still keep the outcome in human hands, because the harness we built is what decides when the work is finished.

That is the Jig.