The most useful advice I’ve found this year on writing instructions for AI agents comes from a 1976 paper about designing factory work.

Albert Cherns, a British organisational researcher, published nine principles for designing work systems, as “a checklist, not a blueprint.” The second is called minimal critical specification, and it reads like a description of how agents are instructed today:

“While it may be necessary to be quite precise about what has to be done, it is rarely necessary to be precise about how it is to be done.”

That’s a good description of an agent brief. It also says something about agent governance that I don’t see discussed much.

For the rest of us: scripts versus briefs

There are two ways to tell someone, or something, how to do a job.

A script spells out every step: open this file, copy this field, paste it here, click submit. Traditional software automation works like this. It’s predictable, and it breaks the moment reality differs from the script.

A brief gives the goal and the limits: “Reconcile these invoices against the purchase orders. Flag anything over 5,000. Don’t contact suppliers directly.” How the work gets done is left open. That’s how you’d instruct a capable colleague, and it’s how AI agents work. You give them an objective, tools and constraints, and they work out the steps themselves.

The move from scripts to briefs is the move from conventional automation to agents. And sociotechnical researchers thought hard about briefs fifty years ago, when the question was how to design work for people.

What Cherns meant

Cherns wrote that the principle has two sides. The negative side: “no more should be specified than is absolutely essential.” The positive side: “we identify what is essential.” Most organisations, he observed, have “far too much specificity about how and, indeed, about what.”

His best illustration was British railway workers. When they wanted to put pressure on management, they didn’t strike. They “worked to rule,” following every regulation exactly, and the whole system ground to a halt. Many rules, Cherns noted, exist to protect whoever imposed them when things go wrong. Strictly applied, “they totally inhibit adaptation and even effective action.”

The principle came out of a humanist tradition. Leaving the “how” open respected workers’ judgment and let them adapt to conditions no designer could anticipate. It was about autonomy for people.

The flip

Apply the same principle to an agent and it still works, but its purpose reverses.

For a human crew, the open space was where judgment and adaptation happened, and specifying less protected their autonomy. For an agent, the open space is where it will make choices nobody reviewed in advance. It’s where it might pick an unexpected tool, take an unexpected path, or go a step further than intended. Specifying less still makes the agent useful. But the open space is now the risk surface.

That changes what “critical” means. The positive side of Cherns’ principle, identify what is essential, is no longer mainly about the task. It becomes the governance design. I find it useful to break it into three questions:

  • Which constraints matter? What must never happen, which actions need a second signature, what spending or data limits apply?
  • Who sets them? Constraints written by the person who happened to configure the agent are different from constraints owned by someone accountable for the outcome.
  • How are violations detected? A constraint nobody checks is a suggestion.

OpenAI researchers proposed a similar list in 2023, in a paper on practices for governing agentic systems: limit the agent’s scope, make its reasoning legible, make it interruptible, set sensible default behaviours, and keep some form of oversight. That’s minimal critical specification written from the other side. As the paper’s own framing makes clear, it’s a lab describing how its own kind of product should be governed, so read it as a set of proposals rather than proven practice.

Two more principles that carry over

Cherns has other principles that apply to agents almost unchanged.

Control errors where they happen. Cherns argued that problems should be caught as near to their point of origin as possible. Inspection in a separate department “some time after the event” makes correction “a long loop, which is a poor design for learning.” For agents, that’s an argument for checks built into the workflow, where the agent validates its own output against tests or rules before handing it on, instead of relying only on a reviewer at the end. The recent research I’ve been reading on agents points the same way. One 2026 method, SkillOpt, lets one model propose changes to an agent’s written instructions while a separate model tests each change before it’s accepted. The check sits right next to the change.

Design is never finished. Cherns called this “incompletion”: “As soon as design is implemented, its consequences indicate the need for redesign.” His image was the Forth Bridge, where painters finished at one end just as the other end needed repainting. An agent brief is the same. The constraints you set at launch will be wrong somewhere within weeks, because the agent will meet cases you didn’t anticipate. A brief that nobody owns and nobody revisits is a design that quietly stopped matching reality.

Who should help write the brief?

Sociotechnical design had one more commitment that deserves a second life: participation. The people affected by a work system help design it. Cherns put it bluntly: “a participative social system cannot be created by fiat.”

For agents, “the people affected” is a wider group than it first appears. It’s the people whose tasks the agent now performs, who know where the edge cases are. It’s the people who use the agent’s outputs and will live with its mistakes. It’s the people who oversee it and need to know what “normal” looks like. In most deployments I’ve seen discussed, the brief is written by whoever sets up the agent. That’s a single point of design in exactly the place that needs the most input.

What this means

We didn’t need to invent a new theory of how to instruct autonomous systems. We had one, written for people, and it transfers with one important change. Specify the what precisely and the how minimally, as Cherns said. But treat the unspecified space as the thing you’re governing. Decide who owns the constraints, how violations surface, and when the brief gets revisited.

The best agent instructions and the best work designs have something in common: they’re short, and every line in them earns its place. The difference is that for agents, the lines you leave out are a risk decision, whether or not anyone made it deliberately.

References