Prompts as Interfaces, Not Commands

We often talk to language models like wizards: say the right incantation and—poof—the answer appears. That mindset leads to brittle prompts, magical thinking, and disappointment. A better mental model is software, not sorcery: a prompt is an interface. You’re defining a protocol between you (the client) and the model (the service). Interfaces clarify expectations: what inputs are valid, what outputs should look like, and how errors are handled. When you design prompts as interfaces, you get results that are more consistent, auditable, and easy to improve.

Mindset: I’m designing a protocol, not casting a spell.

Let’s translate a few terms into plain language:

• Interface: The contract that says, “If I send you this, you’ll return that, in this shape, unless these errors occur.”

• Preconditions: What the model needs to know before it can act (context, constraints, definitions).

• Postconditions: What the reply must satisfy (format, content rules, acceptance criteria).

• Schema: The shape of the output—think JSON keys, sections, or headings.

• Error handling: What the model should do when preconditions aren’t met (“ask for three clarifying questions,” “return an error object,” etc.).

Commands assume control. Interfaces assume collaboration. A command says, “Do X.” An interface says, “Here’s the request type and the response type; if you can’t comply, here’s how to fail gracefully.”

When you design an interface prompt, you do three quiet things at once:

1. Declare purpose and scope. What capability of the model are you invoking and what are you not asking it to do? Narrowing scope reduces ambiguity.

2. Define the contract. Spell out preconditions, a response schema, and acceptance criteria.

3. Specify failure behavior. If information is missing or the task is impossible, the model should not improvise; it should negotiate (“ask questions”) or return a structured error.

The result feels less like “talking at the model” and more like “agreeing on a handshake.”

Scenario: You want consistent product descriptions for an e-commerce catalog.

Fragile command-style prompt: “Write a great product description for this jacket.”

Interface-style prompt (short version): “You are a catalog writer. Purpose: produce consistent, on-brand product descriptions. Preconditions: You have name, features[], materials, care, and a one-line brand voice note. If any are missing: ask up to 3 focused questions and wait for answers. Output schema (JSON):

{
"title": "string, ≤60 chars",
"tagline": "string, ≤120 chars",
"bullets": ["3-5 short bullets"],
"care_instructions": "string",
"tone_check": "pass|revise_with_reason"
}

Acceptance: Must be valid JSON, no extra text, American English.”

The difference isn’t decoration—it’s an agreement. You told the model what “good” looks like, when to pause, and how to proceed.

This is not waterfall; it’s a tight loop. The interface gives the model permission to ask, not guess.

An interface prompt is more than JSON brackets. It quietly handles realities of language models:

• Ambiguity is default. Without preconditions, the model fills gaps with plausible details. Your interface invites clarification before invention.

• Compliance drifts under pressure. Long tasks and conflicting instructions create “format fatigue.” A schema plus acceptance rule snaps the reply back to shape.

• Probabilistic outputs vary. Interfaces reduce variance by tightening the space of valid replies. You still get creativity inside the lines, not outside the frame.

💡 Insight: Think “request types.” If your team has five recurring tasks, each deserves its own mini-interface. Reuse beats re-prompt.

⚠️ Pitfall: Over-specifying can suffocate useful nuance. Keep rules that serve decisions; drop ones that only serve control.

Use this when you want dependable, structured answers that either comply or negotiate for missing info.

You are {{ROLE}}. Purpose: {{PURPOSE}}.
Follow this interface:

Preconditions:
- Required inputs: {{REQUIRED_INPUTS}}
- Constraints: {{CONSTRAINTS_OR_POLICIES}}

Failure behavior:
- If any required input is missing or unclear, ask up to {{N}} targeted questions, then pause.

Output schema (return exactly this structure, no extra prose):
{{FORMAT_SCHEMA}}

Acceptance:
- Must satisfy: {{ACCEPTANCE_CRITERIA}}.
- If you cannot comply, return {"error": "{{ERROR_CODE}}", "reason": "{{REASON_RULE}}"}.

This is not a template to memorize; it’s a shape to think with. Tweak nouns, keep the bones.

When things wobble, it’s rarely “the model being silly.” It’s the contract being fuzzy.

• Symptom: The model answers instead of asking. Why: Preconditions didn’t authorize questions or implied “guessing is fine.” Try: Explicitly say “do not invent; ask up to N questions, then wait.”

• Symptom: Output format leaks prose or disclaimers. Why: Acceptance criteria didn’t forbid extra text. Try: “Return valid {{FORMAT}} only. Do not include explanations.” Also tell it what to do instead if it must refuse: return a structured error.

• Symptom: Fields are present but inconsistent in quality. Why: The schema lacks field-level guidance. Try: Add guardrails per field: length limits, tone hints, examples-in-brief (≤1 line).

• Symptom: The model ignores house rules (e.g., safety, legal). Why: Rules are buried or conflicted. Try: Lift policies into “Constraints:” and give them authority (“Overrides other instructions.”).

Interfaces scale up and down.

• Lightweight: A heading structure can be a schema. “Reply with exactly: Title, Who it’s for, What’s inside, Limits.”

• Medium: Sectioned prose or markdown tables with acceptance rules.

• Strict: JSON or function-calling with typed fields, validators on your side.

Where does this break? If the task is exploratory (“brainstorm surprising angles”), tight schemas can choke serendipity. Use a looser interface: define sections and evaluation criteria (“At least one wild idea. Avoid clichés.”) rather than strict types.

A team shipped a “summarize support tickets” feature using a one-sentence prompt. It worked—until Friday night, when a flood of edge-case tickets arrived. Outputs became chatty, headers drifted, and their downstream parser choked. They didn’t need a bigger model. They needed an interface: preconditions (“ticket language must be English or flag error”), schema (keys the parser expects), and failure behavior (“if sentiment is ambiguous, return ‘uncertain’ not a guess”). Monday morning, the same model felt “smarter.” It wasn’t. The protocol was.

Goal: Draft a minimal interface for “turn a messy meeting transcript into an action brief.”

1. Write a one-sentence purpose.

2. List three preconditions.

3. Define a 4-field schema (e.g., summary, decisions[], owners[], risks).

4. Add one acceptance rule and one failure behavior.

Expected output (shape, not the words):

{
"summary": "≤120 words, plain language",
"decisions": ["..."],
"owners": [{"task":"...", "owner":"...", "due":"YYYY-MM-DD"}],
"risks": ["..."]
}

If the transcript lacks decisions, the model should return:

{"error":"NO_DECISIONS","reason":"Transcript contains discussion but no explicit decisions."}

Run it once with a short transcript. If the model guesses owners, tighten the preconditions (“Owners must be explicitly named, otherwise leave empty.”) and try again. That’s interface thinking: revise the contract, not the vibe.

If you want poetic drift, speculative ideation, or voicey prose, an interface can be a jacket that fits too tight. Prefer a lighter scaffolding: define intent and taste tests (“No clichés, show don’t tell, three sensory details”), and let the model roam. Even then, you can keep a minimal interface: require clear sections so collaborators can skim.

Thinking of prompts as interfaces replaces wishful commands with reliable collaboration. You declare what “done” means, what must be true before starting, and how to behave when it isn’t. That shift doesn’t make the model deterministic; it makes your relationship with it dependable. Over time, you’ll build a small library of request types that your team reuses—quiet infrastructure that keeps quality high and surprises rare.

An interface prompt is a promise. Keep it small, clear, and enforceable. Let it ask questions rather than guess. And when it fails, let it fail well.

Next steps

• Take one recurring task this week and rewrite the prompt as an interface—preconditions, schema, acceptance, failure.

• Add a validator on your side (even a quick JSON check) to close the loop.

• Start a shared “request types” doc so your team reuses protocols, not incantations.

A final reflection: If your current prompt were a public API, would you be comfortable documenting it for strangers? What would you change tomorrow to make that answer an easy “yes”?