Everything Is Prompt Engineering

Shiyan Liu — Wed, 08 Apr 2026 23:10:30 +0000

Everything Is Prompt Engineering: A Formal Argument

Author's note: This post proposes a falsifiable thesis and attempts a rigorous proof. If you've shipped production AI systems, this won't teach you to write better prompts. It tries to answer a more fundamental question: what exactly are you doing when you build all of this? The final section responds directly to the strongest objections, including emergence theory, multimodal heterogeneity, and the dynamic-weight challenge.

0. The Thesis

Proposition P: Within the current Transformer-based large language model paradigm, all Workflow, Agent, MCP, Skill, Harness, and Context mechanisms are computationally equivalent to prompt engineering of varying complexity.

This sounds trivial. It isn't. "Equivalent" here doesn't mean "similar" or "analogous"—it means there exists a behavior-preserving reduction: any such mechanism can be fully expressed as a strategy for constructing the model's input token sequence, without loss of behavioral capability.

One distinction needs to be clarified upfront to prevent a common misreading:

Functional complexity ≠ ontological category.

This argument is ontological (what these mechanisms are), not prescriptive (how hard they are or how much they matter). Claiming everything is prompt engineering does not mean all prompt engineering is equally complex, nor that engineering abstractions lack value. This distinction is developed in §4 and §5.

1. Formal Foundations

1.1 The Computational Model

Let a language model be a function:

M : T* → Δ(T*)

where T* is the set of all token sequences and Δ(T*) is a probability distribution over them. M is a stateless, deterministic mapping (at temperature=0). It has no memory, no tools, no persona—unless that information is encoded in the input sequence.

This is a critical ontological claim: the model's complete "capability" at any moment is determined by, and only by, the token sequence it currently sees.

1.2 The Context Window as Complete State

For the model, the context window is its complete world state. In database terms: every call is a full read with no incremental state and no side effects. This means everything that looks like "state" must be materialized into the token sequence before the call.

1.3 Definition: Prompt Engineering

We define prompt engineering as:

Given target behavior B and model M, construct input sequence x ∈ T* such that M(x) produces output conforming to B with high probability.

Note: this definition places no constraints on the origin of x. It can be hand-written, programmatically generated, or produced by another model. The complexity of the construction strategy does not change its essential nature.

2. The Reductions

2.1 Skill: Versioned Prompt Fragment Management

A Skill is a predefined text (instructions, persona definition, format constraints) injected into the system prompt before a call.

Reduction: Let skill s be a text string. Any call using skill s—i.e., M(s ⊕ u) where u is user input and ⊕ is concatenation—is identical to manually writing s into the prompt. Skill systems add engineering management capability (version control, reuse, A/B testing). They add no computational capability.

Anticipated objection: "But Skills can contain dynamic variables." Correct. A Skill with dynamic variables is a prompt template. Its instantiation is Harness's job—see §2.3.

2.2 MCP (Model Context Protocol): Tool Schema Injection

MCP lets the model "know" that external tools exist. The mechanism: JSON Schema descriptions of tools are injected into context, enabling the model to generate structured tool-call requests.

Reduction: Let tool set T = {t₁, t₂, ..., tₙ} with schemas σᵢ per tool. MCP's core operation:

x_mcp = system_prompt ⊕ serialize({σ₁, σ₂, ..., σₙ}) ⊕ user_message

The model's "use" of a tool is the model generating text that conforms to σᵢ's format. The external harness parses this and executes.

Key corollary: Tools don't exist as real external capabilities from the model's perspective—they are declarations in the prompt. An undeclared tool is nonexistent to the model. This is why MCP tool description quality directly determines call accuracy: it's a prompt quality problem, not a tool implementation problem.

2.3 Harness / Context: The Materialization Engine

A Harness serializes dynamic information (database query results, user history, tool return values, external API data) into tokens and injects them into context.

Reduction: Let external state be S. The harness is a function:

H : S → T*

The final model call becomes M(H(S) ⊕ user_message). A harness can be arbitrarily complex—it can include RAG pipelines, database queries, formatting logic—but its output must be a token sequence. The engineering complexity of the harness doesn't change what it produces: a prompt.

Context management (truncation, summarization, compression of conversation history) is a sub-problem of Harness: how to represent world state with maximum information density within a finite context window. This is a prompt optimization problem.

2.4 Workflow: Orchestrated Serial Prompt Engineering

A Workflow chains multiple model calls, where each call's output becomes (part of) the next call's input.

Reduction: Let workflow W = (p₁, p₂, ..., pₙ). Execution:

o₁ = M(p₁(input))
o₂ = M(p₂(o₁))
...
oₙ = M(pₙ(oₙ₋₁))

The "orchestration capability" (conditional branching, parallel execution, retry logic) is entirely implemented in the harness layer. At each node, the model sees an ordinary prompt. Workflow frameworks add process management abstractions. They introduce no new computational primitives.

2.5 Agent: Self-Referential Context Construction

Agent is the most interesting case—it looks least like prompt engineering.

An agent's defining feature: the model decides in its output what information or operation it needs next, the harness executes and fills the result back into context, forming a loop.

Reduction: A single agent step:

action_t = M(system ⊕ history_t ⊕ available_tools)
result_t = execute(action_t)
history_{t+1} = history_t ⊕ action_t ⊕ result_t

The agent's "autonomy" manifests entirely as: which tool-call format the model chose to generate in its token output. This is a generation decision, not a control-flow decision independent of the prompt.

More pointedly: the agent's sense of goal and planning capacity come from the system prompt's description of objectives, constraints, and reasoning process. Change the system prompt, the agent's behavior changes fundamentally. This is the defining characteristic of prompt engineering: behavior is determined by the prompt, not by external control structures.

Anticipated objection: "But agents can modify their own prompts (memory, self-reflection)." This supports Proposition P. Self-modification of prompts is a prompt engineering strategy, not a counterexample. Whatever the agent writes to memory ultimately manifests as token changes in the next call's context. There's no escape.

3. The Unified Framework: The Context Builder Pattern

Based on these reductions, we can define a unified abstraction:

Any AI System = Context Builder × Model

Where Context Builder is a family of functions from world state to token sequence:

CB : (Intent × State × History × Tools × Skills) → T*

Component mapping:

Component	Role in CB	Core Question
Skill	Static Intent/Constraint injection	What behavior is desired?
MCP	Tools declaration serialization	What can the model do?
Harness	State materialization	What is the world's current state?
Context mgmt	History compression	Which past information is still relevant?
Workflow	Sequential composition of CB	How to decompose multi-step tasks?
Agent	Self-referential recursion of CB	Model selects next CB input

The framework's value: it converges all engineering complexity into one question—how to construct the optimal token sequence.

4. Corollaries and Practical Implications

4.1 Security: Prompt Injection Is the Fundamental Attack Surface

Since the model's only interface is the token sequence, any external input that can influence that sequence is a potential attack vector. Prompt injection isn't an implementation-layer vulnerability—it's a structural property of this computational model. Any solution claiming to "completely solve" prompt injection without architectural changes deserves skepticism.

4.2 Debugging: Most Bugs Are Context Bugs

Many behavioral anomalies in AI systems (tool-call errors, persona drift, instruction forgetting) reduce to: the model saw a context on some call that wasn't what you thought it was. The first debugging step is usually: print the complete context, inspect whether information was correctly materialized.

To be precise: this is not a determinist claim. Model weight limitations—hallucinations from training data distribution bias, capability ceilings on specific reasoning chains—are a orthogonal source of bugs, independent of context construction. Context quality and model capability are two separate dimensions; debugging requires locating which one is failing. Attributing every hallucination to context construction is the most common misuse of this framework.

4.3 Optimization: The Core Variable in Inference Cost Is Tokens

Latency optimization = fewer context tokens + fewer output tokens. Cost optimization follows. "Intelligent" context compression strategies (summarization, vector retrieval) are prompt engineering problems, regardless of their engineering packaging.

4.4 The Necessity of Abstraction Layers

Acknowledging that everything is prompt engineering doesn't mean abstraction is unnecessary. Here is a precise analogy: assembly language and high-level languages are equivalent at the Turing machine level, but radically different in productivity. Equivalence is an ontological claim, not an engineering recommendation.

Skill, Harness, and Workflow are necessary productivity tools. But conflating "engineering management tools" with "sources of computational capability" produces two common failure modes: framework worship (believing that switching agent frameworks can fix prompt quality problems), and capability miscounting (believing that adding workflow orchestration grants the model reasoning abilities it doesn't have).

5. Responding to the Strongest Objections

Here are the most compelling objections to this thesis, and why they don't overturn Proposition P—or, precisely where they do constitute grounds for revision.

5.1 "The Reductionist Fallacy": Don't Emergent Behaviors Create Something New?

Objection: Reducing everything to token sequences is naive reductionism. Workflow and Agent introduce closed-loop feedback and multi-step reasoning, producing emergent behaviors that a single prompt cannot achieve. Calling this "prompt engineering" erases the intelligence that structure itself creates.

Response: This objection conflates two fundamentally different kinds of "emergence."

Physical emergence (e.g., consciousness arising from neurons) invalidates reductionism because we cannot predict the whole from the parts—the emergence is unpredictable and irreducible. This kind of emergence genuinely escapes reductionist explanation.

But the "emergent behaviors" of Workflow belong to a completely different category: given a fixed set of prompts and a fixed execution order, the system's behavior is fully predictable and fully reducible. A multi-step agent's output can be precisely explained by unrolling each step's prompt and model output. There is no behavior that can "only be described at the system level"—every step corresponds to a specific token sequence.

True emergence is undebuggable; "emergence" that can be traced and decomposed is, in essence, composition of finite-state machines—not a new computational paradigm.

Furthermore, the "temporal extension of the computation graph" argument actually supports Proposition P: at every time step, this extension manifests as a complete prompt→response cycle. The temporal structure is implemented by the harness, not the model.

5.2 "Multimodal Heterogeneity": Are Audio and Video Streams Still Prompts?

Objection: As native multimodal models proliferate, models increasingly process audio streams, video streams, and binary tokens. Calling these high-dimensional inputs "prompt engineering" inflates the definition until it loses all practical meaning. If everything is a prompt, prompt means nothing.

Response: This objection identifies a real boundary of Proposition P and deserves to be taken seriously. Two cases need to be distinguished.

Case 1: Audio/video is encoded via a tokenizer and sent to the model (as in most current multimodal implementations). Proposition P holds fully—the input is still a token sequence, just with tokens sourced from multimodal signals rather than text. Constructing "which modalities to send, in what order" is still prompt engineering; the operation space has expanded from text to multimodal, but the structure is the same.

Case 2: The model processes continuous signals end-to-end (e.g., a voice model where both input and output are audio waveforms). Here, the "token sequence" framework no longer applies, and Proposition P requires revision: prompt engineering needs to be generalized to "input signal engineering." But this is an extension of Proposition P's boundary, not a negation—the underlying logic is unchanged: model behavior is fully determined by its input, and constructing the input is the only lever for obtaining desired output.

On the concern about "definition inflation": this concern is valid in engineering practice but irrelevant at the ontological level. Physicists saying "everything is an excitation of quantum fields" doesn't make that statement meaningless—it's a precise ontological claim, not an operational checklist. Proposition P's value is in revealing a unified underlying mechanism, not in providing operational guidance.

5.3 "Engineering as Qualitative Change": Isn't High-Level Code More Powerful Than Assembly?

Objection: Harness and Memory mechanisms change the "effective lifespan" of an LLM, enabling Agents with long-term memory to exhibit robustness that no static prompt can match. This is engineering structure empowering intelligence—a qualitative change. Just as high-level languages and assembly are Turing-equivalent but productively different.

Response: This analogy supports Proposition P rather than refuting it.

The equivalence of high-level and assembly languages is precisely the content of Turing completeness: any high-level program can be compiled to equivalent assembly without loss of computational capability. This is an ontological equivalence. Proposition P is making the same claim: Workflow/Agent/Harness are computationally equivalent to prompt engineering, with enormous differences in engineering productivity. The objector is presenting "engineering productivity differences" as evidence of "ontological category differences"—a category error in the argument.

An agent's "robustness" comes from better context construction strategy—long-term memory means each call's prompt contains more relevant historical information—not from a new computational mechanism. Robustness is a function of prompt quality; frameworks are productivity tools for achieving prompt quality.

5.4 "Dynamic Weights": What If an Agent Fine-Tunes Its Own Weights at Runtime?

Objection: Dynamic LoRA adapter loading and the trend of In-context Learning evolving toward weight updates are blurring the line between "what is a prompt" and "what is a model." If an agent modifies its own weights in real time, does that still count as prompt engineering?

Response: This is the most substantive challenge to Proposition P and requires careful case analysis.

Current practice—LoRA dynamic loading: Switching adapters at inference time doesn't change the inference process itself—each call is still a fixed-weight mapping over a token sequence, with the weight set switching between calls. Proposition P still holds; adapter selection can be understood as the harness's responsibility, and the selection logic can be encoded as meta-prompts.

The radical case—real-time gradient updates at inference: If an agent modifies its weights via gradient updates within a single session, this genuinely exceeds Proposition P's framework. Behavior is no longer determined solely by the token sequence; the weights themselves are evolving. In this case, Proposition P needs to be revised to:

Proposition P': In the fixed-weight inference paradigm, all orchestration mechanisms are equivalent to prompt engineering. In a dynamic-weight evolutionary paradigm, prompt engineering and weight engineering constitute orthogonal dimensions that jointly determine system behavior.

This is a boundary refinement of Proposition P, not a negation. The overwhelming majority of current production systems remain in the fixed-weight inference paradigm; Proposition P applies to them fully.

6. Precise Boundary Conditions

Based on the preceding analysis, Proposition P's scope can be precisely defined as four conditions:

Condition A (Modality): The model's input/output maps through a tokenizer to a discrete token space. For end-to-end continuous-signal models, Proposition P generalizes to "input signal engineering"; underlying logic unchanged.

Condition B (Weights): Weights are fixed during inference (including static LoRA adapter loading). For systems with dynamic weight evolution at runtime, "weight engineering" must be introduced as an orthogonal dimension (see Proposition P').

Condition C (System): Single-model or explicitly-routed multi-model systems. For implicit mixture-of-experts systems, internal routing constitutes control structure beyond the prompt—but from the external API caller's perspective, behavior is still fully determined by the input sequence, so Proposition P holds at the API layer.

Condition D (Exclusion): Fine-tuning is out of scope because it modifies M itself rather than M's input. That said, fine-tuning's effects are still modulated by inference-time prompts—the two are orthogonal but coupled dimensions.

7. Conclusion

Workflow, Agent, MCP, Skill, Harness—these concepts represent real growth in engineering complexity and deserve to be taken seriously. But they are not a new paradigm independent of prompt engineering; they are prompt engineering operationalized at different complexity levels.

Examination of the strongest objections shows: the emergence argument conflates unpredictable emergence with debuggable composition; the multimodal challenge identifies a real boundary without negating the core logic; the engineering-as-qualitative-change argument's best analogy supports Proposition P; dynamic weights are a genuine boundary case, addressed in Condition B and refined as Proposition P'.

Understanding Proposition P's practical value is not about simplifying problems—it's about locating problems correctly. It gives you an accurate map:

When debugging: Check context construction first, then investigate model capability limits. Don't conflate two orthogonal bug sources.
When evaluating frameworks: Separate engineering productivity value (real and important) from computational capability claims (requiring proof).
When encountering new concepts: Quickly determine which dimension of the Context Builder it occupies, or whether it genuinely exceeds conditions A/B/C/D.

To locate the precise level of this argument, one final metaphor: the fuse and the explosive both matter. But understanding that "a fuse is fundamentally a controlled combustion process"—this ontological insight—doesn't lead any engineer to neglect the arrangement of the explosive. It just ensures that when you're debugging, you don't misdiagnose the explosive's problem as the fuse's problem, or vice versa.

You are not building an "AI system." You are building a context construction engine whose output happens to be the input of a language model. The value of this insight is not that it makes things simpler—it's that it lets you classify problems correctly.

If you have a counterargument, identify which of Conditions A/B/C/D fails, or locate a logical gap in one of the reductions. This framework invites falsification—that is the basic posture of a serious thesis.

DEV Community: Shiyan Liu