Prompting is too small

A prompt is an instruction. A specification is an operating contract.

The prompt says, "write this" or "analyze that." The specification says what good means, what evidence matters, what constraints apply, what must not happen, how the output will be evaluated, and when the worker should stop instead of improvising.

That distinction matters because agents are very good at completing the literal task and missing the actual job.

The individual operator's job is not to become clever at phrasing prompts. It is to define work precisely enough that execution can be delegated without surrendering judgment.

The source-backed brief

A good agent brief has more in common with an SOP, PRD, or operating memo than with a chat message. It gives the worker a target state and the boundaries around that target.

Use this structure:

  • Outcome: What should be true when the work is done?
  • Source base: Which files, notes, links, tickets, customer quotes, logs, or decisions must ground the work?
  • Current state: What is already known? What has already been tried?
  • Non-goals: What should the worker avoid, even if it seems adjacent?
  • Constraints: Style, format, privacy, budget, architecture, stakeholder, deadline, or reversibility limits.
  • Acceptance tests: What concrete checks decide whether the work is good enough?
  • Escalation rules: When should the worker stop and ask rather than guess?
  • Final report: What changed, what evidence was used, what remains uncertain, and what decision is needed?

This is the practical meaning of "intent-based" work. The operator defines the ideal state clearly enough that execution can optimize against something more durable than vibes.

Acceptance tests beat adjectives

Weak specifications use adjectives: clear, polished, useful, strategic, concise.

Operator specifications use tests:

  • cites the three source notes used;
  • identifies any claim that lacks evidence;
  • preserves the existing frontmatter;
  • does not rename files;
  • flags irreversible or external actions before taking them;
  • returns changed files and blockers;
  • includes one explicit next step;
  • rejects duplicate ideas rather than rephrasing them.

The more consequential the work, the more the brief should define verification before generation starts.

The failure mode

Vague prompts create plausible output and hidden debt. The agent may produce something that looks complete while quietly changing the scope, inventing certainty, flattening nuance, or skipping the boring constraint that mattered most.

Then the operator pays the review cost late, usually under deadline pressure.

That is not an agent failure. It is a specification failure.

Brief review checklist

Before launching an agent, check the brief:

  • Can the worker tell what success looks like without reading my mind?
  • Are the authoritative sources linked directly?
  • Are forbidden actions explicit?
  • Are ambiguity and escalation rules defined?
  • Is the expected artifact named?
  • Is the review burden proportional to the risk?

Prompting asks, "what should I tell the model?" Specifying asks, "what work system am I creating?" Senior ICs should care much more about the second question.