Prompt Anatomy and the Operator-User Distinction

AITM-PEW: Prompt Engineering Associate — Body of Knowledge Article 1 of 10

A practitioner who approaches prompt engineering as a writing craft will build prompts that work on a Tuesday and fail on a Thursday. A practitioner who approaches it as a configuration-management discipline will build prompts that survive model upgrades, adversarial probing, regulatory scrutiny, and the ordinary erosion that afflicts every production system. The difference between the two is not talent. It is whether the practitioner has internalised that a prompt is not a string of characters the team happens to pass to a model at runtime. A prompt is a set of interacting components, each with a different author, a different trust level, a different governance owner, and a different failure mode. This article defines those components and the distinctions a practitioner must learn to hold between them.

What counts as the prompt

In casual usage, the word prompt means whatever the user types. In production systems, it means something quite different. By the time a request reaches a managed API or a self-hosted model, the request typically contains five distinct payloads stitched together into a single message sequence: a system instruction authored by the operator; a set of few-shot examples also authored by the operator; a retrieval context fetched from a knowledge source; a user turn captured from the end user; and a tool schema describing the functions the model is authorised to invoke. A sixth component, conversation history, carries prior turns forward when the feature is conversational.

Every major provider documents this structure explicitly. OpenAI’s platform guide describes system messages, user messages, and tool definitions as distinct message types sharing a conversation¹. Anthropic’s prompting guide uses the same vocabulary, with a dedicated system field separate from the messages array². Google’s Gemini documentation carries the same distinction under the terms system instruction and contents³. Open-weight providers that expose chat completion endpoints follow the same convention because the pattern is now a de facto standard. A self-hosted Llama deployment, a Mistral endpoint, and a Qwen service all expose the same logical decomposition.

The consequence is that when a practitioner says the prompt, they must specify which component. A bug in the system instruction is a different kind of bug than a bug in a retrieved document. A correct answer produced by the wrong layer is a correctness failure waiting to happen. Governance cannot attach to an undifferentiated blob; it attaches to components.

[DIAGRAM: ConcentricRings — aitm-pew-article-1-prompt-anatomy — Concentric rings: model at the centre, then system prompt, few-shot examples, retrieval context, tool schemas, user input.]

The operator-user distinction

The single most important distinction in prompt engineering is between content the operator authored and content the user authored. The operator is the organisation deploying the feature. Its employees write the system prompt, select few-shot examples, define the tool schemas, and configure the retrieval pipeline. The user is the person or upstream process that consumes the feature. Its content arrives as free input and can contain anything.

Operator content is, in principle, trusted. It ships through code review, it is versioned, it is tested, and it is logged to a registry. The organisation can reason about what it says because the organisation wrote it. User content is, in principle, untrusted. The user can be a loyal employee, a curious prospect, an adversarial red-teamer, or an automated script scraping the feature for a competitor. A production prompt engineer therefore treats user content as Paul Vixie once described email payload: possibly malicious, possibly malformed, possibly non-conforming, and always to be validated before use.

This is the point at which regulation, security, and engineering converge. The European Union’s AI Act, Article 50, requires that users be informed when they interact with an AI system⁴. That duty attaches to the operator, not to the user. The OWASP Top 10 for Large Language Model Applications lists prompt injection as LLM01 precisely because it is the attack in which user content attempts to override operator content⁵. ISO/IEC 42001 Clause 7.5, documented information, requires the organisation to maintain evidence of the controls it has placed on its AI systems⁶; that evidence is almost entirely operator-side. Every major governance duty lives on the operator side of the distinction.

A feature that blurs the boundary accepts risk it cannot see. The clearest public illustration is the Bing Chat incident of February 2023, in which extended dialogue with the product produced outputs quoting what appeared to be Bing’s internal system prompt under the persona name Sydney. The New York Times published a transcript⁷, and the concatenated prompt structure became a widely discussed example of how a production system prompt can surface to users under adversarial conditions. Microsoft responded by limiting turn count per conversation and tightening filters, but the structural lesson was architectural: the operator-authored layer had been leaking into the user-facing output because the containment between layers was not strong enough.

The five operator-authored components

A practitioner should be able to enumerate, for any prompt-driven feature, what inhabits each operator-authored slot. A system instruction is a short block of prose that establishes role, tone, scope, refusal behaviour, citation requirements, and handling of out-of-scope questions. A single well-written system instruction is typically three hundred to eight hundred words. Much shorter and it under-specifies; much longer and it dilutes.

Few-shot examples demonstrate the desired input-output behaviour by showing it. When the target behaviour is easy to specify in prose, examples are optional; when it is nuanced (a particular JSON shape, a particular style of refusal, a particular way of handling edge inputs), a handful of examples outperforms a paragraph of description. The foundational paper on in-context learning is Brown et al. 2020⁸, which established that language models can adapt their behaviour from examples without weight updates. That paper is the theoretical grounding for every few-shot pattern in production today.

Retrieval context is content fetched at request time from a knowledge source and inserted into the prompt. The retrieval pipeline is typically a vector search over chunked documents, augmented with keyword reranking and deduplication. The retrieval context is operator-authored in the sense that the operator controls what is indexable and what the retrieval chain returns, but it is also the layer at which indirect prompt injection becomes possible: if a document in the index was written by an adversary, its content reaches the model inside an operator-authored slot.

Tool schemas are the JSON or typed definitions of the functions the model is authorised to call. Each schema describes the name, description, parameters, and required fields of a tool. The OpenAI function calling API⁹ and Anthropic’s tool use API¹⁰ share a common shape because the pattern has converged. A tool schema is operator-authored configuration and is reviewed exactly as carefully as any other code that mediates between a language model and an action on the world.

Conversation history, the fifth component, is a hybrid. It contains both operator-authored turns (prior assistant messages) and user-authored turns (prior user messages). A practitioner who treats it as uniformly trusted will miss that a user message from three turns ago, if echoed back into the prompt, carries the same risks as a fresh user message.

From text-first to configuration-first

A prompt engineer working alone on a prototype can hold all of this in their head. A prompt engineer working in production cannot. The shift from text-first prompting to configuration-first prompting is the shift from treating a prompt as text you paste into a notebook to treating it as a versioned artefact with an owner, a change log, a test suite, and a deployment lifecycle. Every later article in this credential depends on that shift having happened.

[DIAGRAM: Bridge — aitm-pew-article-1-text-to-configuration — Left side: ad hoc text prompt in a notebook; right side: versioned prompt template with schema, owner, tests, registry entry; bridge beams label the transitions.]

Configuration-first prompting has concrete consequences. The system instruction goes into a file, not into a cell. That file carries a header with the prompt’s identifier, version, owner, model binding, retrieval binding, guardrail binding, and change date. Changes to the file go through code review. A test harness exercises the prompt against a suite of cases before any change reaches production. The deployment path includes a canary phase in which the new prompt runs against a small fraction of traffic before rollout. A registry tracks which prompts are live, on which models, with which retrieval sources. Article 9 of this credential develops this lifecycle in depth.

A worked example: a policy question assistant

Consider an internal HR policy assistant. The operator-authored components might be: a system instruction stating that the assistant answers only HR policy questions, quotes the relevant clause, refuses when the retrieved context is absent, and escalates to a human on ambiguity; three few-shot examples showing the desired answer-with-citation format; a retrieval pipeline over the organisation’s policy corpus; and a single tool schema for escalate_to_human that accepts a reason string and a conversation reference. The user-authored component is the question. Conversation history accumulates across turns.

A practitioner who has decomposed the prompt this way can already list the governance questions that must be answered before the assistant goes live. Who owns the system instruction? What is its version today, and what was its version last week? Which examples are in the few-shot set, and what do they demonstrate about edge-case handling? What documents are indexed for retrieval, who can add to that index, and under what review? What does the escalate_to_human tool do when invoked, who receives the escalation, and what is its SLA? When a user turn arrives, what classification is run on it before it reaches the model? The answers define the governance surface. A prompt engineering associate is the person who asks them.

Multimodal and emerging payload types

The five-component decomposition generalises cleanly to multimodal inputs. When a user uploads an image alongside a question, the image joins the user-authored side of the prompt and carries the same trust profile as user text. A chart extracted from a PDF the user supplied can contain text that functions as instructions; this is the indirect-injection risk surface for vision-enabled features. Audio inputs transcribed into the prompt carry the same concern. The practitioner’s discipline does not change: operator content is trusted by construction; user content is not; the boundaries must remain legible to the model through layering and delimiters.

Emerging payload types extend but do not overturn the taxonomy. A structured memory component, inserted by an agentic runtime summarising prior sessions, is operator-authored in origin but carries content partially derived from past user turns. A practitioner treats it as semi-trusted and applies the same scrutiny a retrieval chunk receives. A tool-response payload, returned from a function call and inserted into the conversation, is similarly semi-trusted; its structural origin is the operator-controlled tool implementation, but its content is often derived from external systems the operator does not fully control. Each of these hybrids calls for a named trust classification in the prompt design rather than being swept into a uniform treatment.

Governance handoffs the decomposition enables

The operator-user distinction also clarifies organisational handoffs. The system instruction’s content is typically a joint product of a prompt engineer and a product or policy owner; the few-shot set is often curated by a content designer or legal reviewer; the retrieval pipeline is owned by a platform or data engineering team; the tool schemas are owned by the engineering team that built the downstream functions. A feature that treats the prompt as one undifferentiated artefact produces an unclear ownership chain; a feature that treats each component as a first-class artefact routes each to its natural owner. The ISO 42001 Clause 5.3 requirement that roles, responsibilities, and authorities be assigned for the AI management system¹¹ becomes tractable only when the artefacts are decomposed enough to hand to different owners.

The practitioner’s role in this organisational structure is not to own every component. It is to know which components exist, which owners hold them, and how they compose into the live prompt. The moment a feature misbehaves, the decomposition is the tool that localises the failure to the component responsible, and therefore to the owner who must act.

A second organisational benefit is that new team members onboard faster. Asking a new engineer to understand the prompt as a monolith produces a slow ramp; asking them to read the system instruction, the few-shot set, the retrieval configuration, and the tool schemas in sequence, each a self-contained artefact, produces a predictable path to competence. The decomposition is a teaching tool as well as a governance tool.

Summary

A prompt is a composition of operator-authored and user-authored components. Operator content includes the system instruction, few-shot examples, retrieval context, tool schemas, and prior assistant turns. User content includes the current user turn and prior user turns. Every governance duty of consequence attaches to the operator side. The shift from text-first to configuration-first prompting is the precondition for every later capability this credential teaches. Article 2 develops the foundational prompting patterns, Article 3 develops output structuring, and every subsequent article extends the operator-authored layer with additional discipline.

Further reading in the Core Stream: Generative AI and Large Language Models and Introduction to the COMPEL Framework.

© FlowRidge.io — COMPEL AI Transformation Methodology. All rights reserved.