Source-linked AI summary
What makes prompts a graph: necessary and sufficient conditions for prompt graph engineering
Sandeco Macedo
TL;DR
Modern language-model applications are graphs rather than isolated prompts, but the field lacks a precise definition of prompt graph engineering. The paper develops four necessary and sufficient conditions and applies them across six systems, finding that the test consistently distinguishes included, excluded, and partial cases.
Problem
The field lacks a reference definition specifying when prompts constitute an explicit, executable graph rather than a string, reasoning topology, agent conversation, or orchestration artifact.
Method
The paper reconstructs the concept’s genealogy, formulates four constitutive conditions, and operationalizes them as an inclusion-and-exclusion test.
Results
Applied to six systems, the test includes graph-first frameworks, distinguishes AutoGen by operating mode, and excludes emergent delegation without a first-class graph artifact.
Takeaways & Limitations
The definition supplies shared vocabulary for inspecting, reusing, executing, and optimizing prompt graphs while identifying empirical questions about structural quality and value.
Takeaways & Limitations
The classification was performed by a single analyst, without replication or inter-rater agreement, and its six-system sample may not generalize to other system types.
Abstract
from arXiv · showhide
Prompts stopped being isolated strings some time ago. In real systems, one model call feeds another, retrieval interleaves with generation, routers branch, and aggregators merge parallel results. Practice converged on a single structure to hold this together: the graph. Frameworks such as LangGraph, DSPy, and Prompt Flow expose it openly, and research systems already optimize it automatically. The vocabulary, however, lags behind. Graph names, variously, a reasoning topology inside one sampling strategy, a multi-agent conversation, or an orchestration artifact, while prompt engineering still evokes writing one good string. What is missing is a reference definition treating prompts as nodes of an explicit, executable, improvable graph. We build that definition through conceptual analysis over sources with persistent identifiers, complemented by primary grey literature. We reconstruct the genealogy of the idea, from dataflow graphs and build systems, through prompt chaining and the thought topologies (chain, tree, graph), to graphs compiled and optimized as artifacts. We then propose a constitutive definition of prompt graph engineering, state its four conditions (explicit structure, separation between structure and prompt content, executable semantics, and the graph as a first-class engineering artifact), and operationalize them as an inclusion and exclusion test. We draw the boundary against six neighboring concepts and apply the test to six real systems (LangGraph, DSPy, Prompt Flow, AutoGen, CrewAI, and Claude Code subagents); it includes and excludes consistently. We close with a research agenda organized along four design tension axes. The contribution is an operational definition and a shared vocabulary for a practice that industry already exercises daily without naming precisely.
1 Introduction
Modern language-model applications are engineered as executable structures of retrieval, model calls, routing, parallelism, aggregation, and verification rather than isolated prompts. This article defines prompt graph engineering as that structure’s explicit, inspectable, and improvable engineering practice, distinguishing it from neighboring uses of “graph” and testing it across real systems.
- Motivation: The engineering unit has shifted from a single prompt string to a structure connecting retrieval, planning, routing, parallel calls, aggregation, and verification.This shift makes prompt composition, execution, and control flow central engineering concerns.
- Genealogy: Prompt structures evolved from single prompts through human-curated chains, within-generation reasoning chains, branching trees, and merging, looping graphs [1].In parallel, declarative pipelines, function-call DAGs, and agent workflows turned these structures into executable or searchable programs.
- Problem: “Graph” remains ambiguous across graph-of-thoughts [1], multi-agent conversation traces, and orchestration practices, while flow engineering lacks explicit criteria for routing, merging, and artifact status.The missing concept is the engineering of how prompt-bearing nodes compose, route, and execute.
- Motivation: Opaque scripts and improvised agent conversations cannot be reliably inspected, type-checked, versioned, or optimized, whereas optimizers require the structure to exist as an object.This motivates treating the graph as a first-class engineering artifact rather than an incidental implementation detail.
- Contributions: The article contributes a genealogy, a constitutive definition with an inclusion/exclusion test, a boundary against six neighboring concepts, a consistent classification of six real systems, and a tension-axis research agenda.It is deliberately definitional: it proposes neither a new framework nor a benchmark, but a shared vocabulary and reproducible membership test; verified-DOI sources are formal citations and product documentation is footnoted.
2 Related Work
Related work surrounds prompt graph engineering through five research lines and three smaller neighborhoods, but does not define its constitutive conditions. The paper positions prompt graphs as the internal structure composing calls, distinct from the external loop that drives an agent harness.
- 2 Related Work: Existing research lines and smaller neighborhoods contextualize prompt graph engineering without supplying a constitutive definition.The related work comprises five research lines plus interface antecedents, terminology, and definitional method.
- 2 Related Work: Prompt engineering surveys systematize techniques for individual prompts, leaving the composition of prompts themselves underdefined.
- 2 Related Work: Prompt graphs organize the internal composition of calls, whereas the external loop drives the agent through an agent harness.The article follows a progression from prompt to context, harness, and loop.
3 Genealogy (RQ1)
Prompt graph engineering inherits graph-based computation, where explicit dependencies separate orchestration from computation and make workflows parallelizable, inspectable, and rerunnable. Its genealogy then splits between internal reasoning topologies and externally authored, executable compositions before converging on optimizable graph artifacts.
- 3 Genealogy (RQ1): Graph-based computation preceded prompts, from dataflow and build dependencies to scientific workflows whose shared unit could be audited and rerun.These traditions established graphs as structures for coordinating steps without welding them together.
- 3 Genealogy (RQ1): Early prompt engineering treated the prompt as an individual string, advancing through few-shot examples, instruction following, reasoning cues, catalogs, and surveys.Decomposition first challenged the assumption that one string was the complete unit of prompt design.
- 3 Genealogy (RQ1): One lineage kept structure inside model reasoning: chain-of-thought was linear, self-consistency parallelized chains, tree-of-thoughts branched search, and graph-of-thoughts allowed merging, refinement, and loops [1].This lineage developed reasoning topologies within generation rather than engineering workflows outside the model.
- 3 Genealogy (RQ1): The other lineage externalized structure into authored model-call chains, visual node-edge editors, probabilistic programs, heterogeneous nodes, and agent workflow graphs.This engineering lineage emphasized composability, controllability, formal semantics, and explicit interaction structure.
4 Constitutive Definition (RQ2)
Prompt graph engineering is defined by four necessary conditions: explicit graph structure, separable structure and prompt content, executable semantics, and first-class artifact status. The definition becomes an inclusion test requiring all four conditions while excluding incidental features such as visual editors, acyclicity, multiple models, frameworks, or agents.
- Reference definition: Prompt graph engineering represents, composes, and executes prompt-mediated language-model computation as an explicit graph of authored computation nodes and data or control dependencies.The definition is framed by necessary conditions rather than examples and is intended to distinguish the concept from neighboring practices.
- Four conditions: The four constitutive conditions are G1 explicit structure, G2 separation of structure and content, G3 executable semantics, and G4 first-class artifact status.The graph must support runtime scheduling, routing, shared state, branching, parallelism, and cycles, while remaining inspectable, versionable, validatable, and optimizable independently of execution.
- Scope and exclusions: The definition excludes incidental requirements: graphs may be coded rather than visually edited, cyclic rather than acyclic, and built with one model, one framework, or no agents.Cycles with exit conditions support reflection and retry loops.
- Decision procedure: A candidate belongs to prompt graph engineering only if it answers yes to T1–T4: explicit enumerable nodes and edges, separable structure and content, executable graph semantics, and an inspectable artifact beyond one run.T1 requires enumeration by inspection, API, or serialization without execution; T3 requires the graph, rather than surrounding handwritten control flow, to determine runtime behavior.
5 Boundary (RQ3)
Prompt graph engineering occupies the intersection of explicit, executable, first-class graph structure and authored, prompt-parameterized model invocations. Its boundary test distinguishes neighboring concepts by which condition they lack, while treating prompt programming as a code-shaped realization of the concept.
- Prompt engineering and programming: Classic prompt engineering is intra-node wording and therefore fails T1, while prompt programming such as DSPy passes all four tests by making module composition the optimizable artifact.Prompt engineering remains local to each graph node; DSPy separates signatures from generated prompt text and interprets module composition during execution.
- Thought topologies: Thought topologies distinguish rhetorical from invocation structure: chain-of-thought fails T1, whereas tree- and graph-of-thought systems orchestrate invocations over explicit topologies [1].Graph-of-thoughts can reify a graph of operations, so T1 and T3 arguably pass.
- Agent orchestration: Free-conversation multi-agent systems fail T1 because their interaction shape emerges turn by turn without a representation enumerating it beforehand.The boundary is crossed when orchestration flows are reified, as in MetaGPT’s standardized procedures and StateFlow’s state machines.
- RAG pipelines: RAG pipelines are partial cases: hardwired retrieve-then-generate code fails T1, while declared framework objects may pass T1 but typically fail T4 and often T2.The verdict depends on where the flow lives and whether the graph remains available beyond the execution context.
- Boundary synthesis: The boundary criterion is conjunctive: prompt graph engineering requires both explicit graph structure and authored, prompt-parameterized model-invocation nodes.Thought topologies have graph without authorship; free agent conversations have prompts without structure; classic workflow engines have structure without prompts; single-prompt craft has neither.
6 Applying the Test to Real Systems (RQ4)
Applying T1–T4 to six systems discriminates fully compliant graph-based systems from partial, mode-dependent, and excluded cases. The exercise also highlights emerging graph-optimization systems while remaining limited by single-analyst classification, grey-literature evidence, and a six-system sample.
- Applying T1–T4: LangGraph passes because its explicit, independently editable StateGraph executes over typed state and remains serializable, visualizable, and usable for tracing and evaluation.Its runtime supports cycles, branching, interrupts, and checkpointing.
- Applying T1–T4: DSPy passes with enumerable module structure, signature-based separation of structure from generated prompt content, executable compositions, and optimizer-facing programs.It demonstrates that prompt graph engineering can center on compilation and optimization rather than hand-authored prompts.
- Applying T1–T4: Prompt Flow passes literally through YAML-declared DAGs, separately referenced templates, runtime execution, and artifacts that are visualized, versioned, and batch-evaluated, but lacks native cycles.Reflective feedback loops must therefore be placed inside nodes, weakening support for reflective patterns.
- Mode-dependent systems: AutoGen’s conversational mode fails T1 and T4 because interaction structure emerges turn by turn, whereas GraphFlow reifies an explicit directed graph and substantially restores those conditions.CrewAI shows a parallel split: emergent Crews are at best partial on T1, while explicit Flows pass T1 and T3 but remain partial on T4.
- Limits: The classification was performed by one analyst using repeatable criteria, while grey-literature evidence, rapidly changing products, and a six-system sample limit generalization.Inter-rater agreement is identified as the first empirical follow-up, and broader testing should include serving layers, visual builders, and enterprise orchestrators.
- Applying T1–T4: LangGraph, DSPy, and Prompt Flow pass all four tests, while AutoGen and CrewAI are partial across operating modes and Claude Code subagents are excluded.Figure 4 and Table 2 summarize the consistent discrimination: three systems pass cleanly, multi-agent frameworks split by mode, and the coding harness fails structural conditions.
7 Research Agenda (RQ5)
The research agenda organizes unresolved prompt-graph design questions along four tension axes: explicit–emergent, static–dynamic, node granularity, and manual–automatic improvement. It also identifies transversal challenges in verification and context discipline.
- Agenda overview: The agenda frames disagreements among analyzed systems as open design questions across four tension axes, summarized in Figure 5.The axes cover structure, dynamism, node granularity, and improvement automation.
- Explicit versus emergent structure: Explicit structure enables inspection, verification, and optimization, whereas emergent structure adapts to unforeseen tasks through runtime delegation.Graph-first systems author the flow; multi-agent frameworks may reify it selectively, while coding harnesses can leave it entirely emergent.
- Static versus dynamic structure: Static graphs preserve knowledge before execution, while dynamic graphs increase expressiveness; an underexplored middle combines static skeletons with dynamically instantiated regions [1].Prompt Flow fixes a DAG, LangGraph routes over fixed nodes, and LLMCompiler builds a graph per task instance.
- Node granularity: Fine-grained prompt invocations support analyzable dataflow, whereas coarse-grained agents provide encapsulation and role clarity.The unresolved problem is composition across granularities, which frameworks currently force engineers to choose.
- Manual versus automatic improvement: Improvement ranges from hand-tuned graphs to prompt optimization, textual gradients, compiled pipelines, and structural search.Automation depends on G4, but stochastic, expensive graph search raises additional questions.
- Transversal problems: Across the axes, verification must address types, cycle termination, cost, and latency, while context discipline treats decomposition as curated context management.Some verification properties may require semantic judgment or model-bearing nodes.
8 Conclusion
The paper defines prompt graph engineering through four conditions and operationalizes the definition as an inclusion and exclusion test. This conceptual vocabulary aligns existing engineering practice with a genealogy spanning dataflow models, build systems, chaining, thought topologies, and compiled or searched graphs.
- Genealogy: The paper reconstructs prompt-graph genealogy from dataflow models and build systems through prompt chaining and thought topologies to graphs compiled and searched as objects.
- Contribution: Prompt graph engineering requires explicit structure, separation of structure from prompt content, executable semantics, and a graph treated as a first-class engineering artifact.These conditions are converted into an inclusion and exclusion test that distinguishes prompt graph engineering from neighboring concepts.
- Engineering payoff: Each condition enables a concrete engineering payoff: inspection requires explicit structure, reuse and compilation require separation, execution requires semantics, and optimization requires the artifact.The contribution is presented as conceptual hygiene with an engineering payoff rather than bureaucracy.
Declaration on the Use of Generative AI
The author conducted the research and wrote the manuscript, using Grammarly and Claude Opus 4.8 only to support textual editing, structuring, and translation before reviewing the content and assuming full responsibility.
- Declaration on the Use of Generative AI: The author used Grammarly for textual agreement and Claude Opus 4.8 for text structuring and English translation, then reviewed and edited the content as needed.The author retains full responsibility for the publication’s content.