CONCEPT Cited by 2 sources

Prompt is not control¶

Definition¶

Prompt is not control is the architectural principle that fine-grained control over agent behaviour cannot be achieved via prompt instructions alone. Prompts are guidelines that shape the model's distribution over outputs, not deterministic control levers. When architects need fine-grained control — sequence of steps, termination conditions, invariant enforcement, per-step output schemas — control belongs in application code (per-task invocations, structured output schemas, state machines, orchestration graphs), not in system- prompt bullet points.

Named and canonicalised verbatim by Slack's Security Engineering team in their Streamlining security investigations with agents post (Source: sources/2025-12-01-slack-streamlining-security-investigations-with-agents).

Canonical statement¶

"We spent some time trying to refine our prompt, stressing the need to question assumptions, to verify data from multiple sources, and to make use of the complete set of data sources. While we did have some success with this approach, ultimately prompts are just guidelines; they're not an effective method for achieving fine-grained control."

(Source: sources/2025-12-01-slack-streamlining-security-investigations-with-agents)

Symptoms that you've been using prompt as control¶

The prompt is large and keeps growing. Each new failure mode adds a bullet ("always double-check X", "never skip Y") and the system prompt creeps toward the context window's upper bound.
Behaviour is non-deterministic for the same input. Two runs of the same investigation / question / task produce different sequences of steps. Sometimes the model follows instruction N; sometimes it skips to N+2.
Failures trace to "the model didn't do X" despite X being in the prompt. "Please always verify with source Y" is in the prompt and the model still skips the verification in 15% of runs.
Prompt tuning is whack-a-mole. Fixing one failure mode surfaces another, often in a previously-working area.
No way to enforce invariants. "Always emit a JSON object with fields A, B, C" is encoded as English; the model sometimes emits A, B, Z, or emits valid JSON with a hallucinated D.

All of these are signatures of control-in-prompt.

Slack's architectural response (the positive form)¶

When Slack hit this wall with their prototype — a 300-word system prompt trying to enforce a multi-step investigation methodology — they moved control out of the prompt into application state across three load-bearing mechanisms:

1. One model invocation per task¶

The complex investigation prompt was decomposed into a sequence of separate model invocations, each with a single well-defined purpose and output structure. The application, not the prompt, owns sequencing and state propagation. See patterns/one-model-invocation-per-task.

2. Structured output per task¶

Each task gets its own JSON-schema-constrained output, not a free-form text response. Schemas enforce shape at invocation boundaries; downstream code can depend on fields being present. "Using structured outputs isn't 'free'; if the output format is too complicated for the model, the execution can fail," Slack notes — but the trade is worth it for per-step control. See concepts/structured-output-reliability.

3. Application-state phase machine¶

Control-flow (discovery → trace → conclude) becomes an explicit application-managed state machine, not a narrative in the prompt. Transition decisions are their own model invocations. See concepts/investigation-phase-progression and patterns/phase-gated-investigation-progression.

The principle generalises¶

The principle applies beyond multi-agent security investigations:

Don't put ordering logic in the prompt. If step A must precede step B, run two invocations with A's output feeding B's prompt, not one invocation whose prompt says "first do A, then do B".
Don't put termination logic in the prompt. "Stop when sufficient information has been gathered" is vague; make termination a separate decision step with a structured output.
Don't put invariants in the prompt. "Always include field X" is a suggestion; JSON schema enforcement is a contract.
Don't put safety-critical control in the prompt. Content- filtering, permission checks, rate limits live in code, not in "please don't do dangerous things" bullets.
Don't put persona-switching in the prompt. "Answer as the Director in phase 1, the Critic in phase 2" is a hallucination hazard. Use separate invocations per persona.

Where prompts are still the right tool¶

The principle is not "prompts don't matter" — prompts remain the right place for:

Role / persona definition — who the agent is, what its tone is, what it's allowed to refuse.
Domain context — what system it's part of, what terminology to use, what the data sources look like.
Task-local guidance — for the single task at this invocation, how to interpret the input and what the ideal output shape is.
Examples / few-shot demonstrations — concrete examples of expected behaviour.

Prompts shape the model's distribution over outputs for a single task. They are exactly the wrong tool for enforcing multi-step control flow across tasks.

Contrasts¶

vs. concepts/context-engineering — context engineering is about what information you feed the model; prompt-is-not-control is about what decisions you let the model make based on that information. They compose: context-engineering fills the prompt well; application code uses the output to drive control.
vs. ReAct-style single-loop agents — ReAct loops (think-act-observe in a single prompt) intentionally put control in the prompt. The prompt-is-not-control principle says "this works for simple tasks; for complex ones, pull control out."
vs. tool-using chatbots — a chatbot tool-calling loop can get away with prompt-as-control when the task is short and failures are self-recoverable by the user. Production long-running pipelines can't.

Why this is a discipline, not a technique¶

The principle is easy to articulate and hard to follow because prompts are the most tactile surface of LLM work. When behaviour is wrong, the first instinct is "adjust the prompt". The discipline is recognising that once prompt- tuning stops producing monotonic quality gains, the root cause has shifted from "I haven't phrased the instruction well" to "I'm using the wrong mechanism to enforce this instruction." At that point, the right move is structural, not textual.

Caveats¶

Newer models shift the line. Larger, more capable models can follow longer multi-step instructions reliably. The point at which prompt-as-control fails moves with model capability; today's prompt-is-not-control task may be tomorrow's prompt-as-control task. But the principle still applies to the reliability tier below the current frontier — agents running on production-cost-tier models will always be closer to the failure boundary.
Structured output is not free. Slack notes structured outputs can fail if the schema is too complex, and are still subject to "cheating and hallucination." Moving control to structured output does not eliminate the problem; it makes failures orchestration-boundary failures (parseable but wrong content) rather than free-text failures.
The app has to be somewhere. Moving control out of prompts into application code means you now own more application code — state machines, schema validation, orchestration logic, retry policy. Teams need the engineering surface to absorb it.

Seen in¶

systems/slack-spear — canonical first wiki instance. The 300-word single-prompt prototype produced wildly variable quality; Slack's rewrite moved control out of the prompt into per-task structured-output invocations, an application-state phase machine, and the Director-Expert- Critic agent split. (Source: sources/2025-12-01-slack-streamlining-security-investigations-with-agents) Second post extends the principle to context state — context-management control doesn't go in prompts either. Rather than asking the prompt to "remember what we decided last round" or "track the investigation progress," Slack moves state into typed artifacts (Journal, Review, Timeline) produced by explicit model invocations with their own schemas. No message-history carry-forward; all inter-round continuity is through these artifacts. This extends prompt-is-not-control from "control flow doesn't belong in prompts" to "persistent state doesn't belong in prompts either." (Source: sources/2026-04-13-slack-managing-context-in-long-run-agentic-applications)