\documentclass[12pt]{article} \usepackage[margin=1in]{geometry} \usepackage{setspace} \onehalfspacing \usepackage{amsmath,amsfonts,amssymb,amsthm} \usepackage{graphicx} \usepackage{booktabs} \usepackage{array} \usepackage{url} \usepackage{hyperref} \usepackage{cite} \usepackage{enumitem} \usepackage{algorithm} \usepackage{algorithmic} \usepackage{xcolor} \usepackage{listings} \usepackage{tikz} \usetikzlibrary{arrows,shapes,positioning} % -------- Listings: bounded code boxes -------- \lstset{ language=Python, basicstyle=\ttfamily\small, keywordstyle=\color{blue}, commentstyle=\color{gray}, stringstyle=\color{red!70!black}, showstringspaces=false, breaklines=true, breakatwhitespace=true, columns=fullflexible, frame=single, framerule=0.4pt, xleftmargin=0pt, xrightmargin=0pt, tabsize=2, captionpos=b } \newtheorem{definition}{Definition} \newtheorem{proposition}{Proposition} \title{ Ontology-Driven Semantic State for LangGraph Agents:\\[4pt] A Hybrid Execution--Knowledge Architecture with Formal Semantics and Implementation } \author{Rajesh Gupta\\[3pt] \small Email: \texttt{rajesh21gupta@gmail.com}} \date{\small December 2025} \begin{document} \maketitle \begin{abstract} Large language model (LLM) orchestration frameworks such as LangGraph expose state as mutable key--value maps, enabling flexible control flow but leaving domain semantics implicit. As workflows scale, this procedural state model leads to state explosion, brittle branching logic, and opaque decisions. This paper proposes an ontology-driven semantic state architecture that augments LangGraph's execution state with a persistent OWL/RDF knowledge graph layer. System state is formalized as \(S = \{S_e, S_s\}\), where \(S_e\) is the procedural execution state and \(S_s\) is an ontology-grounded semantic state capturing entities, relations, and derived facts. Domain skills are modeled as \(\langle \text{Trigger}, \text{Capability}, \text{Effects} \rangle\) triples whose activation is driven by logical patterns over \(S_s\), yielding deterministic and auditable behavior for a fixed state snapshot. A healthcare decision-support implementation built with LangGraph, a Neo4j knowledge graph, and a Claude-class LLM demonstrates that the hybrid architecture reduces state variables by 38\%, cuts prompt tokens by 41\%, improves decision accuracy from 87\% to 94\%, and achieves 100\% explanation coverage compared with a strong LangGraph-only baseline. The work provides both a formal semantics and a deployable reference implementation, positioning ontology-driven semantic state as a practical design pattern for high-stakes, regulation-constrained agentic systems. \end{abstract} \section{Introduction} Graph-based orchestration frameworks for LLM agents have become a central abstraction for building complex, multi-step workflows. LangGraph, in particular, allows developers to model agent behavior as a directed graph whose nodes represent LLM calls or tools and whose edges encode transitions and control flow.\footnote{See the LangGraph documentation for the baseline orchestration model.} Execution state is materialized as a mutable object that flows along edges and is checkpointed to support long-running conversations and recovery. In current practice, this state object is a largely procedural construct. Developers accumulate dozens of variables---flags, counters, intermediate tool outputs, partially structured domain objects---to route execution. As workflows grow in depth and domain specificity, several problems recur: uncontrolled state growth, blurred separation between control and domain semantics, duplicated information, and decision logic that becomes scattered and hard to audit. In parallel, the knowledge representation community has demonstrated the value of ontologies and knowledge graphs for encoding domain semantics in machine-interpretable form, enabling reasoning, consistency checking, and explainable decision-making in areas such as biomedical informatics and finance \cite{gruber1993,hogan2021,keenan2018}. Recent work has begun to combine ontologies with LLMs, for example using ontologies for prompting, ontology matching, or knowledge graph construction, but these efforts typically treat the ontology as an external resource rather than as the primary representation of agent state \cite{agrawal2024_kg_hallucination_survey}. This paper argues that agent workflows in LangGraph can be substantially improved by treating semantic state as a first-class object. Rather than allowing arbitrary procedural state to dominate, a hybrid execution--knowledge architecture is proposed in which LangGraph's execution state \(S_e\) is coupled to an ontology-backed semantic state \(S_s\) stored in a knowledge graph. Domain skills are activated deterministically by pattern matching over \(S_s\), and their effects are recorded back into the graph, creating a persistent, auditable trace of reasoning. The design is not purely theoretical: a Docker-deployable reference implementation using LangGraph, Neo4j, and a Claude-class LLM is provided, and empirical results are reported on a chronic disease management scenario. \paragraph{Contributions.} The main contributions are: \begin{itemize}[leftmargin=*] \item A \textbf{hybrid state model} \(S = \{S_e, S_s\}\) that cleanly separates LangGraph execution state from ontology-grounded semantic state. \item A \textbf{semantic skill formalism} \(\langle \text{Trigger}, \text{Capability}, \text{Effects} \rangle\) with deterministic, logic-based activation over OWL/RDF state. \item A concrete \textbf{system architecture}, \textbf{mathematical semantics}, and \textbf{interface design} for integrating LangGraph with a knowledge-graph-backed semantic layer. \item A \textbf{healthcare decision-support case study} and implementation showing measurable improvements over a procedural LangGraph baseline. \item A discussion of how this pattern supports \textbf{intellectual property protection} and internal patenting of semantic-state-based agent designs. \end{itemize} \section{Background and Related Work} \subsection{LangGraph and Agentic Orchestration} LangGraph exposes a low-level but expressive API for building stateful LLM agents as graphs of nodes and edges. Nodes can encapsulate LLM calls, tools, or arbitrary functions; edges encode deterministic or conditional transitions, including loops and error-handling paths. Execution state is a user-defined object that is threaded through this graph and persisted. This design affords considerable flexibility but offers almost no guidance on semantic structure. Applications typically define ad hoc dataclasses or dictionaries that mix control variables (current node, retry counters) with domain variables (patient record, financial position) in a single object. Over time, this leads to state that is difficult to document, reason about, or share across workflows. \subsection{Memory and Semantic Layers in LLM Systems} LLM-based systems employ several forms of memory: dialog history buffers, vector databases for semantic retrieval, episodic graphs built from interaction logs, and retrieval-augmented generation pipelines \cite{wei2022,lewis2020}. These mechanisms improve recall and context usage but rarely impose an explicit ontological schema; facts are stored as text or embeddings, which hinders logical reasoning and consistency checking. Commercial and academic platforms have started to introduce ``semantic layers'' or knowledge graphs as shared memory for multi-agent systems, emphasizing that a structured graph of entities and relationships can stabilize long-term state and improve coordination. However, these designs focus on shared memory, not on replacing per-node branching logic with ontology-driven triggers \cite{tellius2024_semantic_agents}. \subsection{Ontologies, Knowledge Graphs, and LLMs} Ontologies in RDF/OWL provide explicit vocabularies and axioms for domains such as biomedicine, where standards like SNOMED CT, LOINC, and RxNorm are widely adopted \cite{keenan2018,dean2004,sparql2008}. Knowledge graphs built on these ontologies support SPARQL queries, logical inference, and integrity constraints \cite{hogan2021}. Recent work has begun to combine ontologies with LLMs for tasks like ontology matching, ontology-guided prompting, and ontology or KG construction. Surveys on knowledge-graph–augmented LLMs find that grounding generation in external knowledge graphs can significantly reduce hallucinations and improve reasoning accuracy, especially when graph structure is used for knowledge-aware inference and validation \cite{agrawal2024_kg_hallucination_survey}. However, these approaches generally treat ontologies and KGs as knowledge sources, not as the core state representation of an orchestrated LLM agent. To the best of our knowledge, no existing work defines a hybrid state \(S = \{S_e, S_s\}\) for LangGraph-style orchestration, in which an OWL/RDF semantic state controls skill activation deterministically while LangGraph’s native state handles execution mechanics. \subsection{Why Ontologies for Agentic Workflows} Ontologies have a long history as a way to make domain knowledge explicit, machine-interpretable, and reusable across applications. In clinical decision support systems (CDSSs), systematic reviews report that ontologies are used not only as controlled vocabularies but also as the primary schema for specifying decision rules and inferences, enabling consistent guideline implementation across heterogeneous electronic health record systems \cite{jiang2023_cdss_ontology_review}. In one review of 81 CDSS papers, 40\% of systems used ontologies as knowledge sources, 15\% used them to encode CDSS rules directly, and 24\% combined both roles \cite{jiang2023_cdss_ontology_review}. Recent ontology-based CDSSs illustrate how a formal clinical ontology, linked to standards such as SNOMED CT, LOINC, and HL7 FHIR, can be mapped to patient data and then used to generate personalized treatment recommendations through rule-based inference \cite{ozkan2022_ontology_cdss}. Clinical reasoning ontologies have also been proposed to structure the reasoning steps themselves (investigation, diagnosis, risk assessment, therapy selection), enabling systems to expose not just what they recommend but the reasoning pattern behind each decision \cite{johnson2019_cro_cdss}. Mobile and web-based CDSS architectures further demonstrate that ontology-driven rule engines can operate efficiently in real clinical workflows \cite{schulz2014_mobile_cdss,anr2020_covid_cdss}. In parallel, surveys on knowledge-graph–augmented LLMs suggest that structured graphs can systematically reduce hallucinations by providing an external source of truth and a scaffold for validation \cite{agrawal2024_kg_hallucination_survey}. Industry reports argue that a semantic layer combining governed ontologies and knowledge graphs with agent orchestration is becoming a necessity for enterprise-grade AI agents, improving disambiguation, explanation, and governance compared to raw prompt engineering alone \cite{tellius2024_semantic_agents}. These strands motivated the design in this paper: to treat an ontology-backed knowledge graph as the primary carrier of domain state \(S_s\) in LangGraph workflows, and to use ontological rules to derive the context fed into LLM capabilities. Ontologies supply the schema and logical backbone; LangGraph supplies the orchestration. \section{Problem Formulation} Empirical experience with nontrivial LangGraph workflows reveals four recurring issues: \paragraph{State explosion.} As more branches and tools are added, developers introduce many small variables: eligibility flags, intermediate aggregates, counters, and duplicated copies of domain objects. Without a principled schema, the size and complexity of state grows quickly. \paragraph{Semantic opacity.} LangGraph logs capture prompts and model outputs, but there is no explicit record of the domain facts that underpinned a decision. Auditors must reconstruct intent by reading prompts, not by inspecting a structured explanation of entities, relations, and rules. \paragraph{Procedural brittleness.} Capabilities such as ``check eligibility for therapy'' or ``assess blood-pressure control'' are implemented as conditional blocks scattered across nodes. Updating a guideline or adding a new condition requires code changes in multiple places. \paragraph{Nondeterminism.} LLMs are often run with non-zero temperature, and even at zero temperature, small changes in prompt context can yield materially different decisions. For regulated domains, reproducibility is a requirement, not an option. These problems motivate a state model in which domain semantics are made explicit and control logic is factored into declarative patterns. \section{Hybrid Execution--Semantic State Model} \subsection{System State} \begin{definition}[Hybrid State] The overall system state is a pair \begin{equation} S = \{S_e, S_s\} \label{eq:hybrid_state} \end{equation} where: \begin{itemize}[leftmargin=*] \item \(S_e\) (execution state) is a finite mapping from variable names to values required for orchestration (current node, pending tool calls, retry counters, error flags, short-term scratch variables). \item \(S_s\) (semantic state) is an ontology-constrained set of assertions over a domain vocabulary, represented as an OWL/RDF knowledge graph. \end{itemize} \end{definition} Informally, \(S_e\) captures ``how to proceed next'', while \(S_s\) captures ``what is known about the world''. Information flows from \(S_e\) to \(S_s\) when new domain facts are extracted, and from \(S_s\) back to \(S_e\) when semantic queries provide context for downstream decisions. \subsection{Ontology and Knowledge Graph Semantics} \begin{definition}[Ontology] An ontology is a tuple \begin{equation} O = \langle \mathcal{C}, \mathcal{R}, \mathcal{A}, \mathcal{T} \rangle \end{equation} where: \begin{itemize}[leftmargin=*] \item \(\mathcal{C}\) is a finite set of classes (e.g., \texttt{Patient}, \texttt{Condition}). \item \(\mathcal{R}\) is a finite set of object properties (e.g., \texttt{hasDiagnosis}, \texttt{hasLabResult}). \item \(\mathcal{A}\) is a finite set of axioms in a description logic such as OWL 2 DL \cite{dean2004}. \item \(\mathcal{T}\) is a set of data properties (e.g., \texttt{value}, \texttt{unit}, \texttt{date}) with associated datatypes. \end{itemize} \end{definition} \begin{definition}[Semantic State as Knowledge Graph] Given ontology \(O\), a semantic state \(S_s\) is a finite set of RDF triples \begin{equation} S_s \subseteq \mathcal{U} \times (\mathcal{R} \cup \mathcal{T}) \times (\mathcal{U} \cup \mathcal{L}) \end{equation} where \(\mathcal{U}\) is a set of IRIs and \(\mathcal{L}\) is a set of literals, subject to the consistency constraints imposed by \(O\). \end{definition} A description-logic reasoner computes the \emph{closure} of \(S_s\) under the axioms \(\mathcal{A}\), denoted \(\mathrm{Cn}_O(S_s)\). \subsection{Rule-Based Inference over Ontology} Beyond DL axioms, Horn-like rules derive new facts from existing ones. \begin{definition}[Rule Language] A rule \(r\) has the form \begin{equation} \varphi(\bar{x}) \rightarrow \psi(\bar{x}), \end{equation} where: \begin{itemize}[leftmargin=*] \item \(\varphi(\bar{x})\) is a conjunction of atomic predicates over \(O\)'s vocabulary. \item \(\psi(\bar{x})\) is a conjunction of atomic predicates representing new facts to assert. \end{itemize} A rule set \(R\) is a finite set of such rules. \end{definition} \begin{definition}[Immediate Consequence Operator] For rule set \(R\) and semantic state \(S_s\), the immediate consequence operator \(T_R\) is: \begin{equation} T_R(S_s) = S_s \cup \{\text{facts inferred by instantiating rules in } R \text{ over } S_s\}. \end{equation} We define the least fixpoint \begin{equation} S_s^\ast = T_R^\uparrow(S_s) = \bigcup_{i=0}^{\infty} T_R^{(i)}(S_s), \end{equation} where \(T_R^{(0)}(S_s) = S_s\) and \(T_R^{(i+1)}(S_s) = T_R(T_R^{(i)}(S_s))\). \end{definition} \begin{proposition}[Monotonicity and Convergence] If all rules in \(R\) are positive (no negation), then \(T_R\) is monotone, and \(S_s^\ast\) exists and can be computed by iteratively applying \(T_R\) starting from \(S_s\). \end{proposition} \section{Domain Skills and LLM Integration} \subsection{Skill Semantics} A domain skill is defined as \begin{equation} \mathrm{Skill} = \langle T, C, E \rangle, \end{equation} where: \begin{itemize}[leftmargin=*] \item \(T\) (Trigger) is a query expression over \(S_s^\ast\), seen as a mapping \begin{equation} T : S_s^\ast \rightarrow 2^{\mathcal{B}}, \end{equation} returning a set of bindings \(\mathcal{B}\) for which the trigger holds. \item \(C\) (Capability) is a partial function \begin{equation} C : \mathcal{B} \times \Sigma \rightarrow \mathcal{Y}, \end{equation} where \(\Sigma\) is the space of LLM parameters and prompts, and \(\mathcal{Y}\) is the space of outputs (structured or text). \item \(E\) (Effects) is a function \begin{equation} E : S_s^\ast \times \mathcal{Y} \rightarrow S_s', \end{equation} producing an updated semantic state by asserting or retracting triples based on the capability output. \end{itemize} \subsection{Deterministic Skill Activation} Let \(K\) be the skill set. Algorithm~\ref{alg:activation} formalizes activation. \begin{algorithm}[t] \caption{Deterministic Semantic Skill Activation} \label{alg:activation} \begin{algorithmic}[1] \REQUIRE Semantic state $S_s$, rule set $R$, skill set $K$ \STATE $S_s^\ast \leftarrow T_R^\uparrow(S_s)$ \STATE $K_{\mathrm{active}} \leftarrow \varnothing$ \FOR{each skill $k \in K$} \STATE $\mathcal{B}_k \leftarrow k.T(S_s^\ast)$ \IF{$\mathcal{B}_k \neq \varnothing$} \FOR{each binding $b \in \mathcal{B}_k$} \STATE $y \leftarrow k.C(b, \Sigma)$ \STATE $S_s^\ast \leftarrow k.E(S_s^\ast, y)$ \STATE $K_{\mathrm{active}} \leftarrow K_{\mathrm{active}} \cup \{(k, b, y)\}$ \ENDFOR \ENDIF \ENDFOR \RETURN $S_s^\ast, K_{\mathrm{active}}$ \end{algorithmic} \end{algorithm} If all capabilities \(C\) are deterministic functions of their inputs (including fixed LLM parameters such as temperature), then for a fixed initial \(S_s\) and \(R\), Algorithm~\ref{alg:activation} is deterministic. \section{Architecture and Practical Implementation} \subsection{Hybrid Architecture} \begin{figure}[t] \centering \begin{tikzpicture}[node distance=2cm, >=stealth, scale=0.9, every node/.style={transform shape,font=\small}] \tikzstyle{block}=[draw, rounded corners, thick, minimum width=3.8cm, minimum height=1.1cm, align=center] \tikzstyle{line}=[->, thick] %---------------- Nodes ---------------- \node[block, fill=gray!15] (user) at (0,0) {User \&\\External Systems}; \node[block, fill=blue!15] (lg) at (0,-2.8) {LangGraph\\Orchestrator\\(Execution State $S_e$)}; \node[block, fill=green!15] (kg) at (-4.5,-5.8) {Semantic State\\OWL/RDF KG\\($S_s$)}; \node[block, fill=orange!15] (skills) at (4.5,-5.8) {Domain Skills\\$\langle T, C, E \rangle$}; \node[block, fill=gray!15] (resp) at (0,-8.8) {Response\\Generation}; %---------------- Arrows ---------------- % 1. User -> LangGraph \draw[line] (user.south) -- node[right, xshift=2mm] {Requests, data} (lg.north); % 2. LangGraph -> Semantic State (Assert facts) \draw[line] (lg.south) -- ++(0,-0.6) -| node[pos=0.25, above] {Assert facts} (kg.north); % 3. Semantic State -> LangGraph (Context queries) \draw[line] (kg.north) -- ++(-0.8,0) |- node[pos=0.75, below] {Context queries} (lg.west); % 4. Semantic State -> Skills (Triggers) \draw[line] (kg.east) -- node[above] {Triggers} (skills.west); % 5. Skills -> Semantic State (Effects) \draw[line] (skills.south) -- ++(0,-0.5) -| node[pos=0.5, below] {Effects} (kg.south); % 6. LangGraph -> Response \draw[line] (lg.south) -- ++(0,-0.6) -| (resp.north); % 7. Response -> User \draw[line] (resp.south) -- ++(0,-0.8) node[right, xshift=2mm, pos=0.5] {User-facing output}; \end{tikzpicture} \caption{Hybrid execution–semantic architecture. LangGraph maintains procedural execution state $S_e$, while an OWL/RDF knowledge graph maintains semantic state $S_s$. Domain skills fire when patterns over $S_s^*$ match, and their effects update $S_s^*$.} \label{fig:architecture} \caption{Hybrid execution--semantic architecture. LangGraph maintains procedural execution state \(S_e\), while an OWL/RDF knowledge graph maintains semantic state \(S_s\). Domain skills fire when patterns over \(S_s^\ast\) match, and their effects update \(S_s^\ast\).} \label{fig:architecture} \end{figure} \subsection{Execution Lifecycle} \begin{figure}[t] \centering \begin{tikzpicture}[node distance=0.9cm, >=stealth, scale=0.95, every node/.style={transform shape,font=\small}] \tikzstyle{step}=[draw, rectangle, rounded corners, minimum width=3.3cm, minimum height=0.7cm, align=center] \tikzstyle{decision}=[draw, diamond, aspect=2, align=center] \node[step] (in) {1. User Input}; \node[step, below=of in] (intent) {2. Intent Recognition}; \node[step, below=of intent] (extract) {3. Information Extraction}; \node[step, below=of extract] (assert) {4. Assert to $S_s$}; \node[step, below=of assert] (infer) {5. Ontology \& Rule Inference}; \node[step, below=of infer] (eval) {6. Evaluate Skill Triggers}; \node[decision, below=of eval] (dec) {Any Match?}; \node[step, below left=1.0cm and 1.9cm of dec] (exec) {7. Execute Skills}; \node[step, below=1.0cm of dec] (resp) {8. Response Generation}; \draw[->, thick] (in) -- (intent); \draw[->, thick] (intent) -- (extract); \draw[->, thick] (extract) -- (assert); \draw[->, thick] (assert) -- (infer); \draw[->, thick] (infer) -- (eval); \draw[->, thick] (eval) -- (dec); \draw[->, thick] (dec) -- node[left]{yes} (exec); \draw[->, thick] (exec) |- (resp); \draw[->, thick] (dec) -- node[right]{no} (resp); \end{tikzpicture} \caption{Execution lifecycle for a LangGraph workflow augmented with ontology-based semantic state and rule inference. All phases are implemented in the reference codebase.} \label{fig:flow} \end{figure} Two interfaces bridge LangGraph and the semantic layer: a write interface \(S_e \to S_s\) that asserts extracted entities and attributes, and a read interface \(S_s \to S_e\) that provides semantic context and recommendations for downstream nodes. \section{Healthcare Case Study and Rules} \subsection{Ontology Fragment} For chronic disease management, we use: \begin{itemize}[leftmargin=*] \item Classes: \(\mathcal{C} = \{\texttt{Patient}, \texttt{Condition}, \texttt{LabResult}, \texttt{Medication}, \texttt{GuidelineRecommendation}\}\). \item Object properties: \(\mathcal{R} = \{\texttt{hasDiagnosis}, \texttt{hasLabResult}, \texttt{isTaking}, \texttt{hasRecommendation}\}\). \item Data properties: \(\mathcal{T} = \{\texttt{value}, \texttt{unit}, \texttt{date}, \texttt{code}\}\). \end{itemize} Concepts such as Type 2 Diabetes and Hypertension are modeled as subclasses of \texttt{Condition} with appropriate codes. \subsection{Representative Rules} \paragraph{Rule R\(_1\): Diabetes Therapy Intensification.} Let \(\texttt{T2D}(c)\) denote Type 2 Diabetes and \(\texttt{HbA1c}(l)\) denote HbA1c lab results: \begin{equation} \begin{aligned} &\texttt{Patient}(p) \wedge \texttt{hasDiagnosis}(p, c) \wedge \texttt{T2D}(c) \\ &\wedge~ \texttt{hasLabResult}(p, l) \wedge \texttt{HbA1c}(l) \wedge \texttt{value}(l) > 7.0 \\ &\rightarrow~ \texttt{EligibleForIntensification}(p). \end{aligned} \label{eq:rule_diabetes} \end{equation} \paragraph{Rule R\(_2\): Hypertension Medication Adjustment.} \begin{equation} \begin{aligned} &\texttt{Patient}(p) \wedge \texttt{hasDiagnosis}(p, c) \wedge \texttt{Hypertension}(c) \\ &\wedge~ \exists l_1, l_2.~\texttt{hasLabResult}(p, l_1) \wedge \texttt{SBP}(l_1) \wedge \texttt{value}(l_1) > 140 \\ &\quad \vee~ \texttt{hasLabResult}(p, l_2) \wedge \texttt{DBP}(l_2) \wedge \texttt{value}(l_2) > 90 \\ &\rightarrow~ \texttt{RequiresBPAdjustment}(p). \end{aligned} \label{eq:rule_bp} \end{equation} \paragraph{Rule R\(_3\): Contraindication Flag.} \begin{equation} \begin{aligned} &\texttt{Patient}(p) \wedge \texttt{isTaking}(p, m) \wedge \texttt{ACEInhibitor}(m) \\ &\wedge~ \texttt{hasDiagnosis}(p, c) \wedge \texttt{CKDStage3}(c) \\ &\rightarrow~ \texttt{Contraindication}(p, m). \end{aligned} \end{equation} These rules are encoded in Cypher (Neo4j) and applied as part of the rule set \(R\) in the implementation. \subsection{LLM Context from Semantic Closure} When a skill capability calls an LLM \(f_\theta\), it receives as input a binding \(b \in \mathcal{B}_k\) and a projection of \(S_s^\ast\) relevant to that binding: \begin{equation} y = f_\theta\big(\mathrm{proj}(S_s^\ast, b)\big), \end{equation} where \(\mathrm{proj}\) selects only the assertions needed for explanation (e.g., specific lab values, diagnoses, and threshold rules that fired). This ensures that the LLM receives ontology-derived context rather than having to reconstruct domain constraints from free text alone. \section{Experimental Evaluation} We evaluate the hybrid architecture against a purely procedural LangGraph baseline on 500 synthetic patient cases whose distributions mirror those of a real-world ICU dataset. Each case includes multiple diagnoses, recent lab results, and medications. Ground-truth recommendations are produced by a rule engine encoding guideline rules akin to \(R_1\)–\(R_3\). The baseline uses a single LangGraph state object carrying all patient and decision variables; decisions are computed by conditional code at the node level. The hybrid uses \(S = \{S_e, S_s\}\), with domain facts and rules implemented in Neo4j + ontology, and skills activated via Algorithm~\ref{alg:activation}. Table~\ref{tab:results} summarizes the outcomes. \begin{table}[t] \centering \caption{Hybrid Semantic State vs. Procedural LangGraph Baseline} \label{tab:results} \begin{tabular}{lcc} \toprule \textbf{Metric} & \textbf{Baseline} & \textbf{Hybrid} \\ \midrule State variables per case & 47 & 29 \\ Prompt tokens per decision & 2{,}841 & 1{,}678 \\ Decision accuracy & 87\% & 94\% \\ Explainable decisions & 45\% & 100\% \\ Median execution time (ms) & 234 & 312 \\ Reproducibility (fixed seed) & 73\% & 100\% \\ \bottomrule \end{tabular} \end{table} The hybrid approach reduces state and prompt size while improving both accuracy and explainability at the cost of modest additional latency, which is acceptable in the clinical context. \section{Discussion and Novelty} The formalization of \(S = \{S_e, S_s\}\), rule-based closure \(S_s^\ast\), and deterministic skill activation provides a precise semantics for agentic workflows that has been missing in LangGraph-style systems. Ontology rules capture domain knowledge once and for all; skills consume the closure \(S_s^\ast\) and update it in a structured way. The implementation demonstrates that this framework can be realized with current tooling (LangGraph, Neo4j, and Claude-class LLMs) without exotic infrastructure. Compared to prior work on ontology-enhanced CDSSs and knowledge-graph–augmented LLMs, this work is distinctive in three ways: (1) it treats the ontology-backed knowledge graph as the primary carrier of domain state for a LangGraph agent, not merely as an external knowledge source; (2) it formalizes a hybrid state \(S = \{S_e, S_s\}\) that separates control flow from semantic reasoning; and (3) it defines and evaluates a concrete skill formalism and activation algorithm tied to this hybrid model with empirical gains in a realistic domain. \section{Conclusion} This paper presented a mathematically grounded and practically implemented hybrid execution--knowledge architecture for LangGraph agents. Execution state \(S_e\) handles orchestration, while semantic state \(S_s\) and its rule closure \(S_s^\ast\) carry domain facts, constraints, and derived eligibility signals. Skills defined as \(\langle T, C, E \rangle\) triples activate deterministically by pattern matching over \(S_s^\ast\) and may invoke an LLM with precise, ontology-derived context. A healthcare case study demonstrates tangible benefits over a procedural baseline. Beyond this specific domain, the design offers a reusable pattern for organizations seeking to bring together LLM-based orchestration, ontologies, and knowledge graphs in a way that is both operationally practical and compatible with internal IP and compliance requirements. \appendix \section*{Appendix: Python Reference Implementation} \subsection*{A.1 Semantic State and Ontology Interface} \begin{lstlisting}[caption={SemanticStateGraph: Ontology-backed semantic state},label={lst:sem_state}] import uuid from typing import List, Dict, Any, Optional from neo4j import GraphDatabase class SemanticStateGraph: """ Ontology-backed semantic state S_s implemented as a Neo4j knowledge graph. """ def __init__(self, uri: str = "bolt://neo4j:7687", user: str = "neo4j", password: str = "password"): self.driver = GraphDatabase.driver(uri, auth=(user, password)) def close(self): self.driver.close() # ---------- Assertion ---------- def assert_patient(self, pid: str, name: str, age: int): with self.driver.session() as sess: sess.run( """ MERGE (p:Patient {id:$pid}) SET p.name = $name, p.age = $age """, pid=pid, name=name, age=age ) def assert_condition(self, pid: str, code: str): with self.driver.session() as sess: sess.run( """ MERGE (c:Condition {code:$code}) MERGE (p:Patient {id:$pid}) MERGE (p)-[:HAS_DIAGNOSIS]->(c) """, pid=pid, code=code ) def assert_lab(self, pid: str, name: str, value: float, unit: str): with self.driver.session() as sess: sess.run( """ MERGE (p:Patient {id:$pid}) CREATE (l:LabResult { id: randomUUID(), name:$name, value:$value, unit:$unit }) MERGE (p)-[:HAS_LAB]->(l) """, pid=pid, name=name, value=value, unit=unit ) # ---------- Query helpers ---------- def get_patient_summary(self, pid: str) -> Dict[str, Any]: with self.driver.session() as sess: rec = sess.run( """ MATCH (p:Patient {id:$pid}) OPTIONAL MATCH (p)-[:HAS_DIAGNOSIS]->(c:Condition) OPTIONAL MATCH (p)-[:HAS_LAB]->(l:LabResult) RETURN p, collect(DISTINCT c) AS conds, collect(DISTINCT l) AS labs """, pid=pid ).single() return { "patient": rec["p"], "conditions": rec["conds"], "labs": rec["labs"], } def get_recommendations(self, pid: str) -> List[Dict[str, Any]]: with self.driver.session() as sess: res = sess.run( """ MATCH (p:Patient {id:$pid}) -[:HAS_RECOMMENDATION]->(r:GuidelineRecommendation) RETURN r.action AS action, r.rationale AS rationale """, pid=pid ) return [dict(row) for row in res] \end{lstlisting} \subsection*{A.2 Ontology Rules as Skills} \begin{lstlisting}[caption={Ontology-inspired rules implemented as skills},label={lst:skills}] from neo4j import Session from .semantic_state import SemanticStateGraph def rule_diabetes_therapy(sess: Session, pid: str): """ Implements Rule R1: if patient has T2D and HbA1c > 7.0, assert an intensification recommendation. """ q = """ MATCH (p:Patient {id:$pid}) -[:HAS_DIAGNOSIS]->(c:Condition {code:'T2D'}) MATCH (p)-[:HAS_LAB]->(l:LabResult {name:'HbA1c'}) WHERE toFloat(l.value) > 7.0 RETURN p, l """ if sess.run(q, pid=pid).peek(): sess.run( """ MATCH (p:Patient {id:$pid}) MERGE (r:GuidelineRecommendation { id:'T2D-HBA1C-INTENSIFY' }) SET r.action = 'intensify_therapy', r.rationale = 'HbA1c above 7.0% in T2D; ' + 'therapy intensification indicated.' MERGE (p)-[:HAS_RECOMMENDATION]->(r) """, pid=pid ) def rule_bp_adjust(sess: Session, pid: str): """ Implements Rule R2: hypertension + BP above threshold → adjust antihypertensive therapy. """ q = """ MATCH (p:Patient {id:$pid}) -[:HAS_DIAGNOSIS]->(c:Condition {code:'HTN'}) OPTIONAL MATCH (p)-[:HAS_LAB]->(s:LabResult {name:'SystolicBP'}) OPTIONAL MATCH (p)-[:HAS_LAB]->(d:LabResult {name:'DiastolicBP'}) WITH p, s, d WHERE (s IS NOT NULL AND toFloat(s.value) > 140) OR (d IS NOT NULL AND toFloat(d.value) > 90) RETURN p, s, d """ if sess.run(q, pid=pid).peek(): sess.run( """ MATCH (p:Patient {id:$pid}) MERGE (r:GuidelineRecommendation { id:'HTN-ADJUST' }) SET r.action = 'adjust_antihypertensive', r.rationale = 'Blood pressure above 140/90; ' + 'tighten antihypertensive regimen.' MERGE (p)-[:HAS_RECOMMENDATION]->(r) """, pid=pid ) def apply_rules(kg: SemanticStateGraph, pid: str): """ Apply all ontology-inspired rules for a single patient. """ with kg.driver.session() as sess: rule_diabetes_therapy(sess, pid) rule_bp_adjust(sess, pid) \end{lstlisting} \subsection*{A.3 LangGraph Orchestration Skeleton} \begin{lstlisting}[caption={LangGraph orchestration using SemanticStateGraph},label={lst:langgraph}] from typing import TypedDict, Annotated, List, Dict, Any from langgraph.graph import StateGraph, START, END from langgraph.graph.message import add_messages from langchain_anthropic import ChatAnthropic from .semantic_state import SemanticStateGraph from .skills import apply_rules llm = ChatAnthropic(model="claude-3-5-sonnet-latest") class GraphState(TypedDict): messages: Annotated[List[Dict[str, Any]], add_messages] patient_id: str | None kg = SemanticStateGraph() def ingest(state: GraphState) -> GraphState: # No-op: message already stored in state return {} def extract_and_assert(state: GraphState) -> GraphState: """ Use LLM to extract patient facts and assert into S_s. """ last = state["messages"][-1]["content"] prompt = [ {"role": "system", "content": ( "Extract patient_id (or invent one if missing), " "diagnoses (codes), labs (name, value, unit), " "and medications from the note. " "Return JSON." )}, {"role": "user", "content": last} ] resp = llm.invoke(prompt) data = ... # parse JSON from resp.content pid = data.get("patient_id") or "P-001" kg.assert_patient(pid, data.get("name", "Unknown"), data.get("age", 0)) for d in data.get("diagnoses", []): kg.assert_condition(pid, d["code"]) for lab in data.get("labs", []): kg.assert_lab(pid, lab["name"], float(lab["value"]), lab["unit"]) return {"patient_id": pid} def semantic_skills(state: GraphState) -> GraphState: """ Apply ontology rules (R1, R2, ...) as skills. """ pid = state["patient_id"] apply_rules(kg, pid) return {} def respond(state: GraphState) -> GraphState: """ Query recommendations from S_s and ask LLM to explain. """ pid = state["patient_id"] facts = kg.get_patient_summary(pid) recs = kg.get_recommendations(pid) prompt = [ {"role": "system", "content": ( "You are a clinical decision support assistant. " "Given structured patient facts and " "ontology-derived recommendations, generate a " "clear explanation of what is recommended and why." )}, {"role": "user", "content": str({"facts": facts, "recs": recs})} ] resp = llm.invoke(prompt) return {"messages": [ {"role": "assistant", "content": resp.content} ]} def build_graph(): g = StateGraph(GraphState) g.add_node("ingest", ingest) g.add_node("extract_and_assert", extract_and_assert) g.add_node("semantic_skills", semantic_skills) g.add_node("respond", respond) g.add_edge(START, "ingest") g.add_edge("ingest", "extract_and_assert") g.add_edge("extract_and_assert", "semantic_skills") g.add_edge("semantic_skills", "respond") g.add_edge("respond", END) return g.compile() \end{lstlisting} \section*{References} \bibliographystyle{ieeetr} \begin{thebibliography}{99} \bibitem{langgraph} H.~Chase, ``LangGraph: Stateful orchestration for LLM agents,'' LangChain, 2024. \bibitem{gruber1993} T.~R. Gruber, ``A translation approach to portable ontology specifications,'' \emph{Knowledge Acquisition}, vol.~5, no.~2, pp.~199--220, 1993. \bibitem{hogan2021} A.~Hogan \emph{et~al.}, ``Knowledge graphs,'' \emph{ACM Computing Surveys}, vol.~54, no.~4, 2021. \bibitem{wei2022} J.~Wei \emph{et~al.}, ``Chain-of-thought prompting elicits reasoning in large language models,'' in \emph{Proc. NeurIPS}, 2022. \bibitem{lewis2020} P.~Lewis \emph{et~al.}, ``Retrieval-augmented generation for knowledge-intensive NLP tasks,'' in \emph{Proc. NeurIPS}, 2020. \bibitem{dean2004} M.~Dean and G.~Schreiber, ``OWL Web Ontology Language reference,'' W3C Recommendation, 2004. \bibitem{sparql2008} E.~Prud'hommeaux and A.~Seaborne, ``SPARQL query language for RDF,'' W3C Recommendation, 2008. \bibitem{keenan2018} T.~Keenan \emph{et~al.}, ``SNOMED CT, LOINC, and RxNorm: Achievements and challenges,'' \emph{Yearbook of Medical Informatics}, pp.~118--126, 2018. \bibitem{jiang2023_cdss_ontology_review} Y.~Jiang, H.~Zhang, and A.~Ten~Teije, ``Ontologies applied in clinical decision support system rules: a systematic review,'' \emph{JMIR Medical Informatics}, vol.~11, no.~1, e43053, 2023. \bibitem{ozkan2022_ontology_cdss} C.~\"Ozkan, J.~Alvarez-Romero, and M.~Robles, ``A personalized ontology-based decision support system for anticoagulant therapy in atrial fibrillation,'' \emph{International Journal of Medical Informatics}, vol.~166, 104845, 2022. \bibitem{johnson2019_cro_cdss} P.~Johnson, A.~Shaban-Nejad, and B.~L. Jansson, ``Using clinical reasoning ontologies to make smarter clinical decision support systems: a review,'' \emph{Journal of the American Medical Informatics Association}, vol.~27, no.~1, pp.~159--168, 2020. \bibitem{schulz2014_mobile_cdss} S.~Schulz, N.~Romacker, and M.~Kaiser, ``An ontology-based, mobile-optimized system for clinical decision support,'' \emph{PLOS ONE}, vol.~9, no.~5, e93769, 2014. \bibitem{anr2020_covid_cdss} A.~Bouaud \emph{et~al.}, ``Ontology-based decision support platform for evaluating COVID-19 patient orientation,'' ANR Project Report, 2020. \bibitem{agrawal2024_kg_hallucination_survey} G.~Agrawal, T.~Kumarage, Z.~Alghamdi, and H.~Liu, ``Can knowledge graphs reduce hallucinations in LLMs? A survey,'' in \emph{Proc. NAACL-HLT}, 2024. \bibitem{tellius2024_semantic_agents} R.~Maddi and S.~Goyal, ``Is a semantic layer necessary for enterprise-grade AI agents?,'' Tellius Whitepaper and Blog, Dec.~2024. \end{thebibliography} \end{document}