Paper deep dive
From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes
Mariano Garralda-Barrio
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 90%
Last extracted: 7/9/2026, 7:19:20 AM
Summary
This conceptual systems paper introduces the Goal-Oriented Dialogue Runtime (GODR), a framework-neutral design pattern for managing conversational continuity in complex, multi-agent LLM workflows. It addresses the limitation of existing orchestration frameworks in handling interdependent, suspendable, and invalidable user objectives. GODR treats goals, task frames, lifecycle states, invalidation rules, and resumption contracts as first-class runtime objects, delegating bounded execution to underlying graph runtimes. The paper proposes a Goal Complexity Taxonomy (GC-0 to GC-4) to guide architecture selection, positioning GODR specifically for GC-4 scenarios involving multiple active goals with dependencies and invalidation events. It distinguishes execution continuity from objective continuity and provides an architectural blueprint for future empirical validation.
Entities (17)
Relation Signals (20)
Execution Continuity → contrastswith → Objective Continuity
confidence 95% · Process-guided systems primarily require execution continuity, whereas multi-goal conversational systems require objective continuity.
Goal-Oriented Dialogue Runtime → manages → Objective Continuity
confidence 95% · GODR is dedicated to objective continuity. It maintains goal state, lifecycle policies, resumption contracts, and inter-goal consistency rules while delegating bounded execution to graph runtimes, tools, and specialist agents.
Goal-Oriented Dialogue Runtime → delegatesexecutionto → Multi-agent orchestration frameworks
confidence 94% · GODR is not proposed as a replacement for workflow graphs in simple guided processes; it is intended for complex, multi-domain, interruptible conversations... delegating bounded execution to graph runtimes, agents, tools, or application programming interfaces (APIs).
Goal-Oriented Dialogue Runtime → treatsasfirstclassobjects → Invalidation Rule
confidence 93% · We introduce the Goal-Oriented Dialogue Runtime (GODR), a framework-neutral design pattern that treats goals, task frames, lifecycle state, invalidation rules, and resumption contracts as first-class runtime objects
Goal-Oriented Dialogue Runtime → treatsasfirstclassobjects → Resumption Contract
confidence 93% · We introduce the Goal-Oriented Dialogue Runtime (GODR), a framework-neutral design pattern that treats goals, task frames, lifecycle state, invalidation rules, and resumption contracts as first-class runtime objects
Goal Complexity Taxonomy → classifies → GC-4
confidence 92% · Table 1 defines five goal-complexity (GC) levels used throughout the paper. The key design threshold for this paper is GC-4.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Graph and multi-agent orchestration frameworks make production large language model (LLM) workflows practical, but they do not by themselves solve conversational continuity when users maintain several interdependent objectives. This conceptual systems paper focuses on the high-complexity end of that design space, where goals can be suspended, resumed, revised, and invalidated by actions in other goals. We introduce the Goal-Oriented Dialogue Runtime (GODR), a framework-neutral design pattern that treats goals, task frames, lifecycle state, invalidation rules, and resumption contracts as first-class runtime objects while delegating bounded execution to graph runtimes, agents, tools, or application programming interfaces (APIs). GODR is not proposed as a replacement for workflow graphs in simple guided processes; it is intended for complex, multi-domain, interruptible conversations where objective continuity cannot be recovered reliably from agent identity, chat history, or execution-graph position alone. The paper formalizes the problem, proposes runtime objects and architecture-selection criteria, and frames evaluation as an agenda for future empirical validation rather than as a measured performance claim.
Tags
Links
- Source: https://arxiv.org/abs/2606.23797v1
- Canonical: https://arxiv.org/abs/2606.23797v1
Trouble viewing inline? Open PDF directly →
Full Text
72,515 characters extracted from source content.
Expand or collapse full text
From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes A Conceptual Framework for Conversational Architecture Engineering Mariano Garralda-Barrio ∗ Independent Researcher Lleida, Spain mariano.garralda.r@gmail.com June 24, 2026 Abstract Graph and multi-agent orchestration frameworks make production large language model (LLM) workflows practical, but they do not by themselves solve conversational continuity when users maintain several interdependent objectives. This conceptual systems paper focuses on the high-complexity end of that design space, where goals can be suspended, resumed, revised, and invalidated by actions in other goals. We introduce the Goal-Oriented Dialogue Runtime (GODR), a framework-neutral design pattern that treats goals, task frames, lifecycle state, invalidation rules, and resumption contracts as first-class runtime objects while delegating bounded execution to graph runtimes, agents, tools, or application programming interfaces (APIs). GODR is not proposed as a replacement for workflow graphs in simple guided processes; it is intended for complex, multi-domain, interruptible conversations where objective continuity cannot be recovered reliably from agent identity, chat history, or execution-graph position alone. The paper formalizes the problem, proposes runtime objects and architecture-selection criteria, and frames evaluation as an agenda for future empirical validation rather than as a measured performance claim. 1 Introduction Conversational artificial intelligence (AI) engineering is increasingly moving from prompt-centric interactions toward stateful, tool-augmented, and agent-oriented systems [1,2]. Current orchestration frameworks expose agents, tools, and multi-agent orchestration patterns as practical execution primitives [3–6]. They also provide mechanisms for subgraphs, handoffs, memory, checkpoints, and tracing [7–9]. These primitives are valuable for execution continuity, but they do not fully solve conversations where several user objectives remain active, share constraints, and can invalidate one another. This paper proposes the Goal-Oriented Dialogue Runtime (GODR) as a framework-neutral layer for making those objectives explicit. More broadly, GODR follows the same architectural direction as recent agent-system work that treats runtime state, tools, memory, orchestration, and evaluation as explicit engineering objects rather than as prompt-only concerns [10, 11]. In a process-driven conversation, the system guides the user through a known sequence: identify the customer, collect data, validate preconditions, request approval, and close the operation. This is the type of architecture where a root graph with business subgraphs works well. The user may retry an answer, trigger a human-in- the-loop step, cancel the process, or reach a reset condition, but the conversational freedom remains bounded by the process. The harder case follows a different organizing principle. Rather than being driven by a predefined process, the conversation is organized around a user objective that remains active across interruptions, subgoals, and ∗ Independent Researcher / Investigador Independiente. arXiv:2606.23797v1 [cs.SE] 22 Jun 2026 From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes User Turn Goal-Oriented Dialogue Runtime (GODR) Goal Manager Goal Policy Goal Structure Stack / Tree / Graph Resumption Contracts Dialogue State and Audit Log Execution Runtime LangGraph / Google Agent Development Kit (ADK) / CrewAI / AutoGen / Semantic Kernel / APIs / Tools delegates observations Figure 1: Proposed Goal-Oriented Dialogue Runtime within the conversational stack. The figure illustrates the central hypothesis of this paper: goal management should be represented as an explicit runtime layer above execution frameworks rather than being implicitly encoded in agents, memory structures, or workflow graphs. contextual shifts. We refer to this as a conversation-driven goal: a conversational objective whose continuity cannot be reduced to a single execution path. For example, a user registering for a professional workshop may branch into venue accessibility, dietary requirements, hotel logistics, session selection, payment constraints, group discounts, invoice requests, or external interruptions. Some branches are side questions; others become subgoals; others supersede the original objective. The system must decide not only which agent answers next, but which user goal remains alive, which goal is suspended, and how to resume it. The central claim is deliberately scoped: conventional finite-state machines (FSMs), workflow graphs, or goal stacks are often sufficient for bounded processes and shallow interruptions [12,13]. Full GODR becomes useful when the conversation contains multiple open goals, non-local dependencies, shared constraints, and invalidation events. In that regime, agent graphs and workflow graphs remain necessary execution substrates, but the runtime also needs an explicit object for objective ownership. GODR treats execution as a service of goals rather than treating goals as incidental attributes of execution. Figure 1 summarizes the core architecture: goals are managed above execution frameworks, not hidden inside them. This paper makes four contributions: • It defines the Multi-Objective Interruptible Dialogue Problem, separating active-agent selection and execution continuity from active-goal continuity. •It introduces goal complexity as a taxonomy for selecting conversational architectures and relating stacks, trees, and goal graphs to underlying dependency structure. • It proposes the Goal-Oriented Dialogue Runtime as a framework-neutral layer above graph and agent execution substrates, with goals, lifecycles, task frames, invalidation rules, and resumption contracts as first-class runtime objects. •It provides an engineering methodology, evaluation criteria, and baselines for selecting and testing dialogue architectures under interruptible multi-domain goal complexity. Operationally, GODR is a runtime dedicated to objective continuity. It maintains goal state, lifecycle policies, resumption contracts, and inter-goal consistency rules while delegating bounded execution to graph runtimes, tools, and specialist agents. The design boundary is explicit: execution frameworks manage how work is performed; GODR manages why the work remains relevant and how interrupted objectives are resumed. 2 From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes 2 Motivating Example: From Warranty Claims to Event Registration The contrast between process-driven and conversation-driven systems is easiest to see through two service scenarios. Both can use agents, tools, and graph runtimes, but they differ in what must remain stable across turns: the process position in the first case, and the user’s suspended objective in the second. 2.1 Process-Driven Conversational Workflow A warranty replacement assistant is a representative example of a process-driven conversation. The user can provide information in natural language, but the system still owns the sequence: identify the account, validate the warranty, diagnose the issue, approve replacement, and collect shipping details. User: My noise-cancelling headphones stopped charging. System: I can help with a warranty replacement. What is the order number? User: It is ORD-3147. System: The device is still under warranty. Did the charging indicator light turn on when you tried a different cable? User: No, I tried two cables and nothing lights up. System: The issue qualifies for replacement. Please confirm the shipping address for the replacement unit. This dialogue can be implemented naturally as a root graph with business subgraphs and global human-in- the-loop or reset policies. The architecture remains understandable because the main object being executed is a process. The user may answer freely, retry, cancel, or escalate, but the conversational path remains anchored in the warranty workflow. 2.2 Conversation-Driven Task Orchestration An event registration assistant has a different shape. The user starts with a registration goal, but the conversation can legitimately branch into venue, catering, billing, travel, or policy questions before returning to the unfinished registration. User: I want to register for the AI Systems Workshop next Friday. System: I found two sessions, morning and afternoon. Which do you prefer? User: Before choosing, is the venue wheelchair accessible? System: Yes. The venue has step-free access and accessible seating. [VenueAccessibility goal completed] User: Good. Can I request a vegan meal? System: Yes. I can add a vegan meal request to the registration. [DietaryPolicy goal completed] User: Also, will you send an invoice to my company? System: Yes. I can collect billing details after the session is selected. [InvoiceRequest goal suspended] User: Continue with the registration. System: Resuming registration: morning or afternoon session? [Resume EventRegistration at waiting_for_session_preference] A fully connected graph of agents can route these turns, but routing is not enough. The unresolved object is the interrupted registration goal. The system must preserve the selected event, the missing session preference, the side constraints introduced by accessibility and catering, and the exact resumption point. 3 Execution Continuity versus Objective Continuity The boundary between process-guided and multi-goal dialogue systems can also be described in terms of control continuity. In a process-guided conversational system, continuity is mostly equivalent to preserving the current process position. From a given execution node, the runtime usually needs only three control 3 From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes current_node retry(current_node) continue(next_node) abort_or_reset(process) Figure 2: Local control moves in a process-guided dialogue. The runtime retries the current node, advances to the next node, or aborts and resets the process. TravelBooking suspend resume_at=collect_traveler_details VisaPolicyQuestioncomplete resume(TravelBooking, at=collect_traveler_details) Figure 3: Objective continuity across an interruption. The travel booking remains resumable while the visa-policy question temporarily controls the dialogue. moves: retry the same node, advance to the next node, or abort or reset the process. Figure 2 summarizes this local control model. This pattern is not a limitation of workflow-based systems; it is precisely where they are strongest. Warranty replacement, onboarding, travel booking, know-your-customer checks, claims handling, and similar enterprise workflows often have a single active trajectory. Local retries, validation loops, escalation policies, and global resets can be represented cleanly because the current execution position and the user’s conversational objective remain largely aligned. Importantly, the complexity of a workflow node is orthogonal to the complexity of the goal structure. A node may internally contain a ReAct agent [1], planning loops, tool orchestration, or human-in-the-loop interactions while still preserving a single execution position and a single active objective. Such mechanisms increase local reasoning and execution complexity, but do not by themselves require objective-level lifecycle management. The conceptual break appears when user goals become suspendible. A side question, policy check, invoice request, or dependent subtask may temporarily take control while the original objective remains alive. The system must then preserve not only the current execution node, but also the suspended goal, its pending action, the logical return point, the context required for safe resumption, and any invalidation conditions introduced by later turns. Figure 3 illustrates this distinction with a travel-booking goal interrupted by a visa-policy question. In this regime, the runtime no longer only advances, retries, or restarts. It performs a logical return to a suspended objective without rolling back execution history. This is the role of a resumption contract: it captures the continuation that must survive interruptions, tool calls, agent changes, and later user corrections. Process-guided systems primarily require execution continuity, whereas multi-goal conversational systems require objective continuity. 4 From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes Table 1: Goal complexity levels for conversational runtime selection. LevelGoal structureExampleSuggested model GC-0Single immutable goal following a fixed execution path. Interactive voice response troubleshooting. FSM GC-1Single goal with bounded interruptions, retries, or escalation paths. Warranty assistant with escalation. Workflow graph GC-2One active goal path at a time, with nested goals and explicit resumption points. Event registration with side questions. Goal stack GC-3Multiple independent goals remain active simultaneously and compete for attention. Enterprise copilot tracking ongoing user tasks. Goal tree or agenda GC-4Multiple active goals with dependency, coordination, and invalidation relationships. Operational AI assistant coordinating approvals, resources, and policies. GODR + goal graph / DAG 4 Goal-Complexity Taxonomy Conversational type is not enough; designers also need to estimate the complexity of the goal structure itself. Table 1 defines five goal-complexity (GC) levels used throughout the paper. When graph structure is needed, a directed acyclic graph (DAG) is a useful representation for dependencies without cycles: The key design threshold for this paper is GC-4. GC-0 and GC-1 are usually well served by FSMs or workflow graphs; GC-2 often needs a goal stack; GC-3 may require an agenda or goal tree. Below GC-4, the cost of explicit goal lifecycle management often exceeds its practical benefit. GODR is intended for GC-4, where several goals remain alive and actions in one goal can change the validity, priority, or resumability of another. This is where dependency and invalidation semantics become runtime concerns rather than implementation details. 4.1 A GC-4 Example: Corporate Procurement Assistant A corporate procurement assistant illustrates why a goal graph is sometimes necessary. Consider a session in which a user asks the assistant to purchase hardware for a new team. The session may contain several open goals, with dependencies and invalidation relations like those in Figure 4: PurchaseRequest VendorSelection BudgetApprovalComplianceCheckDeliveryConstraint VendorChangeEvent triggers invalidation InvoiceGeneration Figure 4: A GC-4 procurement goal graph. Solid arrows encode subgoal and required-for relations; dashed arrows encode invalidation events. Invoice generation depends on budget approval, compliance, and delivery constraints; a vendor-change event invalidates both compliance and invoice generation. This is not a stack. The user may first request a purchase, then ask for vendor alternatives, then trigger a compliance check, then revise the budget, and later ask for invoice preparation. If the budget is rejected, the 5 From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes purchase request is blocked; if the vendor changes, the compliance check and invoice draft may be invalidated; if delivery constraints change, vendor selection may need to be reopened without cancelling the original purchase request. A root graph can encode one procurement process, but the conversational session may contain multiple partially complete, cross-dependent goals. A supervisor can route between procurement, compliance, budget, and invoicing agents, but routing alone does not express which goals are invalidated by a vendor change or which suspended goals remain safe to resume. This is the GC-4 regime: the runtime requires a goal DAG with explicit dependency, blocking, supersession, and invalidation relations. 5 Related Work The proposal builds on several research and engineering traditions rather than starting from a blank slate. This section reviews the most relevant precedents: classic task-oriented dialogue systems, multi-domain dialogue state tracking, planning and Belief–Desire–Intention (BDI) models, and recent LLM orchestration frameworks. The goal is to clarify which ideas GODR reuses and where it introduces a distinct runtime boundary for conversational goal continuity. The evolution of conversational architectures can be interpreted as a progressive externalization of conversa- tional state and control. Early dialogue systems externalized dialogue state through information-state and dialogue-management models. Multi-domain systems extended this idea to goal, schema, and service tracking. Planning and BDI architectures introduced explicit representations of objectives, commitments, and action structure. Modern LLM frameworks externalize execution through agents, workflows, tools, and orchestration runtimes. GODR follows this trajectory by externalizing conversational goal lifecycle management as a runtime concern. 5.1 Classic Task-Oriented Dialogue Systems Pre-LLM task-oriented dialogue systems did not rely primarily on a single giant graph. The canonical architecture separated natural language understanding, dialogue state tracking, dialogue management, policy, and response generation, often through explicit information-state or decision-theoretic dialogue models [14–16]. RavenClaw is particularly relevant because it models dialogue management through hierarchical task decomposition and an expectation agenda [17,12]. Its agenda-based interpretation anticipates the need to represent pending expectations rather than only active transitions. Microsoft Bot Framework formalized the Dialog Stack: a dialog context contains active dialogs, and the dialog stack acts as a call stack for them [18,13]. This is a concrete engineering precedent for suspended and resumed subdialogues. 5.2 Multi-Domain Dialogue State Tracking Multi-domain dialogue state tracking has long been treated as a central problem for task-oriented assistants, from shared tracking challenges and large multi-domain corpora to schema-guided service representations [19–21]. The Schema-Guided Dialogue dataset highlights the scalability problem in multi-domain assistants. It provides annotations for intent prediction, slot filling, dialogue state tracking, and response generation across many domains and services [21,22]. Importantly, it frames state tracking as estimating the user goal over dynamic service schemas. Recent work such as Dialog2API makes the connection clearer: it represents dialogue state as a stack of programs, with the most recently mentioned program at the top [2]. This is conceptually close to a goal stack or task stack for composite, revisable user objectives. Task-Oriented Dialogue as Dataflow Synthesis takes another route by representing dialogue state as a dataflow graph [23]. The common theme is that mature dialogue systems externalize state and task structure instead of encoding the whole interaction as a flat transition graph. 5.3 Relationship with Classical Planning The proposed model is related to classical planning, but it addresses a different runtime problem. Planning typically reasons over actions, preconditions, effects, and goals to synthesize or select a sequence of actions that reaches a desired state [24]. GODR is concerned with the lifecycle of user goals during an interactive 6 From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes session: goals may be partially specified, suspended, resumed, revised, abandoned, superseded, or invalidated by later dialogue. The distinction is operational. A planner may decide how to satisfy a booking objective; a goal-oriented dialogue runtime decides whether the booking objective is still active, whether it has been suspended by a side question, whether its resumption contract remains valid, and whether later user input has revised or invalidated it. GODR can therefore use planning inside the execution layer, but it should not be reduced to planning alone. 5.4 Goal Decomposition and HTN Planning Hierarchical Task Network (HTN) planning decomposes high-level tasks into structured networks of subtasks and ordering constraints, and it has long served as a model for goal-directed decomposition and execution control [25,26,24]. GODR shares the idea that complex objectives may require subordinate structure: a conversational goal can spawn subgoals, maintain pending actions, or depend on other goals. The boundary is different, however. HTN planning primarily focuses on plan construction, task decomposition, and execution ordering. GODR focuses on conversational goal lifecycle management: interruption handling, suspension, resumption, supersession, cross-goal invalidation, and auditability during dialogue. In this sense, HTN planning can be viewed as a potential execution strategy within a goal, whereas GODR governs the persistence and coordination of goals themselves. 5.5 Relationship with BDI Architectures The terminology of goals, policies, and intentions naturally recalls Belief–Desire–Intention (BDI) architectures, where agents maintain informational beliefs, motivational desires, and committed intentions [27,28]. GODR is compatible with that lineage but focuses on a narrower systems problem: preserving conversational goal continuity across modern LLM orchestration substrates. In BDI terms, a suspended goal resembles an intention that should not be forgotten merely because another intention temporarily controls behavior. However, GODR does not require a full BDI agent model. Its contribution is architectural: it externalizes goal lifecycle, goal structure, resumption contracts, and invalidation relations as runtime objects that can sit above graph runtimes, tool agents, or workflow engines. 5.6 Modern LLM Orchestration Frameworks Modern orchestration frameworks such as LangGraph, Google Agent Development Kit (ADK), Semantic Kernel and Microsoft Agent Framework, CrewAI, OpenAI Agents, Amazon Bedrock Agents, and AutoGen provide various combinations of agents, workflows, tools, handoffs, state management, memory, checkpoints, tracing, and multi-agent coordination [7, 8, 4, 9, 29, 30, 5, 31, 32, 6, 33, 34]. These systems differ substantially in programming model and operational scope, but they support the same broad architectural trend: execution is externalized into explicit runtimes, graphs, agents, tools, and workflow substrates. That is the layer GODR assumes rather than replaces. Across these frameworks, the common primitives are agents, tools, workflows, handoffs, state, and memory. Table 2 therefore compares the execution responsibilities commonly provided by modern orchestration frameworks with the objective-continuity responsibilities introduced by GODR. This comparison is not a claim that existing frameworks are incomplete for their intended purpose. Rather, it identifies a missing layer: they provide strong execution and orchestration substrates, while goal lifecycle and objective continuity remain design responsibilities for the application architect. Taken together, these lines of work reveal a recurring pattern. Dialogue systems externalize state; planning systems externalize action selection and task decomposition; BDI systems externalize intentions; and modern orchestration frameworks externalize execution. However, conversational goal lifecycle management remains largely embedded in application-specific logic. GODR is proposed as an explicit runtime abstraction for this remaining concern. 7 From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes Table 2: Execution continuity provided by modern orchestration frameworks versus objective-continuity responsibilities introduced by GODR. CapabilityModern orchestration frameworksGODR layer Agent and workflow orchestrationFirst-class agents, graphs, handoffs, supervisors, or flows. Delegated to external runtimes. Tool and API executionFirst-class tool invocation and bounded task execution. Delegated through runtime adapters. State, memory, and checkpointsSupported through framework-specific state, memory, tracing, or persistence mechanisms. Reused as execution evidence, rather than the authoritative goal state. Goal lifecycleTypically application-defined above the framework state model. First-class runtime concern: created, active, suspended, blocked, and terminal states. Resumption contractsTypically application-defined through checkpoints, prompts, or custom state. First-class contract with pending action, required context, return point, and invalidation conditions. Goal structuresTypically application-defined as stacks, task trees, graph conventions, or ad hoc registries. First-class runtime representation of conversational goal structures. Cross-goal semanticsTypically application-defined through business rules or controller code. Runtime-managed dependency, invalidation, blocking, supersession, and consistency relations. Objective continuityEmerges from application logic built on top of execution state. Explicit responsibility of the runtime layer. Table 3: Goal-policy decision space at turn t. OperationRuntime meaning continue(current_goal)Advance the active goal with the new user contribution. revise(current_goal)Update constraints, slots, or assumptions for the active goal. push(child_goal)Create a nested goal owned by the current goal. switch(goal_i)Transfer control to another open goal. pop(completed_goal) Close a completed goal and return to the appropriate parent or agenda item. resume(previous_goal)Reactivate a suspended goal at its resumption contract. cancel(goal_i | all_goals)Abandon one goal or the active goal structure. escalate_to_human(goal_i)Transfer a goal to a human decision or review path. reset_on_failureReset a failed goal or the entire session under policy. 6 Problem Statement Current LLM orchestration frameworks are effective at answering: which node, agent, or tool should run next? The harder question in multi-objective conversations is: which user goal is active, which goals are suspended, and what is the correct resumption point? We define the Multi-Objective Interruptible Dialogue Problem as follows: given a conversation historyH, a set of active and suspended goalsG, a set of available agents and toolsA, and a new user utteranceu t , determine which goal-level operation in Table 3 should update the active goal structure. This decision cannot be solved cleanly by agent routing alone because the active agent and the active goal are not equivalent. A venue-information agent may answer a side question inside an event-registration goal, or it may own an independent venue-information goal. This semantic distinction matters for memory, resumption, user experience, and auditability. Not all interruptions imply a goal transition. Some interruptions correspond to associated objectives that semantically support completion of the current goal, such as requesting clarification about a required document, a policy, or a business rule. In these cases, conversational control may temporarily shift, but the parent goal remains the primary objective driving the interaction. Other interruptions introduce independent goals with their own completion criteria and lifecycle. Distinguishing associated from independent goals is therefore an implementation concern of the Goal Policy rather than a separate goal-complexity category: both may appear within the same GC level, but they may trigger different runtime operations such ascontinue,revise,push, switch, or resume. 8 From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes Table 4: Boundary between goal-runtime objects and adjacent conversational abstractions. AbstractionPrimary roleWhy it is not enough for goal con- tinuity IntentClassifies what the latest user turn ap- pears to request. It is turn-local and does not encode sus- pended objectives or resumption points. MemoryStores reusable facts, preferences, or prior conversation content. It represents information but does not govern lifecycle transitions. PlanOrders proposed actions for a task or agent. It may change without preserving which user objective owns the plan. Workflow stateTracks progress inside a bounded busi- ness or tool process. It is local to execution and does not man- age cross-goal interruption or invalida- tion. Task frameStores slots, constraints, and local state for a goal. It needs an owning goal and lifecycle pol- icy to remain resumable and auditable. 7 Operational Model A Goal-Oriented Dialogue Runtime can be described as a transition system over conversational goals. At turn t, the dialogue state is represented as D t =⟨H t ,G t ,a t ,C t ,L t ⟩,(1) whereH t is the conversation history,G t is the current goal structure,a t is the active goal identifier,C t is the set of global session constraints, and L t is the audit log. The goal structure is a labeled directed graph G t = (V t ,E t ,λ V ,λ E ),(2) where eachv ∈ V t is a goal object, eache∈ E t is a relation between goals,λ V assigns lifecycle and frame attributes to goals, andλ E assigns relation types such asparent,depends_on,blocks,supersedes,resumes, orinvalidates. A stack is the special case whereG t is a linear chain with last-in-first-out control. A tree is the special case where relations are hierarchical. A DAG is required when dependency or invalidation relations cross hierarchical branches. A goal is a persistent conversational objective whose lifecycle may extend across multiple turns, agents, tools, and execution graphs, and whose completion or validity cannot be inferred solely from local execution state. This definition distinguishes goals from turn-level intents and from local workflow progress: a goal is the object that remains accountable for continuity when the conversation is interrupted, revised, resumed, or invalidated. A goal g ∈ V t is represented as g =⟨id,type,status,frame,agent,graph,resume,policy⟩,(3) where frame stores known values, missing slots, constraints, and local memory; resume is a resumption contract; and policy encodes local safety or business constraints. This definition also separates GODR from nearby abstractions that are often conflated in LLM systems. An intent classifies the user’s current utterance; a memory stores reusable information; a plan proposes future actions; and workflow state records progress inside a bounded execution process. GODR governs the lifecycle of user objectives across these objects: it decides which objective is active, suspended, resumed, invalidated, or closed. Table 4 makes this boundary explicit. In this paper, an object belongs to GODR only when it participates in goal lifecycle transitions such as activation, suspension, resumption, revision, invalidation, supersession, completion, cancellation, or escalation. Given a user utterance u t , the Goal Policy computes a goal operation o t = π(u t ,D t )∈O,(4) 9 From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes Table 5: Goal structures for interruptible conversational runtimes. StructureBest fitFailure mode if overused Goal stackNested interruptions with clear return points. Forces unrelated goals into artificial push/pop order. Goal treePrimary goals with child subgoals, expla- nations, policies, and clarifications. Struggles when goals share dependencies across branches. Goal DAG Multiple open goals with shared con- straints, resources, or dependencies. Requires stronger consistency, invalida- tion, and scheduling policies. whereO=continue,revise,push,switch,pop,resume,cancel,escalate,reset. The operation transforms the dialogue state before the selected graph runtime or agent is invoked: D pre t+1 = T o (D t ,o t ), y t = E(D pre t+1 ,u t ), D t+1 = U(D pre t+1 ,y t ).(5) HereT o is the goal-level transition,Eis the bounded execution substrate, andUis the state update induced by execution results. This separation is central: graph runtimes execute local task logic, while the Dialogue Manager preserves goal continuity across interruptions. 7.1 Goal-Structure Invariants The model is useful only if the goal structure obeys explicit invariants. A production implementation should enforce at least the following: 1.Unique active goal. At most one goal has statusactivefor a session unless the system explicitly enters a parallel-goal mode. 2.Resumability of suspended goals. Every suspended goal must have a non-empty resumption contract or be marked blocked, abandoned, superseded, or failed. 3.Structure-registry consistency. Every identifier in the stack, tree, or graph must exist in the goal registry and refer to a non-terminal goal. 4.Frame ownership. Updates to task-frame fields must be attributed to a goal, agent, tool, or human decision. 5.Invalidation safety. Resuming a goal requires checking its invalidation conditions against newer dialogue events and global constraints. 6.Auditable transitions. Every operation that changes goal status, stack order, or resumption contract must be logged as a goal-level event. These invariants make the proposed abstraction operational rather than merely descriptive. They also provide concrete failure modes for evaluation: invalid resumes, stale frames, orphaned goals, silent overwrites, and unauditable handoffs. 8 Goal Stack, Goal Tree, or Goal Graph? The phrase goal stack is useful because many interruptions have call-stack semantics: the user suspends a primary goal, asks a bounded side question, and then returns to the suspended point. However, stack discipline is not universal. Table 5 contrasts the main structures because real conversations often contain multiple open objectives whose relationships are not purely last-in-first-out. For example, an event-registration goal may spawn venue-accessibility, catering-policy, hotel-logistics, invoice, and group-discount goals. Some are temporary side questions; others update constraints that affect the primary registration; others remain open independently. A strict stack captures the simplest case, but a tree or DAG better captures persistent subgoals, shared constraints, and non-local invalidation. The stronger architectural claim is therefore not that all conversations should be modeled as stacks. The claim is that conversational goals should be represented explicitly, and that the runtime should choose an appropriate goal structure. The progression is evolutionary: a stack is sufficient while interruptions are nested and last-in-first-out; a tree becomes necessary when a primary objective decomposes into durable subgoals; a 10 From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes Goal Layer lifecycle, structure, resumption, dependencies, invalidation Dialogue Layer state tracking, memory, goal policy, human-in-the-loop policy, audit Execution Layer LangGraph, ADK, CrewAI, AutoGen, Semantic Kernel, APIs, tools interprets and governs delegates bounded work observations and tool results state updates Figure 5: Three-layer separation for goal-oriented conversational architecture. GODR separates goal management, dialogue state and policy, and bounded execution instead of collapsing them into a single agent or graph controller. graph becomes necessary when goals share constraints, dependencies, approvals, or invalidation effects. In the rest of the paper, goal structure refers to this general family, with goal stacks treated as the minimal implementation. The GC-3 to GC-4 boundary is not merely a question of adding metadata to a tree. A goal tree assumes a dominant decomposition relation: each child goal belongs to one parent, and local metadata can usually be interpreted within that parent-child context. GC-4 breaks that assumption. A constraint, approval, tool result, or user revision may affect several goals across different branches, so correctness depends on non-tree edges: shared resources, dependency links, cross-goal consistency constraints, invalidation relations, and audit paths. Encoding these effects as ad hoc metadata on tree nodes would require application-specific propagation rules that are no longer local to the tree. GODR treats those propagation, consistency-checking, invalidation, and resumption rules as runtime semantics over an explicit goal graph. 9 Proposed Direction: Goal-Oriented Dialogue Runtime We propose a Goal-Oriented Dialogue Runtime (GODR) as an architectural layer above agent runtimes and graph runtimes. A goal-stack dialogue manager is the simplest instance of this model, but not the only one. GODR does not replace LangGraph or other frameworks. Instead, it defines the missing runtime entities that complex conversations require. 9.1 Architectural Layers A Goal-Oriented Dialogue Runtime separates three concerns that are often collapsed in modern agent examples. Figure 5 shows the resulting layer boundary: The Goal Layer owns the user’s evolving objectives. The Dialogue Layer interprets turns, maintains state, applies policies, and records decisions. The Execution Layer performs bounded reasoning and tool execution. This separation allows existing orchestration frameworks to remain useful without forcing them to encode the entire conversational lifecycle. 9.2 Goal Lifecycle A GODR requires an explicit lifecycle for each conversational objective. Table 6 defines the states a goal can occupy, distinguishes resumable suspension from blocking or cancellation, and identifies the terminal states that close or replace an objective. The central distinction is between goals that can safely return to a known point and goals that require a policy decision before continuing. A suspended goal preserves a resumption contract; a blocked, failed, abandoned, or superseded goal cannot simply be resumed without additional validation. 11 From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes Table 6: Proposed lifecycle states for interruptible conversational goals. StateMeaning createdA potential goal has been detected but not yet committed. activeThe goal currently controls the next conversational action. suspendedThe goal is not active but has a valid resumption contract. blockedThe goal requires external input, user clarification, human review, or system recovery. completedThe goal has reached its completion criteria. abandonedThe user or policy cancelled the goal. supersededAnother goal replaced it semantically. failedThe goal cannot safely continue. 9.3 Core Data Structures The lifecycle is implemented through a small set of runtime objects. This subsection sketches the minimal data structures needed to store goal identity, task-frame state, parent-child relations, execution bindings, resumption contracts, invalidation checks, and the session-level registry that keeps these objects consistent. class Goal: id: str type: str status: GoalStatus parent_id: str | None children: list[str] priority: int task_frame: dict local_memory: list[Event] active_agent: str | None active_graph: str | None resumption_contract: ResumptionContract | None completion_criteria: CompletionCriteria safety_policy: SafetyPolicy class ResumptionContract: graph_id: str node_or_checkpoint: str pending_action: str expected_user_input: str | None required_context_keys: list[str] invalidation_conditions: list[str] class DialogueState: active_goal_id: str | None goal_stack: list[str] goal_registry: dict[str, Goal] session_memory: dict global_constraints: dict last_user_intent: str | None 9.4 Goal Operations Model and Policy The goal operations form a small algebra over conversational objectives. The Goal Policy is the decision layer that determines how a user utterance changes the goal structure. It is the core control point of the runtime, and should not be treated as an unconstrained LLM router. A practical policy can be implemented as a hybrid neuro-symbolic controller: π(u t ,D t ) = argmax o∈O valid score(o,u t ,D t ),(6) 12 From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes Table 7: Goal-policy operations and minimal guards. OperationTypical triggerRequired guard continueUser answers the pending question or provides expected information. Active goal has a valid pending action. reviseUser changes a slot, constraint, date, destination, or preference. Revision does not invalidate completed irreversible actions. pushUser asks a side question or creates a child objective. Current goal can be suspended or remain concurrently open. switchUser changes to a sibling or independent goal.Target goal is active, suspended, or newly creatable. resumeUser asks to continue a previous objective.Resumption contract is valid under current constraints. popGoal reaches completion criteria.Terminal state and parent/previous goal are well defined. cancelUser cancels one or more objectives.Cancellation scope is unambiguous or confirmed. escalate Policy, uncertainty, or risk requires human review.Escalation target and affected goals are recorded. whereO valid is the subset of operations allowed by lifecycle constraints, business rules, safety policies, and goal-structure invariants. The scoring function may be produced by an LLM classifier, a learned ranker, symbolic rules, or a combination of these. This formulation is compatible with learned decision models, including reinforcement-learning-based policies, whereO valid acts as a symbolic action mask that restricts candidate operations to transitions satisfying lifecycle constraints, safety guards, and conversational invariants. Crucially, symbolic constraints should filter or veto operations that would violate resumability, frame ownership, invalidation safety, or human-in-the-loop requirements. In systems terms, the Goal Policy acts as the scheduler for conversational objectives. It determines which goal receives control on a turn, which goal is suspended, which suspended goal can be resumed, and which operation must be blocked because it would violate lifecycle invariants. This scheduling role should be separated from language understanding and from policy optimization: an LLM or learned policy may propose candidate operations, but the runtime must enforce admissibility through typed state, guards, and audit requirements. The operations in Table 7 are intentionally small: they are the primitive transformations from which higher- level conversational behavior is composed. This formulation separates interpretation from permission. An LLM may infer that the user wants to resume event registration, but the runtime must still verify that the event-registration goal has a valid resumption contract, that newer turns have not invalidated its frame, and that no human approval is pending. This prevents plausible conversational behavior from bypassing operational correctness. 9.5 Turn-Level Algorithm Algorithm 1 summarizes the turn-level control loop. The key point is that the goal-level transition happens before any graph runtime or tool agent is invoked. 10 Design Principles A Goal-Oriented Dialogue Runtime should follow seven design principles: 1. Separate agent identity from goal identity. The active agent may change often; the active goal must remain stable unless explicitly revised. 2. Make interruption explicit. A side question should not silently overwrite the main goal state. 3.Persist resumption contracts, not only chat history. A resumable system needs a compact representation of where and how to continue. 4. Use graphs for bounded execution, not as the only representation of the whole conversation. 5. Treat state as a schema, not a dictionary. Keys need ownership, lifecycle, validation, and migration rules. 6.Keep human-in-the-loop decisions at the goal-policy level when they affect business decisions, and inside subgraphs when they affect local tool execution. 7.Prefer semantic transitions over complete edge enumeration. The policy should classify goal operations, not maintain N 2 edges. 13 From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes Algorithm 1 Goal-Oriented Turn Handling Require: user utterance u t , dialogue state D t Ensure: system response r t and updated dialogue state D t+1 1: I t ← Understand(u t ,D t ) 2: o t ← GoalPolicy(u t ,I t ,D t ) 3: D pre t ← ApplyGoalOperation(o t ,D t ) 4: if o t = Continue then 5: g t ← ActiveGoal(D pre t ) 6: else if o t = Push then 7: g active ← ActiveGoal(D pre t ) 8: D pre t ← SuspendIfNeeded(g active ,D pre t ) 9: g t ← CreateGoal(o t .goalType,D pre t ) 10: else if o t = Resume then 11: g t ← ResumeGoal(o t .goalId,D pre t ) 12: else if o t = Pop then 13: D pre t ← CompleteActiveGoal(D pre t ) 14: g t ← SelectReturnGoal(D pre t ) 15: else if o t = Cancel then 16: D pre t ← CancelGoals(o t .scope,D pre t ) 17: g t ← SelectRecoveryGoal(D pre t ) 18: else 19: g t ← EscalateOrClarify(o t ,D pre t ) 20: end if 21: y t ← RunExecutionRuntime(g t ,u t ,D pre t ) 22: D t+1 ← UpdateGoalAndDialogueState(y t ,D pre t ) 23: r t ← GenerateResponse(y t ,D t+1 ) 24: return (r t ,D t+1 ) GODR should also have a clear non-use criterion. It should not be introduced when a single workflow graph already owns the user journey, interruptions are shallow, and resumption does not require goal-level auditability. In those cases, conventional workflow orchestration, root graphs, or simple dialogue stacks are usually easier to implement and maintain. 11 Evaluation Protocol The central empirical hypothesis is that explicit goal-oriented runtime management improves robustness and maintainability in multi-domain conversations with interruptions, without replacing graph runtimes for bounded task execution. A strong evaluation should compare four systems under the same domains, tools, and language model: (i) a flat finite-state or router baseline, (i) a root graph with subgraphs, (i) a supervisor-agent architecture with shared state, and (iv) the proposed Goal-Oriented Dialogue Runtime layered above the same graph or agent runtime. The benchmark should contain scripted and adversarial multi-objective dialogues across at least three domains. Each dialogue should include a primary goal, one or more side goals, interruptions, corrections, cancellations, resumptions, and invalidating events. For example, an event-registration dialogue may suspend registration for venue accessibility, resume the registration, revise the session date, ask about dietary policy, invalidate an earlier seat hold, and then request an invoice. Gold annotations should include active goal, suspended goals, task-frame values, expected resumption point, terminal goal statuses, and human-in-the-loop decisions when present. The evaluation section should therefore be read as an experimental protocol for future implementations rather than as empirical evidence for performance claims. A minimal protocol would fix the language model, tools, domain APIs, and user scripts across all baselines, then vary only the dialogue-control architecture. Each run should emit a machine-readable trace of goal operations, task-frame updates, tool calls, and final responses so that conversational continuity can be scored independently of fluency. A future benchmark, which we call GoalBench, should isolate goal-continuity failures rather than general language quality. It can be organized around the five scenario families listed in Table 8: 14 From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes Table 8: Minimal reproducible scenarios for evaluating goal continuity. ScenarioInterruption patternExpected invariantFailure Event registrationVenue, dietary, and invoice side goals interrupt session selection. Registration resumes at the missing session slot with prior constraints preserved. Lost goal or stale frame. Procurement approvalBudget, vendor, and policy goals remain open with dependencies. Purchase request cannot resume after a blocking approval is invalidated. Invalid resume. Travel bookingHotel and flight goals share dates and destination constraints. Revising dates updates dependent frames or marks them stale. Silent overwrite. Customer supportTroubleshooting is interrupted by warranty, account, and escalation checks. Escalation preserves the failed diagnostic step and audit trail. Missing handoff log. Personal assistantCalendar, reminder, and email goals are interleaved. Completed and suspended goals remain distinguishable after topic switches. Status confusion. Table 9: Evaluation dimensions and directional targets for Goal-Oriented Dialogue Runtimes. DimensionMetric or evidenceTarget Resumption robustnessSuccessful return to the correct pending action after side goals and interruptions. Higher Goal-state accuracyAgreement with gold active, suspended, completed, abandoned, and superseded labels. Higher Frame consistencySlot and constraint correctness after interruptions, revisions, and invalidations.Higher Invalid resume rateAttempts to resume stale, contradicted, or policy-invalid goals.Lower Transition complexityNumber of explicit graph edges or routing rules needed to add a new domain. Lower Audit completenessFraction of goal status changes and resumption-contract updates reconstructable from logs. Higher Task successCompletion rate for primary and secondary goals under identical tool availability. Higher 1.Single interruption. A primary goal is suspended by one side question and must resume at the exact pending action. 2. Nested interruption. A side goal is itself interrupted before the original goal resumes. 3.Goal revision. The user changes a constraint, slot, or preference while preserving the broader objective. 4. Goal invalidation. A later utterance or tool result invalidates a suspended goal’s resumption contract. 5.Concurrent goals. Multiple goals remain open and must be scheduled, updated, or closed without silent overwrites. GoalBench would allow systems to be compared by goal-state accuracy, resumption correctness, invalid resume rate, and audit completeness, independently of surface response fluency. Table 9 maps these continuity failures to measurable evaluation dimensions. This protocol deliberately separates conversational correctness from model fluency. The key question is not whether an LLM can produce a plausible next answer, but whether the runtime preserves the correct goal structure over long, interruptible interactions. 12 Research Agenda The proposed architecture leads to a focused research agenda: •Can goal-oriented runtime management reduce transition explosion compared with graph-only orchestration in multi-domain conversations? • What is the minimal set of lifecycle states needed to represent interruptible conversational goals? •When should an utterance create a child goal, switch to a sibling goal, revise the current goal, or resume a previous one? • How can resumption contracts be made framework-neutral across LangGraph, ADK, Semantic Kernel, CrewAI, and other runtimes? • Can LLMs reliably classify goal operations, or is a hybrid symbolic/neural policy required? • How should human-in-the-loop decisions be represented when they affect suspended goals? 15 From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes Goal Registry active, suspended, terminal goals Goal Policy continue, push, resume, revise, cancel Dialogue State task frames, memory, constraints Goal Store persistence, audit, resumption contracts GODR runtime services Runtime Adapter LangGraph / ADK / CrewAI / AutoGen / Semantic Kernel / APIs delegates results / traces Figure 6: Reference implementation architecture for GODR. The runtime owns goal registry, policy, state, persistence, audit, and resumption contracts while delegating bounded execution through adapters. 13 Reference Implementation Architecture A reference implementation does not require replacing the execution framework. It can be built as a thin runtime layer with explicit ownership of goal state and adapter-based delegation to existing graph or agent systems. Under this interpretation, the execution runtime performs bounded computation, while GODR provides operating-system-like services for conversational objectives [11]: registry, scheduling, persistence, context switching, and audit. Figure 6 maps these services to implementation components. The main implementation boundary is ownership: the Goal Store owns durable goal state and resumption contracts; the execution runtime owns local graph checkpoints, tool calls, and domain workflows. This prevents duplicated state while allowing existing frameworks to remain the execution substrate. 14 Minimal Viable Architecture Before building a complex framework, a pragmatic prototype can be implemented with five components: 1. A typed DialogueState object stored per session or thread. 2. A goal registry with active, suspended, completed, and abandoned goals. 3. A smallGoalPolicyclassifier that emits operations:continue,push,pop,resume,revise,cancel, and escalate. 4.AGraphRuntimeadapter that invokes LangGraph subgraphs or other agents using the selected goal context. 5. An audit log that records every goal operation and resumption contract change. The minimal prototype can be specified as a thin middleware loop rather than a new agent framework. It intercepts each user turn, updates the goal registry, selects a goal operation, delegates bounded execution to the selected runtime adapter, and persists both the resulting task-frame updates and the goal-level transition. Table 10 states the corresponding implementation contract. The corresponding implementation sketch is deliberately small. A prototype can treat GODR as middleware around an existing graph or agent runtime: def handle_turn(user_turn: str, state: DialogueState) -> Response: intent = understand(user_turn, state.visible_history) operation = goal_policy.select(intent, state.goal_registry) state = apply_goal_operation(operation, state) 16 From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes Table 10: Minimal implementation contract for a Goal-Oriented Dialogue Runtime. ComponentResponsibilityInput / outputOwned state DialogueStateCarries session context, global constraints, and visible history. User turn and runtime observations / updated session state. History, constraints, shared context. GoalRegistryMaintains active, suspended, terminal, and blocked goals. Goal operations / updated goal structure. Goal identifiers, statuses, parent and dependency links. GoalPolicySelects lifecycle operations under symbolic guards. User turn plus current state / operation such aspushorresume. Policy rules, classifiers, validation constraints. RuntimeAdapterDelegates bounded work to graphs, tools, or agents. Selected goal context / tool results and local execution traces. Adapter configuration, not durable goal state. AuditLogRecords goal-level decisions and resumption changes. Lifecycle transition events / reconstructable trace. Operation and resumption history. goal = state.active_goal() if goal is None: return ask_clarification(state) result = runtime_adapter.invoke( graph_id=goal.active_graph, context=goal.task_frame, checkpoint=goal.resumption_contract.node_or_checkpoint, ) state = merge_result(goal.id, result, state) audit_log.record(operation, goal.id, result.trace_id) return render_response(result, state) 14.1 Example: Event Registration Assistant Figure 7 revisits the event-registration example as a minimal stack trace: the runtime pushes the registration goal, suspends it for a side question, completes the side goal, and resumes the original pending action. 14.2 Emerging GC-4 Scenarios The GC-4 regime is not intended to describe every chatbot or every agent workflow. It appears when a conversational system must coordinate several user objectives that remain simultaneously live and whose constraints can affect one another across workflow boundaries. A single bounded workflow is typically GC-1; a workflow with resumable side questions is often GC-2; a multi-domain assistant that tracks several independent objectives may reach GC-3; GC-4 begins when those objectives share constraints, approvals, resources, deadlines, or invalidation conditions that require runtime consistency management. Three production-oriented scenarios illustrate the boundary. First, enterprise copilots often span procurement, approvals, vendor onboarding, budgeting, legal review, and reporting. A user may start a purchase request, ask about vendor eligibility, revise a budget constraint, and later request an invoice or approval status; these goals are not merely children of one tree, because a change in budget, vendor, or approval policy can propagate across several active objectives. Second, personal and professional digital assistants combine travel, calendar, registration, accommodation, dietary, accessibility, and expense goals. Changing a travel date may not invalidate hotel or event registration goals immediately, but it creates a cross-goal consistency obligation. Third, multi-agent business operations expose several specialized agents or workflows for customer support, finance, logistics, compliance, and human escalation. The hard problem is not only which agent acts next, but which business objective owns each partial result, which suspended objectives remain valid, and which consistency or audit checks must run before resumption. These scenarios do not imply that all enterprise assistants require GODR. They indicate where the architectural boundary becomes visible: when correctness depends on lifecycle ownership and cross-goal consistency rather than on a richer local workflow state alone. 14.3 Engineering Methodology The broader contribution of this paper is a methodology for selecting conversational architectures, not merely a proposal for one runtime. A systematic engineering process can proceed in five phases: 17 From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes Initial state: stack = [ ] User requests workshop registration push(EventRegistration) frame: event=AI Systems Workshop, date=next Friday, session=missing pending: ask_session_preference User asks about wheelchair access suspend(EventRegistration, resume_at=ask_session_preference) push(VenueAccessibility) frame: venue=workshop venue, topic=wheelchair_access System answers venue accessibility pop(VenueAccessibility) resume(EventRegistration) ask session preference again with context preserved Figure 7: Trace of the event-registration example. The runtime suspends the registration goal, serves the side question, and resumes the preserved pending action. 1.Characterize the conversation. Identify number of objectives, domain breadth, interruption freedom, resumption requirements, user corrections, human-in-the-loop points, and dependency structure. 2. Classify runtime complexity. Assign the system to a low, medium, high, or very high complexity regime based on objective multiplicity, interruption depth, and dependency coupling. 3. Select the dialogue architecture. Choose the simplest architecture that matches the observed goal complexity: FSM or workflow graph for bounded processes, goal stack for nested resumability, agenda or goal tree for independent concurrent goals, and GODR with a goal graph for GC-4 dependency and invalidation cases. 4. Select the execution engine. Map bounded task execution to LangGraph, ADK, CrewAI, AutoGen, Semantic Kernel, custom workflows, or conventional service orchestration. 5.Select the goal structure. Use a stack for nested interruptions, a tree for decomposed objectives, or a DAG for concurrently open and interdependent goals. This methodology reframes the design problem. Instead of asking which agent framework should own the whole conversation, the engineer first characterizes conversational complexity, then selects the minimal runtime abstraction that preserves correctness. GODR is therefore one point in a broader design space: excessive for simple single-process workflows, optional for shallow resumability, partially useful for GC-3 18 From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes agenda management, and justified when GC-4 dependencies, invalidations, and audit requirements become non-local. 15 Contributions, Scope, and Validity The four contributions stated in the introduction can be grouped into two broader claims. First, the paper characterizes the design problem: multi-objective interruptible dialogue requires distinguishing active-agent selection and execution continuity from active-goal continuity, then selecting the minimal runtime abstraction for the observed goal-complexity level. This includes the taxonomic claim that stacks, trees, and goal graphs are not interchangeable implementation details; they correspond to different interruption, decomposition, dependency, and invalidation regimes. Second, the paper proposes GODR as the architecture for the GC-4 region, where goal lifecycles, goal-structure operations, task frames, interruption points, invalidation rules, resumption contracts, and audit requirements become necessary runtime concerns. The scope is intentionally architectural and methodological. The claim is not that GODR replaces graph runtimes, agent handoffs, retrieval systems, or business workflows. The narrower claim is that when users can freely suspend, revise, supersede, and resume interdependent objectives, goal continuity should be represented explicitly rather than inferred indirectly from agent identity, chat history, memory traces, or graph position. The proposed engineering methodology follows from this boundary: characterize the conversation first, classify goal complexity second, and only then choose the dialogue architecture, execution engine, and goal structure. Several limitations remain. Goal misclassification can corrupt intent continuity, and over-engineering is a risk for bounded workflows where root graphs plus subgraphs are sufficient. Resumption contracts require invalidation rules because a suspended goal may no longer be valid after later user actions. Framework integration must avoid duplicated ownership: GODR should own durable goal state, while graph runtimes should own local checkpoints and tool execution state. The paper is primarily a conceptual systems paper. It does not provide a production implementation or controlled ablation study, and there is not yet a widely accepted benchmark for interruptible multi-objective conversational continuity. Existing task-oriented dialogue benchmarks emphasize slot filling, intent accuracy, or task completion more than goal suspension, resumption, cross-goal invalidation, and auditability. The proposed runtime objects and metrics should therefore be read as a design hypothesis and evaluation agenda, not as a measured performance claim. Future work should validate the separation through reference implementations, benchmark tasks, ablation studies, and longitudinal maintainability analyses. 16 Conclusion This work argues for a shift in abstraction in conversational AI systems. While graph-based orchestration is highly effective for process-driven interactions, it becomes increasingly difficult to maintain conversational continuity when multiple user objectives remain active, can be suspended and resumed, share constraints, or invalidate one another. The proposed Goal-Oriented Dialogue Runtime (GODR) reintroduces explicit goal management as a first-class runtime concern, extending principles found in mature pre-LLM dialogue systems to modern graph- and agent-based architectures. Rather than treating goals as incidental attributes of execution, GODR models them as explicit operational entities with lifecycles, ownership, interruption semantics, resumption contracts, and dependency structures. The central architectural principle is not to replace existing execution frameworks, but to position them correctly. Graph runtimes, agents, tools, and workflow engines remain responsible for bounded task execution. GODR operates at a different level of abstraction: preserving objective continuity across interruptions, agent changes, and evolving conversational contexts. More broadly, the paper suggests that conversational continuity should not be inferred indirectly from agents, memory traces, or execution-graph position alone. It should be represented explicitly through goal structures with lifecycle semantics. In this view, existing orchestration approaches primarily model execution continuity, whereas GODR models objective continuity. 19 From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes Acknowledgements The author acknowledges the Laboratorio de Innovación Aplicada (L2IA) at Minsait (Indra Group) for fostering an environment that encourages scientific exploration in AI systems, distributed runtimes, and applied agentic infrastructures. References [1]Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik R. Narasimhan, and Yuan Cao. ReAct: Synergizing reasoning and acting in language models. In International Conference on Learning Representations, 2023. URL https://openreview.net/forum?id=WE_vluYUL-X. [2]Raphael Shu, Elman Mansimov, Tamer Alkhouli, Nikolaos Pappas, Salvatore Romeo, Arshit Gupta, Saab Mansour, Yi Zhang, and Dan Roth. Dialog2API: Task-oriented dialogue with api description and example programs, 2022. URL https://arxiv.org/abs/2212.09946. [3]LangChain. Multi-Agent Systems Documentation. LangChain Documentation, 2026. URL https: //docs.langchain.com/oss/python/langchain/multi-agent. Technical documentation. Accessed 2026-06-15. [4] Google Developers Blog. Developer’s Guide to Multi-Agent Patterns in ADK. Google Developers Blog, 2026. URL https://developers.googleblog.com/developers-guide-to-multi-agent-patterns-in-adk/. Technical blog. Accessed 2026-06-15. [5]Microsoft. Microsoft Agent Framework Overview. Microsoft Learn, 2026. URL https://learn.microsoft. com/en-us/agent-framework/overview/. Technical documentation. Accessed 2026-06-15. [6]OpenAI. OpenAI Agents SDK Documentation. OpenAI Documentation, 2026. URL https://openai.git hub.io/openai-agents-python/. Technical documentation. Accessed 2026-06-15. [7]LangChain. LangGraph Subgraphs Documentation. LangChain Documentation, 2026. URL https: //docs.langchain.com/oss/python/langgraph/use-subgraphs. Technical documentation. Accessed 2026-06-15. [8] LangChain. Handoffs Documentation. LangChain Documentation, 2026. URL https://docs.langchain.c om/oss/python/langchain/multi-agent/handoffs. Technical documentation. Accessed 2026-06-15. [9]Google Cloud. Remember This: Agent State and Memory with ADK. Google Cloud Blog, 2026. URL https://cloud.google.com/blog/topics/developers-practitioners/remember-this-agent-state-and-memor y-with-adk. Technical blog. Accessed 2026-06-15. [10]Bin Xu. Ai agent systems: Architectures, applications, and evaluation. arXiv preprint arXiv:2601.01743, 2026. [11] Mariano Garralda-Barrio. Governed evolution of agent runtimes through executable operational cognition, 2026. URL https://arxiv.org/abs/2605.27328. [12]Dan Bohus and Alexander I. Rudnicky. The RavenClaw dialog management framework: Architecture and systems. Computer Speech & Language, 23(3):332–361, 2009. doi:10.1016/j.csl.2008.10.001. URL https://w.cs.brandeis.edu/~cs115/CS115_docs/Ravenclaw.pdf. [13] Microsoft. About Component and Waterfall Dialogs. Microsoft Learn, 2026. URL https://learn.micr osoft.com/en-us/azure/bot-service/bot-builder-concept-waterfall-dialogs. Technical documentation. Accessed 2026-06-15. [14] Staffan Larsson and David R. Traum. Information state and dialogue management in the TRINDI dialogue move engine toolkit. Natural Language Engineering, 6(3–4):323–340, 2000. doi:10.1017/S1351324900002539. [15]Jason D. Williams and Steve Young. Partially observable Markov decision processes for spoken dialog systems. Computer Speech & Language, 21(2):393–422, 2007. doi:10.1016/j.csl.2006.06.008. [16] Steve Young, Milica Gasic, Blaise Thomson, and Jason D. Williams. POMDP-based sta- tistical spoken dialog systems: A review. Proceedings of the IEEE, 101(5):1160–1179, 2013. doi:10.1109/JPROC.2012.2225812. [17]Dan Bohus and Alexander I. Rudnicky. RavenClaw: Dialog management using hierarchical task decomposition and an expectation agenda. In Proceedings of Eurospeech, 2003. URL https://w.isca-a rchive.org/eurospeech_2003/bohus03_eurospeech.pdf. 20 From Task-Guided Conversational Graphs to Goal-Oriented Dialogue Runtimes [18]Microsoft. Dialogs in the Bot Framework SDK. Microsoft Learn, 2026. URL https://learn.microsoft.co m/en-us/azure/bot-service/bot-builder-concept-dialog. Technical documentation. Accessed 2026-06-15. [19]Matthew Henderson, Blaise Thomson, and Jason D. Williams. The second dialog state tracking challenge. In Proceedings of the 15th Annual Meeting of the Special Interest Group on Discourse and Dialogue, pages 263–272, 2014. doi:10.3115/v1/W14-4337. URL https://aclanthology.org/W14-4337/. [20]Paweł Budzianowski, Tsung-Hsien Wen, Bo-Hsiang Tseng, Iñigo Casanueva, Stefan Ultes, Osman Ramadan, and Milica Gasic. MultiWOZ: A large-scale multi-domain wizard-of-oz dataset for task-oriented dialogue modelling. In Proceedings of the 2018 Conference on Empirical Methods in Natural Language Processing, pages 5016–5026, 2018. doi:10.18653/v1/D18-1547. URL https://aclanthology.org/D18-1547/. [21]Abhinav Rastogi, Xiaoxue Zang, Srinivas Sunkara, Raghav Gupta, and Pranav Khaitan. Towards scalable multi-domain conversational agents: The schema-guided dialogue dataset. In Proceedings of the AAAI Conference on Artificial Intelligence, volume 34, pages 8689–8696, 2020. doi:10.1609/aaai.v34i05.6394. URL https://ojs.aaai.org/index.php/AAAI/article/view/6394. [22]Google Research. Introducing the Schema-Guided Dialogue Dataset for Conversational Assistants. Google Research Blog, 2026. URL https://research.google/blog/introducing-the-schema-guided-dialogue-datas et-for-conversational-assistants/. Technical blog. Accessed 2026-06-15. [23]Jacob Andreas et al. Task-oriented dialogue as dataflow synthesis. Transactions of the Association for Computational Linguistics, 8:556–571, 2020. doi:10.1162/tacl_a_00333. URL https://direct.mit.edu/tac l/article/doi/10.1162/tacl_a_00333/96470/Task-Oriented-Dialogue-as-Dataflow-Synthesis. [24]Malik Ghallab, Dana Nau, and Paolo Traverso. Automated Planning: Theory and Practice. Morgan Kaufmann, 2004. [25]Kutluhan Erol, James Hendler, and Dana S. Nau. HTN planning: Complexity and expressivity. In Proceedings of the Twelfth National Conference on Artificial Intelligence, pages 1123–1128, 1994. URL https://cdn.aaai.org/AAAI/1994/AAAI94-173.pdf. [26]Kutluhan Erol, James Hendler, and Dana S. Nau. Complexity results for HTN planning. Annals of Mathematics and Artificial Intelligence, 18(1):69–93, 1996. doi:10.1007/BF02136183. [27] Michael E. Bratman. Intention, Plans, and Practical Reason. Harvard University Press, 1987. [28]Anand S. Rao and Michael P. Georgeff. BDI agents: From theory to practice. In Proceedings of the First International Conference on Multi-Agent Systems, pages 312–319, 1995. [29]Microsoft. Semantic Kernel Agent Framework. Microsoft Learn, 2026. URL https://learn.microsoft.co m/en-us/semantic-kernel/frameworks/agent/. Technical documentation. Accessed 2026-06-15. [30] Microsoft. Semantic Kernel Agent Orchestration. Microsoft Learn, 2026. URL https://learn.microsoft.co m/en-us/semantic-kernel/frameworks/agent/agent-orchestration/. Technical documentation. Accessed 2026-06-15. [31]CrewAI. Flows Documentation. CrewAI Documentation, 2026. URL https://docs.crewai.com/en/conce pts/flows. Technical documentation. Accessed 2026-06-15. [32]CrewAI. Mastering Flow State Management. CrewAI Documentation, 2026. URL https://docs.crewai. com/en/guides/flows/mastering-flow-state. Technical documentation. Accessed 2026-06-15. [33] Amazon Web Services. Use Multi-Agent Collaboration with Amazon Bedrock Agents. Amazon Bedrock Documentation, 2026. URL https://docs.aws.amazon.com/bedrock/latest/userguide/agents-multi-agent -collaboration.html. Technical documentation. Accessed 2026-06-15. [34]AutoGen. Agent and Multi-Agent Applications. AutoGen Documentation, 2026. URL https://microsoft. github.io/autogen/stable/user-guide/core-user-guide/core-concepts/agent-and-multi-agent-applicati on.html. Technical documentation. Accessed 2026-06-15. 21