1 Introduction↩︎

Industrial automation is shifting from monolithic control toward environments populated by many autonomous subsystems that operate concurrently – production schedulers, energy-management agents, automated guided vehicle (AGV) fleets, and maintenance planners – each optimizing its own objective while competing for the same physical resources such as energy, floor space, equipment, and time. As autonomy increases, the behavior of such a system is no longer the product of a single controller but the emergent result of many independently specified goals. Building on a prior intention-based engineering framework for modular process plants [1] and an autonomous-systems environment for evaluating control in autonomous plant operation [2], this paper lifts intention modeling from the design phase into runtime operation and generalizes it beyond process plants to autonomous industrial systems at large.

A structural problem accompanies this shift. Goals are formulated by humans at a high level of abstraction (“maximize throughput for Order A while keeping energy below 80 % of peak load”), but they are executed at the low level of setpoints and control logic. In this translation the rationale, the why behind a goal, is discarded, so no component of a running system can answer whether it is still pursuing what was actually intended. Three failure patterns recur. Lost intent: the original objective survives only as setpoints, and its purpose can no longer be queried at runtime. Silent conflict: two agents specify objectives independently, neither aware of the other, and the contradiction surfaces only once a physical constraint is violated or a target is missed. Stale intent: an objective set at \(t_0\) keeps executing at \(t_3\) even though its context has changed (e.g., the order was cancelled, the product discontinued) so the system acts consistently against an obsolete goal. Today these reconciliations are still performed implicitly: integration engineers resolve conflicting objectives at design time, and supervising operators catch drift by watching the process. The problem we address is therefore an emerging one, as autonomy removes the human from the loop, that implicit safeguard disappears and is given no formal home.

Existing coordination mechanisms do not close this gap because none represents intentions as managed runtime objects: contract-net and auction protocols are transactional and carry no notion of why a resource is requested [3]; agent communication languages such as FIPA-ACL exchange goal-bearing messages but neither persist nor cross-check them at runtime [4]; and rule engines detect only conflicts anticipated at design time. What is missing, we argue, is a runtime infrastructure that treats intentions as first-class, persistent, and explainable resources across agent boundaries. At the same time, large language models have begun to recognize and discover intent directly from natural language [5], pointing to a practical route for capturing intentions at runtime.

This work-in-progress paper proposes such an infrastructure – the Intention Abstraction Layer (IAL) – and reports a first proof of concept. Our contributions are: (i) the IAL architecture, a domain-agnostic middleware that treats intentions as first-class runtime resources and manages them along two axes: elicitation of intentions between human operators and autonomous agents, and reconciliation of intentions among the agents themselves, with formal capture, persistence, and lifecycle management; (ii) LLM-grounded intention parsing and conflict detection, showing that a language model anchored to a formal OWL ontology can bridge natural-language goal specification and machine-interpretable intention structures and can flag goal conflicts in open-world scenarios without pre-specified conflict rules; and (iii) an open-source proof-of-concept that validates the three core modules on a multi-agent production scenario.

2 Background and Related Work↩︎

Our work connects three strands of research.

Goal- and intention-oriented modeling. Goal-oriented requirements engineering captures stakeholder objectives and their refinement, e.g., the KAOS method [6], while the belief–desire–intention (BDI) model [7] gives agents an explicit notion of goals and is still being extended, for instance by integrating machine learning [8]. These approaches formalize intentions at design time or inside individual agents; we instead manage them as shared, living runtime objects that can be registered, monitored, and retired across agents. Our own prior work introduced ontology-based intention modeling for the early engineering of modular process plants [1] and methods for evaluating the behavior of autonomous plants [9]; here we lift intention modeling into runtime operation.

Coordination in multi-agent systems. Classical mechanisms coordinate behavior without a shared representation of why: the Contract Net protocol allocates tasks through bidding [3], and agent communication languages such as FIPA-ACL exchange goal-bearing messages [4], yet none persists, monitors, or cross-checks intentions across agents at runtime. Recent benchmarks confirm the difficulty: even LLM-based agents coordinate well on observable conditions but struggle to reason about their partners’ beliefs and intentions [10]. Closing this gap at runtime is precisely what the IAL targets.

Language models in industrial automation. A rapidly growing body of work applies LLMs to production and control, enhancing modular production [11], controlling automation systems directly [12], exploring resource capabilities in multi-agent manufacturing [13], building agentic frameworks [14], and integrating LLMs with digital twins [15]. Closest to our parser, NL2IBE maps natural language to formalized engineering artefacts under ontology control [16]; we apply the same principle to runtime intentions rather than design-time artefacts. The capability-and-skill paradigm, increasingly paired with LLMs [17], formalizes what a system can do; the IAL is complementary, addressing what it intends. We ground the model in an OWL ontology [18] and keep it strictly above execution.

3 Problem Statement and Research Questions↩︎

The failure patterns above share a common root: intentions exist only implicitly, dispersed across operator knowledge, configuration files, and control code, and are never reconciled while the system runs – neither between the human operators who set goals and the agents that execute them, nor among the agents themselves. No shared, formal, runtime representation of what each party currently intends exists, so divergence between intended and executed behavior becomes observable only through its consequences. We therefore ask:

• Can a dedicated middleware layer – the IAL – formally capture, persist, and monitor the intentions exchanged between human operators and autonomous agents and among the agents themselves, and detect conflicts before they manifest as execution failures?

• Can LLM-based parsing bridge natural-language goal specifications and formal, ontology-based intention representations well enough to make the IAL practically usable in industrial settings?

This paper treats the forward direction, from stated goals to monitored, reconciled intentions. We identify the backward direction, inferring the intention implied by a planned execution and checking declared against enacted behavior, as the bridge to our subsequent work, and sketch it as a capability of the architecture below.

4 Proposed Approach↩︎

The IAL is a domain-agnostic middleware layer positioned between the goal-specification level (human operators or autonomous agents) and the execution level (PLCs, controllers, agent execution frameworks), as shown in Fig. 1. It is deliberately a coordination and transparency layer rather than a safety-critical controller: it reasons about and reconciles intentions above the execution layer and never intervenes in real-time control directly. This boundary keeps non-deterministic components – notably the language model – out of the safety-critical path.

4.1 Formal intention representation↩︎

In the underlying intention-based engineering framework [1], an intention is described by intentional elements: Goals (what is to be achieved), Abstract Solutions, strategies, stated at a solution-neutral level, and Requirements, the constraints that must hold. For runtime operation we add Context, the operating situation in which the intention is valid, together with provenance metadata, giving \[\mathit{Intention} = \langle\, \underbrace{G}_{\text{Goal}},\; \underbrace{A}_{\text{Abstr.\,Sol.}},\; \underbrace{R}_{\text{Requirement}},\; \underbrace{C}_{\text{Context}} \rangle\; \label{eq:intention}\tag{1}\] where \(G\), \(A\) and \(R\) are ontology classes taken from the framework and the context \(C\) is introduced here. Because each element is an ontology object rather than free text, an intention is machine-interpretable and reasoning over intentions reduces to reasoning over the ontology.

4.2 Intent Parser (LLM + ontology)↩︎

The Intent Parser maps natural-language or semi-structured input to an instance of 1 . A large language model performs the mapping, but it is anchored to the ontology: the target vocabulary for goals, abstract solutions, and requirements is constrained to ontology terms, so the parser produces grounded structures rather than unconstrained text. This is what answers RQ2 – it lets operators and agents state goals in their own terms while the IAL still obtains a formal representation.

4.3 Consistency Monitor↩︎

On registration, the Consistency Monitor checks the new intention against all currently active intentions in the store using ontology-based semantic similarity and constraint intersection. When two intentions act on overlapping resources and time windows with incompatible constraints, it raises a conflict, annotated with type, severity, and the affected agents. Crucially, this happens at registration time, before execution, which is the mechanism behind RQ1 and the pre-execution behavioral-evaluation angle.

4.4 Transparency API and resolution↩︎

The Transparency API renders detected conflicts and IAL decisions back into operator-facing natural language, closing the loop opened by the parser. It turns formal ontology reasoning into an explanation a human can act on and, where one exists, proposes a candidate resolution, for example, delaying a batch or relaxing a temperature ramp. Consistent with the design boundary, the IAL advises but does not enforce: a human or the owning agent accepts or rejects the proposal.

4.5 Intention Store and lifecycle↩︎

The Intention Store is a persistent OWL repository of all active and historical intentions across agents, backed by the ontology and a reasoner that the Consistency Monitor queries. Because intentions are explicit objects, they have a lifecycle: they can be updated, superseded, or retired. This directly addresses stale intent, the failure pattern that arises when no one manages the validity of an objective over time.

4.6 Directionality↩︎

The IAL operates along two axes. In the forward direction it elicits and reconciles intentions: an operator or agent states a goal, the Parser lifts it into 1 , and the Monitor reconciles it against the active set—the path exercised in this paper. In the backward direction the layer inverts the mapping, inferring the intention implied by an observed execution and comparing it against the declared intention to expose divergence between what an agent says and what it does; we sketch this direction here and develop it in subsequent work.

5 Preliminary Implementation and First Results↩︎

We implemented a minimal proof of concept whose modules map one-to-one onto Fig. 1: an Intent Parser, a Consistency Monitor, a Transparency and Resolution module, and an OWL-backed Intention Store, sitting on top of a simulated execution layer. The ontology is an OWL file built with owlready2. Consistent with the design boundary, the language model is confined to the parser; all conflict logic is deterministic Python.

The simulated execution layer is a minimal process model of the plant’s aggregate load on a shared electrical bus: other consumers follow a time-varying baseline profile, and an executing high-temperature batch superimposes its demand on top, producing a load trajectory that the IAL evaluates against the active constraint before execution. It is deliberately simple – a software stand-in for a PLC or control system, not a high-fidelity plant model.

5.1 Scenario↩︎

Two autonomous agents register intentions concurrently. The Production Scheduler states: “run a high-temperature batch from 14:00–16:00 that draws about 92 % of peak load”; the Energy Manager states: “keep total load below 80 % of peak between 13:00–17:00.” Each sentence is parsed into the structure of 1 by Anthropic’s Claude (Opus 4.8), constrained to the ontology vocabulary so that its output is grounded rather than free text; the parsed structures are recorded so that the reported result is deterministic and reproducible.

5.2 Result↩︎

On registering the second intention, the Consistency Monitor reports a high-severity conflict on the shared resource peak_load: the batch demands \(\sim\)​92 % during 14:00–16:00, exceeding the active 80 % cap by 12 percentage points in the overlapping window, the exceedance margin by which the monitor grades severity. The Transparency module explains this in natural language and proposes a resolution: defer the batch until the cap window ends (17:00) or reduce its demand. Evaluating both cases against the simulated execution layer yields Fig. 2: without the IAL the conflict is latent and the cap is breached at execution (a); with the IAL it is caught at registration and the resolved schedule keeps the load under the cap throughout the constrained window (b). The conflict is thus surfaced and explained before execution rather than after a violation, the behavior targeted by RQ1, with the parsing step answering RQ2.

5.3 Application↩︎

To apply the IAL, an automation engineer deploys it as a coordination service alongside an existing control system or agent framework. The ontology is extended once with the plant’s vocabulary; the system is then connected in one of two ways. In the active mode each autonomous component calls register(goal, source) when it forms a plan and subscribes to conflict notifications over OPC-UA, REST, or MQTT. In the passive mode the IAL observes setpoints and schedules and infers intentions without modifying the components. Detected conflicts and their explanations are routed to the operator’s HMI or returned to the agents as advisory signals; the control system keeps running throughout, as the IAL only observes, reconciles, and explains.

The implementation will be released as open source as a next step.

6 Conclusion and Future Work↩︎

We presented the Intention Abstraction Layer, a middleware that captures, reconciles, and explains the intentions of multiple autonomous systems at runtime, together with a proof of concept that detects and explains a production/energy conflict before execution. The work is preliminary. The language model is non-deterministic and adds latency, so we confine it to the advisory layer and record its output; the proof of concept implements only the forward path over a simulated execution layer. Real PLC/OPC-UA connectivity, agent identity and trust, and concurrency control remain open engineering challenges. A rule-based or locally-deployable model alternative to the cloud LLM is planned to address determinism and on-premise deployment requirements. A confirmation step for the operator even in the conflict-free case, verifying that the parsed intention matches the stated goal before execution, is identified as a trust-building measure for deployment. The backward direction – inferring intentions from observed execution to check declared against enacted behavior – remains an open direction for future work.

References↩︎