Learning Objectives

After reading this chapter, the reader will be able to:

1. Explain why agentic engineering changes the interface to process simulation.
2. Distinguish between a language model, a physics engine, and a governed tool server.
3. Describe how faster access to technical data changes the scope of possible engineering studies.
4. Identify the human review points that remain essential when agents accelerate analysis.

Online companion: The online book covers this ground in its Why Agentic Engineering? and The NeqSim Physics Engine chapters, with detailed EOS tables, flash-calculation theory, and the four-layer architecture diagram. This chapter gives a shorter operational framing and then moves into the data ecosystem and workflow patterns that the online book does not cover in depth.

1.1 From Simulation Files to Simulation Conversations

Process simulation has always been more than a numerical calculation. A useful simulation study starts with a question, gathers data, chooses assumptions, builds a model, runs scenarios, checks results, and turns those results into a decision. The solver is only one step. A flash calculation may run in a fraction of a second, while finding the right composition, design pressure, equipment datasheet, and operating history can take hours. The practical bottleneck is often the translation between people, documents, databases, and software.

Agentic engineering changes that translation layer. A large language model can read a natural-language request, identify what data is missing, call tools, write small pieces of code, inspect results, and draft a report. It cannot be trusted to invent thermodynamic numbers. It can, however, be trusted to call a validated thermodynamic tool when the tool is available, the input schema is clear, and the result carries provenance. This division of labour is the core idea of the new workflow: the model coordinates, the simulation engine computes, and the engineer judges.

NeqSim is well suited to this role because it is both a thermodynamic engine and a process simulation framework. It contains equations of state, flash calculations, physical property models, process equipment, pipeline models, mechanical design helpers, standards calculations, and reporting utilities [1, 2]. The NeqSim MCP server exposes selected parts of that capability through the Model Context Protocol (MCP), so an LLM host can discover and invoke tools without knowing the internal Java API [3].

The important shift is not that engineers can ask a chatbot for an answer. The important shift is that engineers can ask for an auditable workflow. A prompt such as "check the dew point and hydrate margin for this gas at arrival conditions" can become a sequence of explicit operations: validate the composition, run a flash, calculate hydrate temperature, compare against a margin, record assumptions, and prepare a short conclusion. Each operation can be logged, reproduced, and reviewed.

1.2 What Is NeqSim?

NeqSim (Non-Equilibrium Simulator) is an open-source Java library for thermodynamic and process simulation, developed since 2002 and maintained on GitHub [1, 2]. It is used by oil and gas companies, universities, and engineering consultancies worldwide.

At its core, NeqSim contains a thermodynamic engine with multiple equations of state:

NeqSim also provides:

• Flash calculations: TP, PH, PS, dew point, bubble point, hydrate equilibrium, and multiphase checks.
• Physical properties: Density, viscosity, thermal conductivity, surface tension, diffusion coefficients, and speed of sound, using both corresponding- states and specialised correlations.
• Process equipment: Separators, compressors, heat exchangers, valves, pumps, mixers, splitters, distillation columns, pipelines (Beggs and Brill), reactors, and flare systems.
• Modular field models: ProcessSystem for single process areas and ProcessModel for multi-area plants, with recycle convergence and shared streams.
• Dynamic simulation: Time-stepping with runTransient, PID controllers, measurement devices, blowdown, and control-loop tuning.
• Mechanical design: Wall thickness, separator internals, well casing (API 5C3), and cost estimation.
• Standards calculations: ISO 6976 (gas quality), AGA 8, GPA 2145, and 22 additional standards for gas and oil properties.
• Component database: Over 100 pure components and support for petroleum fractions (TBP, plus-fraction characterisation).

NeqSim can be used directly as a Java library, through Python bindings (via JPype), or through the MCP server described in Chapter 2. The MCP server exposes selected NeqSim capabilities as structured tools that any MCP-compatible client can discover and call without knowing the Java API.

1.3 The Three-Layer Pattern

The agentic process-simulation workbench has three layers.

The language model should not be treated as a calculator. It should be treated as a coordinator that can read and write around calculators. The tool layer defines what the model is allowed to call. The data and model layer is where the engineering truth lives: thermodynamic equations, equipment records, historian values, design documents, and standards.

This pattern is closely related to reasoning-and-acting agent architectures in the AI literature [4, 5]. The industrial difference is that the actions are not web searches or generic code snippets. They are engineering operations with units, standards, access controls, and review requirements. A tool call that sizes a relief valve has a different risk class than a tool call that lists available component names.

1.4 Why Data Access Changes the Study Envelope

Traditional process studies are limited by the cost of assembling evidence. A team may run a single base case and a handful of sensitivities because each case requires manual data gathering: one person exports historian tags, another finds the latest datasheet, another checks whether the design basis has changed, and another copies results into a report. When the evidence chain is manual, studies become narrow.

Agentic engineering broadens the study envelope. If an approved STID retrieval agent can fetch a compressor datasheet, a tagreader skill can collect the last 30 days of inlet conditions from IP.21 or PI, and a SAP adapter can summarize recent maintenance notifications, then a model can ask better questions. It can compare current compressor performance against vendor curves, detect whether a heat exchanger has drifted since the last cleaning, or evaluate whether a separator debottlenecking option is constrained by an existing nozzle rating.

The value is not only speed. It is scope. Many studies that were previously too expensive to do routinely become practical:

• daily hydrate-margin screening using live composition and temperature tags;
• compressor operating-point checks against retrieved vendor curves;
• relief-load re-screening when operating envelopes change;
• production-optimization scenarios tied to current equipment constraints;
• emissions and energy studies using current fuel, flare, and power data;
• safety-barrier reviews that link simulations to as-built documents.

None of these workflows removes engineering accountability. The agent can assemble evidence and perform calculations faster, but the study team still owns assumptions, acceptance criteria, and final decisions. The new capability is that more scenarios can reach the review table with traceable evidence.

1.5 The Operational Data Ecosystem

The previous section described how data access changes the study envelope. But the phrase "data" is too vague for industrial practice. An oil and gas facility generates and consumes at least eight distinct categories of data, each with its own structure, access pattern, quality characteristics, and engineering role. Modern process simulation becomes state of the art when it can draw on all eight simultaneously — and when the agent can distinguish which category a particular value came from.

The first two categories — steady-state and dynamic simulation — are what traditional process simulation provides. They remain the computational core. But they answer different questions. A steady-state model asks: at these boundary conditions, what does the equilibrium look like? A dynamic model asks: when something changes, how does the system respond over time? Both are needed. A compressor anti-surge study needs steady-state operating points to define the map and dynamic simulation to evaluate how fast the controller responds to a trip. A depressurization study needs steady-state initial conditions and dynamic blowdown to predict metal temperatures. An agentic workflow should be able to launch either mode and explain which one is needed for the decision at hand.

The next three categories — documents, historian archives, and real-time readings — supply evidence. Documents provide design intent and constraints. Historian archives provide observed behaviour over days, weeks, or months. Real-time readings provide the current state. These are not interchangeable. A design pressure from a datasheet is not the same as a measured pressure from a historian tag. A historian tag from last month is not the same as a live reading at this moment. Agents should track the basis — design, historical, or real-time — and state it in every result.

The final three categories — modification/maintenance systems, project documentation, and production databases — supply context that turns a calculation into a decision. A simulation may show that a heat exchanger can deliver more duty after cleaning. SAP tells the team whether cleaning is scheduled, what the lead time is, and whether spare gaskets are available. A FEED report tells the team what design margins were originally assumed. A production database tells the team what actual throughput has been and whether the wells can deliver the scenario being tested.

The state-of-the-art contribution of agentic process simulation is that it treats all eight categories as first-class data sources. The agent can retrieve from documents, read from historians, query modification status, check project assumptions, and use production data to set reservoir boundary conditions — all feeding into a process model that runs both steady-state and dynamic calculations. The result is a decision basis, not just a calculation.

The rest of this book explores how these eight pillars work together. Chapter 4 describes the data foundation in detail. Chapter 5 shows how modular models connect to evidence. Chapter 7 covers operational workflows that combine simulation with live and historical data. Chapter 9 walks through a worked case.

1.6 What Makes This Different from a Traditional Digital Twin

Digital twins are often described as continuously updated models of physical assets. In practice, many digital twins struggle because model maintenance is expensive. Tag names change. Equipment is modified. Documents are revised. Operating modes shift. A model that was accurate during commissioning can drift unless people keep feeding it current information.

Agentic workflows can reduce this maintenance burden. They can use historian data to identify recent operating envelopes, document retrieval to refresh equipment constraints, and process automation APIs to set model variables by string-addressable names. A modular field model can then be used for both steady-state studies and detailed equipment checks. The model does not have to be a monolithic file that only a specialist can understand. It can be a set of connected process areas with explicit data links, validation steps, and saved states.

This is why the MCP server matters. It gives the LLM a governed way to call the simulation engine. It does not ask the model to remember the NeqSim Java API. It publishes tools, schemas, examples, resources, and validation metadata. The LLM can inspect the tool catalogue, choose a calculation, pass structured input, and receive structured output. The engineer can inspect the same output.

1.7 The Human Role Moves Upstream and Downstream

When agents accelerate calculation, the human role does not disappear. It moves to the points where judgement matters most.

Upstream, engineers define the question. They decide whether the study is a quick screening, a standard study, or a comprehensive decision basis. They decide which standards and jurisdiction apply, which data sources are approved, what uncertainty ranges are credible, and what acceptance criteria will be used.

Downstream, engineers review the answer. They check whether the result is physically plausible, whether the model is inside its validation envelope, whether the retrieved data is current, and whether the recommendation is appropriate for the decision. Agentic engineering is powerful precisely because it creates more material for this review. It can produce a notebook, a results.json file, a report, a standards map, and a trace of tool calls. That is far better than an unsupported number copied into an email.

1.8 A Day in the New Workflow

Imagine a production engineer arriving in the morning to a question from operations: gas export was reduced overnight because the arrival temperature in the export line approached the hydrate-management limit. The old workflow might start with email: ask for the latest composition, export the relevant historian tags, find the hydrate curve used last year, locate the pipeline route data, and ask a simulation specialist to rerun a case. By the time the result is ready, the operating situation may have changed.

In an agentic workflow, the engineer starts with a bounded request:

Screen hydrate margin for the last 12 hours of export operation. Use approved
historian tags, the latest reviewed gas composition, and the NeqSim hydrate
method. Report source windows, model assumptions, minimum margin, and whether
specialist review is required.

The assistant does not invent the answer. It routes the task. A plant-data agent retrieves pressure, temperature, flow, and inhibitor tags. A document or data agent retrieves the latest approved composition and route assumptions. A NeqSim tool calculates hydrate temperature at selected operating points. A reporting step summarizes the tightest margin, lists rejected bad-quality tags, and marks whether the result is a screening or a decision basis. The engineer then reviews the evidence and decides whether to escalate.

The same pattern can apply to many daily questions. A compressor study can retrieve a vendor curve and calculate actual head. A heat exchanger study can compare predicted and measured duty. A relief screening can use the current operating envelope to decide whether a formal update is needed. The common theme is that the workflow becomes evidence first, calculation second, recommendation third.

1.9 From Pattern to Infrastructure

The workflows described above --- hydrate screening, compressor study, heat exchanger comparison --- share a common pattern. Each one combines technical documentation, field measurement data, and NeqSim simulation. The question is whether this pattern remains an informal convention that each agent must reinvent, or whether it becomes a programmable infrastructure that agents invoke.

NeqSim takes the infrastructure approach. The neqsim.process.operations package provides Java classes that implement the data-to-model binding:

• OperationalTagMap maps logical tag names to historian tags and simulation variables, so field data can be applied to a process model in a single call.
• OperationalEvidencePackage orchestrates a tag map, field data, scenarios, and benchmark comparisons into a single structured JSON report.
• OperationalScenarioRunner executes what-if scenarios defined as ordered action lists, returning before/after comparisons.
• ControllerTuningStudy evaluates controller performance from step-response time-series, computing IAE, overshoot, settling time, and stability.
• WaterHammerStudy combines route geometry, fluid properties, valve events, and tagreader overrides into a transient screening.

The neqsim.process.diagnostics package provides a RootCauseAnalyzer that combines OREDA failure data, historian time-series, STID design limits, and process simulation into a Bayesian-inspired ranking of failure hypotheses.

The neqsim.process.safety sub-packages provide consequence screening tools: GasDispersionAnalyzer for release-to-dispersion analysis, ReleaseDispersionScenarioGenerator for building release scenarios from a process model, TrappedLiquidFireRuptureStudy for blocked-in pipe segments, and CfdSourceTermExporter for formatting source terms for specialist CFD tools.

Each of these classes is exposed through MCP tools, so any MCP client --- a chat agent, a notebook, a dashboard, or a batch scheduler --- can invoke them without knowing the Java API. The important design principle is that the classes are orchestration classes. They do not replace NeqSim's flash calculations, EOS models, or equipment solvers. They combine those existing capabilities with external data sources into structured, auditable workflows.

The rest of this book explores these classes in context. Chapters 4 and 7 describe the data foundation and operational workflows. Chapter 6 covers safety. Chapter 9 presents a complete worked pattern that shows how the classes fit together in a realistic field study.

1.10 What Changes for Engineers

The new workflow changes the skill profile of a process engineer. It does not remove the need to understand thermodynamics, equipment, or safety. It increases the value of asking precise questions and reviewing evidence.

Engineers need to become good at specifying model boundaries. A prompt such as "optimize production" is too vague. A better prompt states the decision, time horizon, constraints, and acceptable output: "screen whether production can be increased by 5% for the next 24 hours without reducing hydrate margin below the operating criterion, exceeding compressor driver load, or increasing flare rates." This is not just better prompting. It is better engineering problem definition.

Engineers also need to become good at evidence review. When an agent extracts a design pressure from a datasheet, the reviewer should ask whether the document revision is current, whether the value is design or operating pressure, whether the unit is absolute or gauge, and whether the extraction was OCR-based. When an agent reads a historian tag, the reviewer should ask whether the instrument was healthy, whether the selected window was steady state, and whether all tags came from the same operating period.

Finally, engineers need to become good at model-risk thinking. A NeqSim flash calculation may be numerically correct but still unsuitable for a particular fluid, pressure range, or design decision. An MCP tool may expose a validated calculation, but the validation envelope must still match the task. The new workflow makes these checks more visible. It does not make them optional.

1.11 Summary

Agentic engineering is a new interface to facility operations. The language model coordinates, NeqSim computes, MCP governs tool access, and industrial data sources provide evidence. The outcome is not an autonomous engineer. It is a faster, more traceable workflow where more operational scenarios can be studied and reviewed.

Key points from this chapter:

• The main productivity bottleneck in simulation is often data translation, not solver runtime.
• MCP turns NeqSim capabilities into discoverable, typed, auditable tools for LLM clients.
• The operational data ecosystem has eight pillars: steady-state simulation, dynamic simulation, technical documents, historian archives, real-time readings, modification/maintenance systems, project documentation, and production databases.
• Modern process simulation draws on all eight simultaneously, tracking the basis of every value.
• STID, tagreader, SAP, production databases, and project documents expand the scope of routine studies.
• Human engineers remain responsible for questions, assumptions, acceptance criteria, and final decisions.

Exercises

1. Workflow decomposition: Choose a recent process-simulation task and list the steps that were calculation work versus evidence-gathering work.
2. Tool boundary: Identify three subtasks that an LLM should coordinate but not compute from memory.
3. Review point: For a hydrate-margin screening, define the minimum evidence an engineer should review before using the result.

This chapter uses references from the master bibliography.

Learning Objectives

After reading this chapter, the reader will be able to:

1. Install and smoke-test the NeqSim MCP server through the Docker distribution.
2. Configure VS Code Copilot Chat to use NeqSim through .vscode/mcp.json.
3. Install the NeqSim agent and skill pack that teaches the assistant how to use the MCP tools.
4. Explain the difference between STDIO and HTTP/SSE MCP transports.
5. Run a first engineering conversation that calls a NeqSim tool rather than relying on model memory.

Online companion: The online book covers MCP setup in its Getting Started chapter and the full MCP protocol, governance tiers, and validation profiles in its The MCP Server chapter. This chapter focuses on the Docker distribution path, practical troubleshooting, and deployment profiles for industrial teams.

2.1 Why Docker Is the Fastest Distribution Path

The NeqSim MCP server can be distributed as a Java runner jar or as a Docker image. For individual engineers and study teams, Docker is usually the fastest path because it packages the server runtime, Java dependencies, and startup command into a single image. The user does not need to install a matching Java runtime or manage classpaths. The LLM client starts the container, sends MCP JSON-RPC messages through standard input/output, and receives tool responses.

Docker also gives repeatability. A study team can pin an image tag, document the exact server version used for a study, and rerun the same calculation later. For regulated or safety-relevant engineering, this matters. The question is not only "what result did we get?" but "which model version, which tool contract, and which validation profile produced it?" [6, 7].

The local Docker workflow is deliberately small:

docker pull ghcr.io/equinor/neqsim-mcp-server:latest

echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' |
  docker run -i --rm ghcr.io/equinor/neqsim-mcp-server:latest

The smoke test sends a tools/list request and verifies that the server starts, accepts JSON-RPC input, and returns its tool catalogue. A failed smoke test is usually a Docker installation issue, an image access issue, or a blocked network path to the container registry.

2.2 Connecting VS Code Copilot Chat

GitHub Copilot Chat in Visual Studio Code can act as an MCP client when a workspace declares available servers. The configuration lives in .vscode/mcp.json. For a Docker-based NeqSim server, the minimal workspace configuration is:

{
  "servers": {
    "neqsim": {
      "type": "stdio",
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "ghcr.io/equinor/neqsim-mcp-server:latest"
      ]
    }
  }
}

After restarting VS Code, Copilot can discover the NeqSim server and expose the server's tools to the model. The engineer can then ask a question such as:

Use NeqSim to calculate the dew point temperature of a gas with
85 mol% methane, 10 mol% ethane, and 5 mol% propane at 50 bara.
Report the EOS model, convergence status, and limitations.

The important phrase is "Use NeqSim". It tells the assistant that the answer should come from a tool call, not from a memorized or approximated response. The model should select an appropriate flash or phase-envelope tool, provide a structured input object, and summarize the returned result. If the MCP client shows tool-call details, the engineer should inspect them during early use to build confidence in the workflow.

2.3 Installing the NeqSim Agent and Skill Pack

The MCP server is the calculation layer. It exposes NeqSim tools, schemas, and resources. It does not by itself teach the assistant how a NeqSim engineering study should be planned, which standards to check, how to structure evidence, or when to stop for human review. That guidance lives in NeqSim agents and skills.

For a useful Copilot setup, distribute the MCP server together with a small agent and skill pack from the NeqSim repository:

An organization can provide this as a versioned "NeqSim Copilot pack" in one of three ways:

1. Copy from the NeqSim repository: Suitable for individual pilots and training workspaces.
2. Distribute a ZIP or internal template repository: Suitable for study teams that need a controlled starting point.
3. Publish an approved internal package: Suitable for enterprise use, where agents, skills, validation cases, and MCP image versions are released together.

The minimum useful pack is:

For discipline work, add the relevant specialist agents and skills:

The pack should be versioned together with the MCP image tag. A report should be able to say, for example: "NeqSim MCP image vX.Y.Z, agent pack revision 2026-05-10, and skill pack revision 2026-05-10 were used." That provenance is as important as the numerical result.

2.4 STDIO and HTTP/SSE

Most desktop clients use STDIO transport. The client starts the server process, writes JSON-RPC messages to its standard input, and reads responses from its standard output. This is simple, local, and easy to sandbox. The Docker command above is exactly this pattern.

HTTP/SSE is useful when the server is long-running, remote, or shared by multiple clients. The server exposes an endpoint such as http://localhost:8080/mcp, and the client connects by URL instead of starting a process. This pattern is more natural for web applications, dashboards, or centrally managed engineering services. It also requires more explicit network, authentication, and logging decisions.

For a first engineering pilot, STDIO through Docker is usually best. For a study-team service, HTTP/SSE may be appropriate after governance, logging, and access-control decisions are made.

2.5 What the MCP Server Exposes

The server exposes NeqSim calculations as tools with typed schemas. The exact tool inventory evolves, but the stable pattern is consistent: core calculation tools, advisory discovery tools, advanced engineering tools, and experimental or higher-autonomy tools are separated by maturity and deployment profile. The tool contract promises stable required fields within the v1 API while allowing new optional fields to be added [8].

Useful first tools include:

Every engineering conversation should begin with discovery when the user is not sure which tool fits. A prompt such as "List NeqSim tools relevant for a CO2 pipeline phase-envelope and dense-phase screening" is better than asking the model to guess.

2.6 Deployment Profiles

The server distinguishes between desktop exploration, study-team work, digital twin advisory use, and enterprise-governed use. The names may evolve with the server, but the principle is stable: higher-risk or higher-autonomy tools are restricted in more governed profiles.

The key governance message is simple: an MCP tool can be technically callable without being appropriate for every deployment. A desktop engineer may run an experimental scenario solver for learning. A production advisory service should restrict itself to validated, read-only, traceable calculations unless a formal approval architecture exists.

2.7 First Conversation Pattern

A good first conversation tests the whole loop without involving private data:

I am testing the NeqSim MCP server. Please discover available NeqSim tools,
choose the simplest validated tool for a methane/ethane/propane dew-point
calculation, call the tool, and summarize the result with provenance and
limitations. Do not estimate the dew point from memory.

The expected assistant behaviour is:

1. discover or select the relevant tool;
2. create a structured input with composition, pressure, EOS, and flash type;
3. call the tool;
4. report convergence, model, assumptions, warnings, and result;
5. avoid claiming design suitability beyond the tool's validation envelope.

This pattern is more important than the numerical answer. It trains the team to ask for provenance and limitations as part of the result.

2.8 Walkthrough: A Complete MCP Tool Session

This section shows a concrete multi-tool session to illustrate what actually happens between the LLM client and the NeqSim MCP server. The engineer asks a single question; the assistant chains several tool calls behind the scenes. The JSON excerpts below are representative of real MCP messages.

Step 1 — Discovery. The assistant calls getCapabilities through MCP tools/call to find available tools:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "getCapabilities",
    "arguments": {}
  }
}

The server returns a list of tools with descriptions, categories, and maturity tiers. The assistant selects runFlash for a dew-point calculation.

Step 2 — Schema inspection. Before constructing the input, the assistant calls getSchema to learn the required and optional fields:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "getSchema",
    "arguments": {
      "toolName": "run_flash",
      "schemaType": "input"
    }
  }
}

The response includes field names, types, valid ranges, enums for flashType and model, and required composition format. This prevents the assistant from guessing parameter names or units.

Step 3 — Input validation. The assistant calls validateInput with the planned input to check for errors before running the calculation:

{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "tools/call",
  "params": {
    "name": "validateInput",
    "arguments": {
      "inputJson": "{\"model\":\"SRK\",\"pressure\":{\"value\":50.0,\"unit\":\"bara\"},\"flashType\":\"dewPointT\",\"components\":{\"methane\":0.85,\"ethane\":0.10,\"propane\":0.05},\"mixingRule\":\"classic\"}"
    }
  }
}

The server returns "valid": true or a list of issues such as unknown component names, out-of-range pressures, or compositions that do not sum to 1.0.

Step 4 — Flash calculation. With validated input, the assistant calls runFlash:

{
  "jsonrpc": "2.0",
  "id": 5,
  "method": "tools/call",
  "params": {
    "name": "runFlash",
    "arguments": {
      "components": "{\"methane\":0.85,\"ethane\":0.10,\"propane\":0.05}",
      "temperature": 25.0,
      "temperatureUnit": "C",
      "pressure": 50.0,
      "pressureUnit": "bara",
      "eos": "SRK",
      "flashType": "dewPointT"
    }
  }
}

For dewPointT, the pressure is the specification; the temperature argument is only the initial thermodynamic state used to construct the fluid before the dew point calculation. An abridged successful response has this shape:

{
  "status": "success",
  "flash": {
    "model": "SRK",
    "flashType": "dewPointT",
    "numberOfPhases": 1,
    "phases": ["gas"]
  },
  "fluid": {
    "conditions": {
      "temperature_K": 264.61
    },
    "properties": {}
  },
  "provenance": {
    "engine": "NeqSim",
    "thermodynamicModel": "SRK",
    "mixingRule": "classic",
    "calculationType": "dewPointT flash",
    "converged": true,
    "validationsPassed": [
      "component_names_verified",
      "flash_converged"
    ],
    "assumptions": [
      "Ideal gas reference state",
      "Van der Waals one-fluid mixing rules"
    ],
    "limitations": [
      "SRK EOS may under-predict liquid densities by 5-15%",
      "Less accurate for polar/associating compounds (use CPA instead)"
    ]
  }
}

The assistant reads this response and presents the result: the dew-point temperature is approximately $-8.5\,°\text{C}$ at 50 bara using SRK, the flash converged in 12 iterations, and the model limitation note warns about liquid density accuracy for heavier systems.

Step 5 — Trust metadata. For a formal study, the assistant can also call getBenchmarkTrust to report validation status:

{
  "jsonrpc": "2.0",
  "id": 6,
  "method": "tools/call",
  "params": {
    "name": "getBenchmarkTrust",
    "arguments": {
      "action": "getTool",
      "toolName": "runFlash"
    }
  }
}

The response includes validation basis (test cases, accuracy bounds, known limitations) and a trust classification. This metadata belongs in the study record so reviewers know the tool's qualification level.

What the engineer sees. In VS Code Copilot Chat, the engineer sees a natural-language summary with the dew-point value, EOS model, convergence status, and limitations. The tool-call details can be expanded to inspect the exact JSON exchanged. This transparency is what separates a tool-backed answer from a language-model guess.

2.9 Troubleshooting

Common startup issues are straightforward:

For corporate pilots, the most important troubleshooting rule is to separate connectivity problems from engineering problems. First prove the MCP server can list tools. Then prove a public flash example works. Only then connect internal data sources or run asset-specific workflows.

2.10 Prompt Templates for First Use

Early users often ask the assistant for a number and receive a plausible-looking answer. A better habit is to ask for a tool-backed workflow. The following prompt patterns are useful during a pilot.

Discover NeqSim MCP tools relevant to this task before choosing a calculation.
Explain why the selected tool is appropriate and what assumptions it requires.

Use NeqSim for the thermodynamic calculation. Do not estimate from memory.
Return model, units, convergence status, warnings, and provenance.

Treat this as a screening calculation. List what additional evidence would be
required before using the result for design or safety approval.

If input data is missing, stop and list the missing fields instead of inventing
reasonable defaults. Suggest realistic data sources for each missing field.

These prompts are intentionally procedural. They train the assistant to expose the reasoning path and tool boundary. They also train the engineer to expect structured answers rather than fluent guesses. During early deployment, teams should collect good prompt patterns and convert them into skills or reusable workflow templates.

2.11 Local Docker Security and Practical Operations

Running an MCP server through Docker is simple, but it still deserves basic operational discipline. A local container can read only what it is given through the MCP session and mounted paths. For the NeqSim MCP server in the minimal configuration, the container is transient: --rm removes it after the session, and no workspace folder is mounted by default. That is a good first-pilot posture.

When a workflow needs files, the team should decide what to mount and why. A task folder containing public examples is very different from a folder containing internal documents. Mount only the folders needed for the task, use read-only mounts when possible, and do not copy confidential documents into locations that are outside approved storage. The convenience of Docker should not become a workaround for document control.

Version control is equally important. The latest tag is convenient for early testing, but a report should record the image digest or version tag used. If a study is repeated later, the team should know whether the same server version, NeqSim version, and tool contract were used. For formal or high-impact studies, pin the image version and store it in the task metadata.

Logging needs the same care. Tool-call logs are valuable for reproducibility, but they may contain compositions, pressures, tag names, or document references. Store them in the study folder or approved logging system, not in arbitrary chat exports. When a result is reused outside the team, remove private asset names and confidential source references unless the receiving context is authorized.

2.12 Summary

Docker and VS Code Copilot make the NeqSim MCP server accessible to engineers without local Java setup. The .vscode/mcp.json file declares the server, MCP tool discovery exposes NeqSim capabilities, and deployment profiles govern what tools are appropriate in each context.

Key points from this chapter:

• Docker is the fastest repeatable way to install the MCP server for desktop pilots.
• Copilot should be configured to call NeqSim tools, not estimate engineering results from memory.
• STDIO is best for local desktop use; HTTP/SSE is better for centrally managed services.
• Profiles and validation metadata are part of the engineering control system.

Exercises

1. Smoke test: Pull the Docker image and run a tools/list request. Record the server version and tool count.
2. Workspace setup: Create .vscode/mcp.json for a local test workspace and verify Copilot can discover the NeqSim server.
3. Governance choice: Decide which deployment profile is appropriate for a digital-twin advisory dashboard and justify the restrictions.

This chapter uses references from the master bibliography.

Learning Objectives

After reading this chapter, the reader will be able to:

1. Explain the difference between an agent, a skill, a tool, and a memory.
2. Describe how skills encode engineering practice without fine-tuning a model.
3. Map common engineering-study types to specialist agents and skills.
4. Identify where human approval should enter multi-agent workflows.

Online companion: The online book covers the multi-agent system, the skills library, and the AI architecture in dedicated chapters. This chapter gives a compact working summary and then focuses on engineering memory, cross-agent handoffs, and skill design patterns for industrial study teams.

3.1 Why One General Assistant Is Not Enough

A general LLM assistant can be useful for brainstorming, summarizing, and code generation. It is not enough for industrial engineering studies. A single assistant that claims to handle thermodynamics, process simulation, safety, economics, standards, field development, technical documents, and plant data is likely to blur boundaries. It may use the wrong EOS, quote a standard too loosely, or treat a screening result as a design result.

The NeqSim agent ecosystem solves this by specialization. A routing agent can classify the task and delegate to a process simulation agent, flow assurance agent, safety and depressuring agent, PVT agent, field development agent, technical document reader, or documentation writer. Each specialist has a smaller job, a clearer set of tools, and a relevant skill stack. This follows a multi-agent pattern familiar from distributed AI systems, but applied to engineering tasks with units, standards, and auditable outputs [9, 4].

3.2 Definitions

The vocabulary matters because it defines governance.

An agent chooses actions. A skill informs those actions. A tool executes them. Memory prevents repeated mistakes. Artifacts make the work reviewable.

This separation is what makes agentic engineering manageable. If a hydrate calculation fails, the fix might be in the skill (load the CPA hydrate pattern), the tool (improve validation), the memory (record a known API gotcha), or the agent instruction (require a standards lookup). Without the separation, every failure looks like a vague model problem.

3.3 Skills as Engineering Procedures

Skills are not magic prompts. They are structured procedures. A good NeqSim skill contains the domain scope, when to use it, required inputs, API patterns, validation rules, common errors, and output schema. This is exactly the kind of knowledge that a senior engineer carries in working memory and a junior engineer learns through repetition.

Examples include:

In practical deployments, these skills and their matching agents should be distributed with the MCP configuration. The MCP server gives the assistant a trusted calculation interface; the agents and skills teach the assistant which calculation to call, which evidence to request, which warnings matter, and when human review is required. Chapter 2 lists a minimum agent and skill pack that can be copied from .github/agents/ and .github/skills/ in the NeqSim repository or distributed as a controlled internal template.

The advantage over fine-tuning is transparency. A skill can be reviewed in a pull request. It can cite standards. It can be changed when a method changes. It can tell the agent to avoid a known API mistake. Fine-tuned model weights cannot be inspected in the same way.

3.4 Agent Composition for Engineering Studies

Most useful studies are not single-agent tasks. Consider a separator debottlenecking study. The router may compose the workflow as follows:

1. The technical document reader extracts existing vessel dimensions, nozzles, design pressure, internals, and vendor notes from approved documents.
2. The plant-data agent retrieves recent flow, pressure, temperature, and level tags through tagreader and classifies steady-state windows.
3. The process simulation agent builds or updates the NeqSim separator and upstream/downstream process context.
4. The mechanical design agent checks whether proposed operating changes stay inside design constraints.
5. The safety agent screens relief, blowdown, HAZOP deviations, and barrier implications.
6. The reporting agent assembles assumptions, results, uncertainties, and recommendations.

Each agent sees enough context to do its job but not so much that it becomes unfocused. The handoff artifact matters. A document-reading output should not be a paragraph of vague text. It should be structured data with source, page, confidence, and units. A simulation output should not be a screenshot. It should be a results object with key values, validation, and provenance.

3.5 Memory and Reuse

Engineering organizations repeat patterns. The same simulator setup issue appears in many tasks. The same process equipment class has the same unit conventions. The same source system has the same tag naming pattern. Memory lets agents learn these local facts without retraining.

There are three useful memory scopes:

Memory should be short, reviewed, and corrected when wrong. It is not a place for private plant data or confidential assumptions. Those belong in task artifacts under approved access controls.

3.6 Study Types Enabled by Agents and Skills

The value of agents and skills becomes clear when looking at study types. A process engineer can ask for a quick density calculation, but the same framework can scale to integrated studies.

The same MCP server can support many of these tasks by exposing trusted calculation tools. The broader agent workflow adds source retrieval, notebooks, reports, uncertainty analysis, and review gates.

3.7 Approval Points

Agentic workflows should not be fully autonomous in industrial engineering. They should be fast and explicit. Useful approval points include:

• after task classification and before a comprehensive study begins;
• after data retrieval, to approve sources and reject poor-quality data;
• after model construction, to approve assumptions and operating envelopes;
• after simulation, to review validation warnings and physical plausibility;
• before report release, to approve conclusions and recommendations.

These approval points are not bureaucracy. They are how the organization keeps engineering judgement in the loop while still benefiting from automation.

3.8 Designing a Skill

A skill should be written like a compact engineering procedure. It should begin with a clear trigger: when should the agent load this skill? The trigger should be specific enough to avoid accidental use. "Use for any engineering task" is too broad. "Use when predicting hydrate formation, inhibitor dosage, or hydrate margin in pipelines and wells" is better.

A useful skill then gives the agent a checklist. For a flow-assurance skill, the checklist may include fluid composition, water content, pressure and temperature envelope, inhibitor concentration, pipeline profile, ambient temperature, acceptance criterion, and applicable standards. The skill should also define failure modes: missing water content, unverified composition, wrong unit, hydrate model outside domain, or operating point close to the limit.

Code patterns belong in skills when they prevent repeated mistakes. In NeqSim, that may include setting a mixing rule before a flash calculation, calling physical-property initialization before reading viscosity, or using a modular ProcessModel instead of one oversized flowsheet. A skill is not a place to hide complicated logic. It is a place to make the logic reviewable.

Finally, a skill should define the output. An agent that runs a hydrate screen should return minimum margin, selected time window, model, composition source, warnings, and escalation recommendation. An agent that reads a compressor curve should return extracted curve data, confidence, page reference, and uncertainty. Without an output schema, multi-agent handoffs become fragile prose.

3.9 Handoffs Between Agents

Multi-agent workflows succeed or fail at their handoffs. A document-reading agent may produce extracted equipment data. A process-simulation agent may use those values. A safety agent may use the simulation state to screen a relief case. If the first output is vague, every downstream step inherits ambiguity.

A good handoff has five fields:

For example, a technical document reader should not simply say "the separator is rated for 85 bar." It should say whether 85 bar is design pressure or maximum operating pressure, whether the unit is bara or barg, which document and revision it came from, whether the value was read from a table or OCR, and whether a human needs to review it before use in a safety calculation.

This level of structure may feel heavy during a simple demonstration. In real engineering work it is lighter than the alternative: repeated clarification, manual copying, and untraceable assumptions.

3.10 Summary

Agents divide work. Skills encode practice. Tools compute and retrieve. Memory preserves verified local knowledge. Together they form an engineering operating system around NeqSim and industrial data.

Key points from this chapter:

• Specialist agents are safer and more effective than a single general assistant for complex studies.
• Skills are transparent, reviewable containers for domain procedure and API patterns.
• Handoffs should be structured artifacts, not loose prose.
• Approval points keep engineers accountable for assumptions and decisions.

Exercises

1. Agent map: For a compressor performance study, list the agents and skills needed from data retrieval to final recommendation.
2. Skill design: Draft the headings for a skill that teaches an agent how to use a company-approved hydrate management procedure.
3. Approval gate: Identify where a human reviewer should stop an automated study if source data quality is poor.

This chapter uses references from the master bibliography.

Learning Objectives

After reading this chapter, the reader will be able to:

1. Describe how eight categories of operational data support process simulation studies.
2. Explain the role of STID retrieval, technical document reading, and tagreader workflows.
3. Distinguish between real-time readings, archived historian data, and design-basis values.
4. Describe how production databases and project documentation provide context that turns calculations into decisions.
5. Design a governed data-ingestion pattern for agentic engineering tasks.
6. Identify common data-quality risks before using retrieved data in a model.

Beyond the online book: The online book's worked examples use pre-defined compositions and conditions. This chapter addresses the reality that most industrial studies start with data scattered across STID, historian servers, SAP, production databases, and project archives. It provides the retrieval patterns, quality gates, and source-manifest schema needed to turn raw enterprise data into trustworthy model inputs.

4.1 The Data Problem Around Every Simulation

A process model is only as useful as the evidence behind its inputs. A gas composition from a lab report, a separator design pressure from a datasheet, a compressor map from a vendor package, a cooling-water inlet temperature from a historian tag, and a maintenance history from SAP can all change the conclusion of a study. In many organizations these data sources are separate. The engineer becomes the integration layer.

Agentic engineering makes that integration layer explicit. Instead of asking a person to manually search every source, an agent can be instructed to retrieve approved documents, read relevant pages, extract structured values, query historian tags through tagreader, and summarize enterprise records. The output must not be an untraceable blob. It must be a source manifest: what was read, where it came from, when it was retrieved, which values were extracted, what the confidence is, and what still needs human review.

The retrieval workflow is as important as the simulation workflow. A beautifully converged NeqSim result is not useful if it was built on stale, wrong, or unapproved data.

4.2 Source Classes

Industrial process studies typically draw on eight classes of source data, matching the taxonomy introduced in Chapter 1. The first four are the traditional categories. The next four are equally important but have been harder to integrate systematically until now.

STID is treated here as an example of a controlled engineering-document source. The same pattern applies to any document management system that stores datasheets, vendor documents, piping records, and as-built drawings. The agent does not need unrestricted access to everything. It needs approved retrieval capabilities, precise search criteria, and a requirement to store retrieved documents inside the study folder.

Historian data is different. It is time series, not a static evidence file. The neqsim-plant-data skill describes how tagreader can read plant data from PI or Aspen IP.21, map tags to model variables, and classify quality issues such as bad values, flatlined instruments, missing periods, and inconsistent units [10, 11]. The model should not simply use the latest tag value. It should identify a steady-state window or a relevant operating mode and report the selected interval.

SAP and similar enterprise systems add another dimension. Maintenance history, equipment master data, spare-part lead times, and work-order notes can explain why measured performance differs from design. A compressor may underperform because an anti-surge valve is passing, a heat exchanger may have fouling history, or a pump may have a known vibration issue. These data should not be mixed blindly into thermodynamics, but they can guide the study questions and interpretation.

4.3 Retrieval Agents and Skills

The document retrieval pattern normally uses several agents.

A safe retrieval workflow has six steps:

1. define the information need;
2. search only approved source areas;
3. copy or reference retrieved documents in the task's references/ folder;
4. extract candidate values with units and source locations;
5. mark confidence and human-review status;
6. pass only reviewed values into the model.

For a compressor study, the information need may be: rated speed, driver type, vendor map, suction and discharge nozzles, design pressure, operating range, anti-surge setpoints, and recent measured suction/discharge tags. The retrieved documents and tags should be joined by equipment tag or reference designation, not by a guessed name.

4.4 A Tag Mapping Pattern

Historian tags are rarely named the way a simulator variable is named. A tag may encode facility, system, equipment, instrument type, and signal. The model may use Compression::Export Compressor.inletStream.pressure. A tag map bridges the two.

equipment: Export Compressor
model_area: Compression
model_variables:
  inlet_pressure:
    address: "Compression::Export Compressor.inletStream.pressure"
    unit: "bara"
    historian_tag: "APPROVED_TAG_FOR_SUCTION_PRESSURE"
    quality_rule: "good_values_only"
  inlet_temperature:
    address: "Compression::Export Compressor.inletStream.temperature"
    unit: "C"
    historian_tag: "APPROVED_TAG_FOR_SUCTION_TEMPERATURE"
    quality_rule: "steady_state_median_30min"

The exact tag names are asset-specific and should not be hard-coded in a public book. The pattern is the important part. A model variable has an address, unit, historian tag, time-window rule, and quality rule. The agent can then retrieve a data window, calculate a robust median, detect bad periods, and set the process model input.

4.5 SAP and Maintenance Context

SAP data is not usually a process variable. It is context. Equipment master data can confirm the equipment identity, installed location, manufacturer, and functional hierarchy. Work orders and notifications can reveal recent repairs, inspection findings, cleaning campaigns, and known limitations. Spare-parts data can constrain what recommendations are realistic in the near term.

For example, an agent may find that a heat exchanger has lower duty than the NeqSim model predicts. Historian data shows the temperature approach has degraded over several months. STID provides the exchanger surface area and design duty. SAP shows repeated cleaning notifications and a planned shutdown window. The engineering study can then become more useful: not just "calculated duty is lower than design," but "observed duty degradation is consistent with fouling; evaluate cleaning during the planned window and update the model after post-cleaning data is available."

This is where access to SAP and other data enables studies that were difficult before. The process model can quantify the effect. Enterprise data can explain whether the effect is operationally actionable.

4.6 Production Databases: Well Tests, Allocation, and Reporting

Production databases are a critical but often neglected data source for process simulation. They contain the measured throughput that links reservoir deliverability to facility performance.

Well tests provide periodic measurements of individual well rates, water cut, gas-oil ratio, wellhead pressure, and choke position. These are the primary basis for reservoir boundary conditions in a facility model. A process simulation that assumes a fixed feed composition and flow rate may be valid for design-case screening, but a simulation that reads the latest well test results reflects actual reservoir behaviour.

Allocation data distributes total measured production back to individual wells or reservoirs. It provides the official volumes used for fiscal reporting and reserves tracking. When an agent builds a multi-well field model, allocated volumes can validate whether the simulation's well-level outputs are consistent with field accounting.

Daily production reports capture actual throughput, flaring, injection rates, and downtime events. They provide a day-by-day record of what happened. When a simulation study asks "what would happen if we increased rate?" the production report answers "what is the current rate, and what has it been?"

The agent pattern for production data is similar to historian data but with a different structure. Production databases typically return tabular records rather than time series. A well test report may give one measurement per well per month. An allocation report may give daily volumes per well. The agent should extract the most recent valid well test for each well, confirm its date, and set the simulation boundary conditions accordingly. If the well test is more than three months old, the agent should flag this as a data currency risk.

Production data also enables reservoir-to-facility consistency checks. If the total well test rate at wellhead conditions exceeds the facility's measured inlet flow, something is wrong --- either a well test is unreliable, or a flow meter is miscalibrated. The agent can report these discrepancies before they corrupt the simulation.

4.7 Project Documentation and Modification Management

Two source classes that are rarely integrated into process simulation studies deserve explicit treatment: project documentation and modification management records.

4.7.1 Project Documentation

A facility's design intent is captured in project documentation: the design basis memorandum, basis of design, FEED reports, concept study reports, decision-gate (DG) packages, and technical safety evaluations. These documents define the assumptions that shaped the original design. They answer questions like:

• What composition, flow rate, and pressure range was the facility designed for?
• What design margins were assumed for critical equipment?
• What acceptance criteria were set for gas quality, flaring limits, and water discharge?
• What alternatives were evaluated and why were they rejected?

When an agent performs a brownfield capacity screening, project documentation tells it what the original envelope was. If the current operating conditions have drifted outside the design basis, the study should flag this explicitly. If the agent finds that a proposed operating change is within the design margins documented in the FEED report, the confidence in the recommendation increases.

Project documentation is typically stored in document management systems like STID, SharePoint, or project data warehouses. The agent access pattern is similar to technical document retrieval: search by facility, system, and document type; retrieve the document; extract relevant values; cite the source and revision. The difference is that project documents are often large narrative reports rather than structured datasheets. The agent may need to read multiple pages of a FEED report to find the relevant design margins.

4.7.2 Modification Management and Management of Change

Modification management records track what has been changed, what is being changed, and what is planned to change. In many organizations, these records live in SAP (as projects or plant modification notifications), in dedicated MOC systems, or in project planning tools.

For process simulation, modification records answer essential questions:

• Has the equipment configuration changed since the last approved datasheet?
• Is there a modification in progress that affects the equipment being studied?
• Are there planned changes that the study should consider?
• Was a previous modification assessed against the same operating scenario?

A study that recommends increasing compressor throughput should check whether the compressor is subject to a pending modification. A study that finds a separator bottleneck should check whether an upgrade project is already approved. Without this context, the agent may produce technically correct but practically redundant or conflicting advice.

Management of change (MOC) records are particularly important for safety studies. A HAZOP deviation or LOPA study should consider not only the current configuration but also any modifications in the pipeline. If a valve is being replaced or a control system is being upgraded, the safety assessment should reflect the as-will-be configuration, not just the as-is.

The agent should treat modification records as context rather than as model inputs. A pending modification does not change the thermodynamics. But it changes whether a recommendation is actionable, redundant, or in conflict with an approved change.

4.8 Online Data Versus Archived History

Historian data and online data both come from instruments, but they serve different engineering purposes and have different quality characteristics.

Archived historian data is stored time-series data, typically compressed, sampled at regular intervals, and retained for months or years. It is the basis for trend analysis, steady-state window identification, and performance tracking. When an agent reads a 30-minute median from PI or IP.21, it is using archived data.

Online data is the current or near-current reading from an instrument, typically seconds old. It is the basis for live advisory, alarm validation, and closed-loop monitoring. An agent that reads the current compressor suction pressure and compares it to a model prediction is using online data.

The distinction matters for three reasons:

1. Temporal validity. Archived data can be selected from a known operating window. Online data captures the present moment, which may be transient, abnormal, or in the middle of a process upset. A steady-state model should not be compared against a live reading taken during a slug event.

1. Data quality. Archived data can be filtered for bad values, flatlines, and sensor faults before use. Online data may contain momentary glitches that have not yet been flagged.

1. Decision context. Archived data supports post-event analysis, model calibration, and performance benchmarking. Online data supports real-time decision support: should the operator change a setpoint now? Is the current alarm real or spurious?

An agentic system that integrates both should label the data basis clearly. A model calibrated against a 2-hour historian window and then compared against live readings is doing two different things. Both are valuable, but the uncertainty and interpretation differ.

For real-time advisory, the agent workflow typically looks like this:

1. Read the latest value from each mapped tag.
2. Check each reading against physical plausibility bounds.
3. Set the simulation inputs to the current readings.
4. Run the process model.
5. Compare model outputs to measured outputs.
6. If deviations exceed thresholds, generate an advisory with both the model prediction and the measured value.

This is a live diagnostic loop. It requires fast model execution, robust handling of bad data, and clear presentation of results. It also requires governance: who sees the advisory? What authority does it carry? These questions are addressed in Chapter 8.

4.9 Data Quality Gates

Every retrieved value should pass simple gates before entering a simulation.

The agent should fail early when these gates fail. A failed data gate is a good result: it prevents a bad calculation from becoming a polished report.

4.10 Source Manifest Pattern

A source manifest is the bridge between retrieval and trust. It should be machine-readable enough for agents and clear enough for engineers. A simple manifest entry can look like this:

source_id: COMP-DS-001
source_type: datasheet
system: approved_document_repository
title: Export compressor datasheet
revision: B
retrieved_at: 2026-05-08T10:30:00Z
retrieved_by: study_agent
access_basis: user_authorized
extracted_values:
  design_pressure:
    value: 160.0
    unit: bara
    page: 2
    confidence: high
    review_status: checked
  rated_power:
    value: 12.5
    unit: MW
    page: 3
    confidence: medium
    review_status: needs_review
limitations:
  - Vendor curve image was low resolution.
  - Rated power needs confirmation against driver datasheet.

The manifest should travel with the study. If the calculation is rerun six months later, the reviewer can see which source revision was used and whether a newer document exists. If an extracted value was medium confidence, a later agent can prioritize human review before reusing it.

This pattern is also useful for historian data. A tag window should be recorded with tag name, unit, start time, end time, aggregation rule, number of points, bad-quality percentage, and reason for choosing the window. A steady-state median is much more defensible when the source manifest explains how it was selected.

4.11 Data Fusion Without Confusion

The temptation in agentic systems is to fuse all available data into a single answer. Engineering work needs a more careful pattern. Data sources should be joined only when their basis is compatible.

For example, a compressor datasheet may define rated conditions at a specific gas composition and speed. Historian tags may represent a different composition and speed. SAP maintenance history may describe a condition that started after the selected tag window. A NeqSim model may use a simplified compressor efficiency rather than the full map. Joining these sources without stating the basis can produce a confident but misleading conclusion.

A disciplined workflow keeps three basis labels visible:

When the bases differ, the report should say so. The compressor may be inside the design basis but outside the current operating basis. A heat exchanger may meet design duty but fail to deliver observed duty because fouling is present. An agent that preserves the distinction helps the engineer reason; an agent that collapses it hides the problem.

4.12 Studies Enabled by Integrated Data

Access to SAP, document systems, historians, production databases, and project documentation does not merely make existing studies faster. It enables studies that were previously too cumbersome to run. Examples include:

These workflows are powerful because they connect technical feasibility to operational action. A simulation may show that a higher production rate is possible, but SAP may show that a limiting valve replacement is already planned. A model may show that a heat exchanger cleaning would recover duty, while the maintenance plan may show the earliest practical window. The study becomes a decision workflow rather than a calculation exercise.

4.13 NeqSim Infrastructure for Data-to-Model Binding

The concepts described so far --- tag mapping, evidence packages, data quality gates --- are not only workflow patterns for agents to follow. NeqSim provides concrete Java classes that implement them, so the agentic workflow has a programmable backbone rather than relying on convention alone. This section describes the key classes in the neqsim.process.operations package and shows how they bridge technical documents, plant data, and process simulation.

4.13.1 OperationalTagMap and OperationalTagBinding

The OperationalTagMap class is a portable, plant-agnostic map from logical operating tags to NeqSim measurement devices and automation addresses. Each entry is an OperationalTagBinding that records:

• a logical tag name used in public workflows and reports;
• an optional historian tag for connecting to PI, IP.21, or other time-series databases;
• a P\&ID reference for traceability to drawings;
• an automation address that maps to ProcessAutomation for reading or writing simulation variables;
• a unit, role (input, benchmark, virtual), and description.

The map intentionally delegates field-data writes to existing measurement devices and model writes to ProcessAutomation. It does not replace the NeqSim instrumentation model; it provides a reusable bridge for P\&ID and tagreader workflows.

A typical binding in Java looks like this after importing neqsim.process.operations., neqsim.process.measurementdevice.InstrumentTagRole, and java.util.:

OperationalTagMap tagMap = new OperationalTagMap();
tagMap.addBinding(
    OperationalTagBinding.builder("Suction_Pressure")
        .historianTag("PI_TAG_SUCTION_P")
        .pidReference("PT-1001")
        .automationAddress("Compression::Compressor.inletStream.pressure")
        .unit("bara")
        .role(InstrumentTagRole.INPUT)
        .build());

When the agent retrieves field data from a historian, the tag map can apply it directly to an existing ProcessSystem process:

Map<String, Double> fieldData = new LinkedHashMap<>();
fieldData.put("Suction_Pressure", 72.3);
fieldData.put("Suction_Temperature", 34.1);

Map<String, Double> applied = tagMap.applyFieldData(process, fieldData);
process.run();
Map<String, Double> modelValues = tagMap.readValues(process);

The map also supports validation: it checks that all bindings resolve to valid simulation addresses before data is applied, preventing silent mismatches. This is the programmable version of the YAML tag-mapping pattern described earlier. The advantage is that the tag map travels with the process model and can be serialized, versioned, and tested.

4.13.2 OperationalEvidencePackage

The OperationalEvidencePackage class orchestrates a complete evidence report from document-derived tags, field data, operational scenarios, and bottleneck analysis. It takes a process system, a tag map, field data, and a list of scenarios, and returns a structured JSON object containing:

• base evidence: model values for every bound tag;
• benchmark comparison: model-versus-field deviation for each tag, with pass/fail against a configurable tolerance;
• bottleneck analysis: capacity constraints from the registered equipment strategies;
• scenario results: before/after values for each operational scenario;
• quality gates: validation of data completeness and consistency.

This is the artifact that makes agentic integration auditable. An agent does not simply assert that the model matches plant data. It produces a JSON object where every deviation is visible, every source tag is traceable, and every scenario result can be compared against a baseline.

4.13.3 From Tags to Decisions

The infrastructure described here transforms the data integration pattern from a manual checklist into a first-class part of the simulation workflow. An agent that uses these classes does not need to coordinate tag mapping, data application, model execution, and evidence collection as separate manual steps. They become a single orchestrated call that returns a reviewable evidence package.

This matters because the bottleneck in many operational studies is not the flash calculation or the separator sizing. It is the translation between plant-data systems, engineering documents, and process models. The OperationalTagMap and OperationalEvidencePackage classes move that translation into tested, versioned code that agents can invoke and engineers can inspect.

4.14 Worked Demo: MCP Tools with Technical Data and Instrument Readings

This section walks through a concrete example that combines technical document data, instrument measurement readings, and NeqSim MCP tool calls. The scenario is realistic: an engineer wants to check whether a gas export compressor is operating within its design envelope, using current plant data and the equipment datasheet.

Step 1 — Retrieve datasheet values

The agent retrieves the compressor datasheet from the approved document repository. From the datasheet, it extracts:

These values become the design-basis reference for comparison.

Step 2 — Read current instrument measurements

The agent reads the latest steady-state window from the process historian using the tag map:

The agent checks data quality: all tags are marked good, the values are physically plausible, and the time window covers a 2-hour stable period.

Step 3 — Get gas composition from latest well test

From the production database, the agent retrieves the current gas composition:

methane: 0.82
ethane: 0.08
propane: 0.04
n-butane: 0.015
i-butane: 0.01
CO2: 0.025
nitrogen: 0.01

Step 4 — Run flash at suction conditions via MCP

The agent calls runFlash with the measured suction conditions and current composition to determine thermodynamic properties at the compressor inlet:

{
  "jsonrpc": "2.0",
  "id": 21,
  "method": "tools/call",
  "params": {
    "name": "runFlash",
    "arguments": {
      "components": "{\"methane\":0.82,\"ethane\":0.08,\"propane\":0.04,\"n-butane\":0.015,\"i-butane\":0.01,\"CO2\":0.025,\"nitrogen\":0.01}",
      "temperature": 38.2,
      "temperatureUnit": "C",
      "pressure": 68.4,
      "pressureUnit": "bara",
      "eos": "SRK",
      "flashType": "TP"
    }
  }
}

The response confirms single-phase gas with density $56.2\;\text{kg/m}^3$, molecular weight $19.1\;\text{g/mol}$, and compressibility factor $Z = 0.876$.

Step 5 — Run process simulation via MCP

The agent calls runProcess with a compressor model that uses the measured operating conditions as boundary:

{
  "jsonrpc": "2.0",
  "id": 22,
  "method": "tools/call",
  "params": {
    "name": "runProcess",
    "arguments": {
      "processJson": "{\"fluid\":{\"model\":\"SRK\",\"temperature\":311.35,\"pressure\":68.4,\"mixingRule\":\"classic\",\"components\":{\"methane\":0.82,\"ethane\":0.08,\"propane\":0.04,\"n-butane\":0.015,\"i-butane\":0.01,\"CO2\":0.025,\"nitrogen\":0.01}},\"process\":[{\"type\":\"Stream\",\"name\":\"Suction Gas\",\"properties\":{\"flowRate\":[42500.0,\"Sm3/hr\"]}},{\"type\":\"Compressor\",\"name\":\"Export Compressor\",\"inlet\":\"Suction Gas\",\"properties\":{\"outletPressure\":[148.7,\"bara\"],\"polytropicEfficiency\":0.78}}]}"
    }
  }
}

The response returns discharge temperature, power consumption, polytropic head, and thermodynamic properties at both inlet and outlet.

Step 6 — Compare against design basis

The agent compares the MCP results with the datasheet values:

The agent reports that the compressor is operating within its design envelope but notes the higher molecular weight and suction temperature. It recommends reviewing the gas composition trend and checking whether the anti-surge margin is adequate at the current operating point.

What this demonstrates

This walkthrough shows the pattern described throughout the book in concrete form. The MCP server provides the calculation engine (runFlash, runProcess). Technical documents provide the design basis. Instrument readings provide the operating basis. The agent orchestrates the retrieval, validation, calculation, and comparison. The result is a structured comparison that an engineer can review, not a single number without context.

4.15 Summary

Agentic process simulation depends on governed data retrieval as much as on calculation. Technical documents provide design evidence. Historians provide operating evidence from archived time series. Real-time readings provide the current state for live advisory. Production databases provide reservoir deliverability and actual throughput. Project documentation provides design intent and acceptance criteria. Modification management records track what has changed and what is planned. SAP and enterprise systems provide asset context, maintenance feasibility, and spare-part availability. Skills and agents connect all eight data classes to NeqSim models while keeping source provenance visible. The neqsim.process.operations package provides concrete Java classes --- OperationalTagMap, OperationalTagBinding, and OperationalEvidencePackage --- that implement data-to-model binding as a programmable, testable, and auditable workflow.

Key points from this chapter:

• Eight categories of operational data feed into modern process simulation studies.
• Retrieval should produce structured evidence with source, unit, confidence, and review status.
• Historian tags need mapping, time-window selection, and quality checks before model use.
• Online real-time readings serve different purposes than archived historian data; the agent must label the basis.
• Production databases provide well tests, allocation, and throughput that set reservoir boundary conditions.
• Project documentation provides design margins, acceptance criteria, and original study assumptions.
• Modification management records prevent recommendations that conflict with approved changes.
• SAP data can turn a calculated deviation into an operationally meaningful recommendation.
• Data gates are essential for preventing fast but unsupported simulations.
• NeqSim's operational tag map and evidence-package classes turn data integration from convention into code.

Exercises

1. Source manifest: Design a source manifest for a pump performance study using a datasheet, three historian tags, and SAP work orders.
2. Tag mapping: Define a tag map for a separator pressure, temperature, gas flow, liquid level, and water cut. Then write the equivalent OperationalTagMap Java code.
3. Quality gate: List three reasons a retrieved value should be rejected before entering a process model.
4. Evidence package: Describe what an OperationalEvidencePackage report should contain for a compressor study that compares model predictions against historian data.

This chapter uses references from the master bibliography.

Learning Objectives

After reading this chapter, the reader will be able to:

1. Explain why facility models should be built as named process areas rather than one opaque flowsheet.
2. Use a modular NeqSim model as the starting point for equipment-detail studies.
3. Link model variables to STID documents, historian tags, vendor evidence, SAP records, and review gates.
4. Feed equipment constraints back into the field model without losing scenario traceability.

Beyond the online book: The online book demonstrates individual NeqSim calculations and equipment examples. This chapter connects those pieces into one operating pattern: modular field models provide the facility context, and equipment-detail studies provide the evidence needed to update constraints, explain bottlenecks, and support decisions.

5.1 The Model-to-Equipment Chain

Agentic facility work becomes useful when a high-level model and a detailed equipment question are connected. A field model may show that the export compressor limits production, that a separator is close to liquid-handling capacity, or that a cooler cannot reach the target outlet temperature. The next question is not only mathematical. It is evidence-based: what does the datasheet say, what do the tags show, what has changed in maintenance history, and what review is needed before the conclusion can affect operation?

This chapter combines two ideas that are often treated separately. Modular field models create the stable process context. Equipment studies drill into the item that matters. The agentic workflow carries assumptions and evidence across the boundary instead of leaving each study isolated in a notebook, spreadsheet, or chat transcript.

5.2 Reference Field Architecture

A practical facility model should be split into process areas with clear owners and handoffs.

The architecture is not a mandatory template. The principle is that each area has a named boundary, a documented data basis, and explicit stream or signal connections to neighbouring areas.

5.3 ProcessModel Pattern

NeqSim supports modular work through ProcessSystem and ProcessModel. A ProcessSystem represents one process area. A ProcessModel composes several named systems into a field or facility model. Shared streams can connect areas by object reference, and the combined model can be run iteratively until the handoffs converge.

A simplified Python-style excerpt, after the standard neqsim_dev_setup cell has created ns and a feed stream named feed, is:

def build_separation(feed_stream):
    separation = ns.ProcessSystem()
    separation.add(feed_stream)
    hp_separator = ns.Separator("HP Separator", feed_stream)
    separation.add(hp_separator)
    return separation, hp_separator.getGasOutStream(), hp_separator.getLiquidOutStream()

def build_compression(gas_stream):
    compression = ns.ProcessSystem()
    compressor = ns.Compressor("Export Compressor", gas_stream)
    compressor.setOutletPressure(150.0, "bara")
    compression.add(compressor)
    return compression, compressor.getOutletStream()

plant = ns.ProcessModel()
separation, gas_to_compression, oil_stream = build_separation(feed)
compression, export_gas = build_compression(gas_to_compression)
plant.add("Separation", separation)
plant.add("Compression", compression)
plant.run()

In a real study, each builder function can read a configuration file, attach controllers, register automation variables, connect evidence metadata, and save a lifecycle state. That structure lets an agent localize a change: update the compression area with a retrieved compressor curve, or run the pipeline area for a cold hydrate case.

5.4 Stable Addresses and Automation

Large models need stable variable addresses. NeqSim's automation layer provides string-addressable variables such as:

Separation::HP Separator.gasOutStream.temperature
Compression::Export Compressor.outletPressure
Pipelines::Export Flowline.outletPressure
Utilities::Gas Turbine.fuelGasFlowRate

This address style matters because tag maps, MCP tools, document extraction outputs, and reports can refer to the same model variable without navigating Java object hierarchies. If a tagreader result says that the median suction pressure in the selected steady-state window is 62.4 bara, the agent can apply that value to the correct model address and rerun the scenario.

Stable addresses also make results reproducible. A table can state exactly which variable was changed, what value was read, which unit was used, and which scenario state stored the result.

5.5 Study Model, Advisory Model, and Design Model

Not every modular model has the same authority.

Agentic workflows can support all three, but the allowed autonomy changes. A desktop study model may be interactive. An advisory model should be read-only and logged. A certified design model needs frozen assumptions, review records, and revision control.

5.6 Steady-State and Dynamic Use

A modular model often starts as steady-state because steady-state simulation is the right tool for capacity screening, product quality, energy use, and scenario comparison. Dynamic simulation is needed when the question is time-dependent: depressurization, control response, startup, shutdown, slug clearing, or water hammer.

For facility work, dynamic mode is often applied to one process area while the larger model supplies boundary conditions. The agent should explain that choice instead of treating every simulation as the same type of calculation.

5.7 Evidence Links

A modular model becomes credible when each area can point to its evidence:

• separation area to vessel datasheets, inlet conditions, internals, and separator tests;
• compression area to vendor curves, driver data, performance tags, and maintenance history;
• pipeline area to line lists, route data, ambient profiles, and flowline drawings;
• safety area to relief basis, blowdown philosophy, cause-and-effect charts, and barrier registers;
• utilities area to fuel gas tags, turbine performance, cooling limits, and emissions factors.

The evidence link should be explicit. Useful metadata includes source_document, source_revision, retrieved_at, review_status, and assumption_owner. The agent can then flag stale evidence and expose uncertainty instead of hiding it in prose.

5.8 Equipment Evidence Package

An equipment-detail study starts with a compact evidence package.

The report should separate values from simulation, documents, tags, and assumptions. That separation is what lets the engineer judge whether the result is a screening, a verification, or a basis for formal approval.

5.9 Equipment Study Examples

Compressor. A compressor bottleneck study can combine simulated suction conditions, gas composition, required head, power, vendor map, driver load tags, anti-surge position, and SAP history. The output should identify whether the active constraint is process load, map limit, driver power, recycle, or degradation.

Heat exchanger. A heat exchanger study can compare model duty with observed duty from tags, check approach temperature and pressure drop against datasheet limits, and review cleaning history. The agent should distinguish between fouling, wrong flow, wrong composition, bypassing, and instrument error.

Separator. A separator study can combine gas and liquid rates, densities, viscosities, surface tension, vessel dimensions, demister type, retention time, level settings, and relief implications. Datasheet and mechanical-drawing evidence is essential; the process model alone does not know the physical internals.

Valves and instruments. Valve and instrument studies connect pressure drop, phase state, flow, Cv, rangeability, actuator behaviour, fail position, noise, alarms, and trip context. The agent can screen, but changes to valves, alarms, set points, and safety functions remain governed engineering changes.

5.10 Study Levels and Review Gates

Equipment studies should declare their authority level.

This distinction prevents polished agent outputs from being mistaken for approval. A result can be useful and still require specialist review before it changes an operating limit.

5.11 Feeding Results Back to the Field Model

The best equipment studies do not end as disconnected reports. They feed constraints, updated parameters, or warnings back into the modular model:

• a compressor study updates maximum allowable flow for a suction-temperature envelope;
• a heat exchanger study updates effective UA or flags a fouling scenario;
• a separator study updates liquid handling capacity or carryover risk;
• a control-valve study updates available pressure drop or noise constraint;
• a pump study updates efficiency or minimum-flow limits.

The feedback should be explicit and reversible. The base model remains a base model. Scenario states record what changed, why it changed, which evidence supports it, and who reviewed it.

5.12 Calibration and Root Cause Loops

A facility model becomes more valuable when it is compared with plant data. Calibration should not mean forcing the model to match every tag. It means selecting steady-state windows, mapping tags to inputs and outputs, calculating residuals, adjusting physically meaningful parameters within bounds, and validating against a separate window.

The same evidence pattern supports root cause analysis. When equipment performance changes, the agent can rank hypotheses, retrieve operating and maintenance evidence, run simulations under observed boundary conditions, and provide a structured package for specialist review. The agent does not replace the specialist; it reduces the time spent assembling the evidence.

5.13 Full-Facility Study Example

Consider a satellite tieback question: can a new stream be processed through an existing host without major modifications? A modular model turns the question into a sequence:

1. build the wellstream fluid and production profile;
2. run subsea and pipeline arrival pressure and temperature cases;
3. feed the host inlet and separation model;
4. check liquid handling, gas compression, dehydration, export, and flare impact;
5. run equipment-detail studies for active constraints;
6. evaluate utilities, emissions, uncertainty, and economics;
7. summarize bottlenecks and modification options.

Different specialists can work on different areas while the integrated model preserves the facility-level picture.

5.14 Summary

Modular field models and equipment-detail studies are one decision chain. The modular model provides the process context, stable addresses, scenario states, and cross-area convergence. Equipment studies provide the datasheet, vendor, historian, maintenance, and standards evidence needed to understand the active constraint.

Key points from this chapter:

• Large facility models should be composed from named process areas.
• Stable automation addresses make tag mapping, reporting, and MCP calls reliable.
• Steady-state and dynamic simulation answer different questions; the agent should explain the mode choice.
• Equipment studies need evidence packages that separate simulation values, document values, tag values, and assumptions.
• Constraints from equipment studies should feed back into scenario states without corrupting the base model.

Exercises

1. Area split: Divide a gas-processing facility into five process areas and define the stream handoffs.
2. Equipment package: Define the evidence package for a compressor bottleneck study and mark which values come from model, STID, tags, and SAP.
3. Feedback loop: Describe how a separator capacity finding should be stored back into a field model without overwriting the base case.

This chapter uses references from the master bibliography.

Learning Objectives

After reading this chapter, the reader will be able to:

1. Explain how agentic workflows can support, but not replace, process safety work.
2. Connect NeqSim calculations to HAZOP, LOPA, SIL, relief, flare, and barrier studies.
3. Describe how STID evidence and standards mapping improve safety traceability.
4. Define review gates for safety-relevant MCP and agent outputs.

Beyond the online book: The online book mentions safety peripherally in flow assurance examples and case studies. This chapter provides dedicated coverage of HAZOP preparation, LOPA worksheets, SIL determination, relief and blowdown screening, barrier evidence, trapped-liquid fire rupture studies, and the review gates that must surround safety-relevant agentic outputs.

6.1 Safety Work Is Evidence Work

Process safety studies are structured ways of asking what can go wrong, how bad it can be, how likely it is, and which barriers prevent or mitigate the event. They are not simply calculations. They combine process understanding, equipment design, operating history, standards, human factors, and judgement.

Agentic engineering can help because much of the preparation is evidence work. An agent can assemble equipment lists, extract design pressures, identify relief devices, read operating envelopes, summarize maintenance history, and map applicable standards. NeqSim can calculate thermodynamic and process conditions that safety studies need: inventories, phase splits, relief properties, blowdown temperatures, hydrate or CO2 freezing margins, flare loads, and dispersion source terms.

The boundary is clear. Agents can prepare and screen. They cannot approve safety decisions. A HAZOP chair, discipline engineers, operations representatives, and technical authorities remain responsible for the study and its conclusions.

6.2 Standards Mapping

Standards mapping is one of the most useful early agent tasks. A safety or design study should identify which standards and company requirements apply before calculations begin. Typical mappings include:

The agent should not merely list standards. It should connect each standard to the calculation or decision it governs. If the task is "increase separator throughput," the standards map may identify vessel design, relief, flare, instrumented protection, and barrier-management implications.

6.3 HAZOP and Deviation Preparation

HAZOP studies use guidewords and process nodes to identify deviations. An agent can prepare the node package:

• process node description;
• equipment and stream list;
• normal operating envelope;
• design pressure and temperature;
• safeguards and trips;
• relevant historical alarms or incidents;
• known modifications and open actions.

For each node, the agent can suggest candidate deviations such as high pressure, low temperature, reverse flow, no flow, high level, low level, wrong composition, or hydrate formation. These suggestions are inputs to a human-led workshop, not automatic findings. The value is preparation: the team starts with a better evidence pack and spends more time on judgement.

6.4 LOPA, SIL, and Barrier Evidence

Layer of Protection Analysis (LOPA) and Safety Integrity Level (SIL) determination require clear initiating events, consequence categories, independent protection layers, frequencies, and risk targets. Agents can help by structuring data and checking consistency.

For example, a high-pressure scenario on a separator may need:

The agent can build a draft LOPA table, but independence of protection layers, credit for human action, common-cause failures, and target risk criteria are discipline decisions. This distinction should appear in the output.

6.5 Relief, Blowdown, and Flare Screening

Relief and flare studies are especially well suited to calculation-backed agents. NeqSim can calculate fluid properties and process states while MCP tools can expose validated routines for flash and process simulation. A workflow may screen blocked outlet, fire case, tube rupture, control-valve failure, or utility failure.

A good screening output includes:

• scenario definition and initiating event;
• fluid composition and thermodynamic model;
• source pressure, temperature, and phase state;
• required relief rate or blowdown rate;
• relief-device or flare-system assumptions;
• model limitations and need for formal verification.

For blowdown, the temperature trajectory can be as important as pressure. Low temperatures may challenge material limits, hydrate formation, CO2 freezing, or brittle fracture margins. The agent should report minimum temperature with the method and model assumptions, not just time to target pressure.

6.6 Safety Studies Linked to STID

Safety studies become stronger when they link directly to as-built evidence. A separator relief check can cite vessel datasheet, PSV datasheet, relief design basis, flare header drawing, cause-and-effect chart, and relevant operating tags. A compressor surge scenario can cite compressor curves, anti-surge valve datasheet, control narrative, and trip history.

The source manifest should be part of the safety artifact. It should list source name, revision, retrieval date, extracted fields, confidence, and reviewer. When a document revision changes, the study can be flagged for review.

6.7 Review Gates for Safety-Relevant Agents

Safety-relevant agent outputs need explicit gates:

These gates do not slow agentic workflows down unnecessarily. They make the accelerated work usable in a safety culture.

6.8 Worked Safety Thread: Separator Throughput Increase

Consider a proposal to raise throughput through an HP separator. A narrow process study might check phase split and liquid residence time. A safety-aware agentic workflow expands the thread.

First, the process model calculates new gas and liquid rates, phase densities, operating pressure, and temperature. The document reader retrieves vessel datasheet, nozzle data, PSV datasheet, cause-and-effect chart, and relevant P&ID extracts. The plant-data agent retrieves current level, pressure, flow, and trip history. The standards skill maps vessel capacity, relief, and barrier requirements. The safety agent then screens deviations: high pressure, high level, liquid carryover, gas blowby, hydrate or wax risk, and relief-load increase.

The result may be a table like this:

This thread does not approve the throughput increase. It tells the team where the safety questions are and what evidence already exists. It also prevents a common failure: treating a capacity calculation as if it automatically covered relief, barriers, and procedures.

6.9 Consequence Screening and CFD Source Terms

Safety studies frequently need to estimate the consequences of a release: thermal radiation from a jet or pool fire, flammable gas concentrations at occupied areas, toxic exposure, or overpressure from a vapor cloud explosion. Full consequence analysis requires specialist CFD tools such as PHAST, FLACS, or KFX. However, the source term --- the release rate, composition, phase state, temperature, pressure, and momentum --- is a thermodynamic and process calculation that NeqSim can provide.

The neqsim.process.safety.scenario package provides a ReleaseDispersionScenarioGenerator that walks a ProcessSystem, discovers high-pressure streams, and builds release scenarios with:

• hole-size taxonomy (small, medium, large, full-bore);
• weather envelope (stability classes, wind speeds);
• source-term properties from NeqSim flash calculations;
• trapped-inventory estimates from vessel and pipe volumes;
• consequence branches (jet fire, flash fire, vapor cloud explosion, toxic).

The GasDispersionAnalyzer in neqsim.process.safety.dispersion connects NeqSim thermodynamics to consequence screening. It auto-selects between a Gaussian plume model for buoyant gases and a dense-gas model for heavy or cold releases. For quick screening, the built-in GaussianPlume class provides downwind concentration estimates at specified distances, stability classes, and release heights.

The CfdSourceTermExporter in neqsim.process.safety.cfd can format the source terms into neutral JSON or OpenFOAM-oriented skeleton files for handoff to specialist CFD analysts. This is a clear example of the boundary between screening and formal analysis. NeqSim calculates the source term and provides screening-level dispersion estimates. The specialist tool provides the detailed field.

The agentic value is that an agent can build the release inventory from the process model, estimate the source term, run screening dispersion, and prepare the CFD input file --- all without manual data transfer between tools. The safety engineer reviews the source terms, approves the scenarios, and runs the formal CFD when warranted. The agent accelerates the preparation; the engineer controls the result.

6.10 Trapped-Liquid Fire Rupture Studies

A blocked-in liquid-filled pipe segment exposed to fire can develop pressure exceeding the pipe or flange rating if no relief device is present. This is a thermal-expansion rupture scenario, often missed in conventional relief studies because it involves piping rather than vessels.

The TrappedLiquidFireRuptureStudy class in neqsim.process.safety.rupture orchestrates a transient screening that requires inputs from multiple document and data sources:

The study models wall heating under fire (API 521 fire heat flux), tracks liquid thermal expansion and pressure rise, checks when the rising pressure exceeds flange-gasket seating pressure or pipe yield, and reports whether passive fire protection (PFP) is needed to extend the time to rupture.

This is an especially strong example of agentic integration because the study cannot be performed from simulation data alone. It needs piping specifications, material certificates, flange data, and fire-zone information. It also cannot be performed from documents alone --- it needs thermodynamic calculations for liquid expansion and phase behavior under heating. The agent that combines both sources produces a screening that would otherwise require a specialist to manually assemble inputs from five or six different systems.

The output includes time-to-rupture, peak pressure, von Mises stress versus allowable stress at each time step, applicable standards, and actionable recommendations. This artifact is ready for review by a piping or safety engineer who can approve, reject, or escalate the screening.

6.11 Limits of Automation in Safety Work

Safety work contains judgements that should not be delegated to a model. Examples include whether two protection layers are truly independent, whether an operator action can be credited, whether a cause is credible for a specific facility, whether a procedural control is robust, and whether residual risk is acceptable. These judgements depend on context, experience, regulations, company requirements, and accountability.

Agents can still help by preparing options. They can draft a bow-tie structure, list candidate barriers, identify missing evidence, and calculate process conditions. They can check whether a report forgot to mention low-temperature embrittlement or flare back-pressure. They can compare scenario assumptions against source documents. But the final safety claim must belong to qualified people in an approved process.

This boundary should be stated in safety outputs. A useful phrase is: "This is an agent-prepared screening based on the sources listed. It is not a HAZOP, LOPA, SIL verification, relief design approval, or management-of-change approval." Such wording may feel cautious, but it protects both the study and the organization.

6.12 Safety Memory and Learning

Safety workflows benefit from controlled memory, but only for reusable lessons, not confidential incident detail. Good memory entries include known API patterns, common data-quality issues, standard review checklists, and generic pitfalls. Poor memory entries include private incident descriptions, asset names, or unreviewed assumptions.

For example, a repository memory may record that blowdown studies should always report both pressure-time and minimum metal-temperature screening, or that relief calculations should state whether pressure is gauge or absolute. A skill may record that HAZOP preparation packages should include cause-and-effect charts, alarm lists, and operating-history summaries. These memories make the next study better without exposing sensitive data.

6.13 Summary

Agents can make safety studies better prepared, more traceable, and faster to screen. They retrieve evidence, structure deviations, map standards, run calculations, and draft artifacts. Human safety processes remain in control of approval and final decisions.

Key points from this chapter:

• Safety studies are evidence and judgement workflows, not just calculations.
• Standards mapping should be tied to specific decisions and calculation methods.
• STID links and source manifests improve traceability for barrier and relief studies.
• Consequence screening and CFD source-term generation connect process simulation to specialist safety tools.
• Trapped-liquid fire rupture studies combine piping documents, material data, and thermodynamic simulation into a screening that no single source can provide alone.
• Safety-relevant agent outputs require explicit human review gates.

Exercises

1. HAZOP package: Build a preparation checklist for a compressor suction scrubber HAZOP node.
2. LOPA evidence: Identify the evidence needed to credit an independent high-pressure trip in a LOPA.
3. Review gate: Define the minimum review gates for an agent-generated relief screening.
4. Source term: For a 50 mm hole in a 100 bar gas line, list the thermodynamic properties an agent needs from NeqSim to prepare a CFD source-term file.
5. Trapped-liquid study: Identify the six categories of input documents needed for a trapped-liquid fire rupture screening on a blocked-in pipe segment.

This chapter uses references from the master bibliography.

Learning Objectives

After reading this chapter, the reader will be able to:

1. Identify routine operational studies that benefit from NeqSim MCP and agents.
2. Describe a decision workflow from question to evidence, calculation, and recommendation.
3. Explain how live or recent plant data changes the frequency and usefulness of studies.
4. Recognize when a fast screening should be escalated to a formal engineering task.

Beyond the online book: The online book's case-study catalogue contains 40+ completed tasks. This chapter shows how those same patterns become repeatable operational workflows: daily hydrate screening, weekly compressor monitoring, root cause analysis, water hammer screening, dynamic simulation, and P&ID-driven what-if studies.

7.1 From Occasional Studies to Continuous Readiness

Many operational questions repeat: Can we increase production today? Is hydrate margin acceptable? Why did compressor power increase? Is the flare load still inside expected limits? Which operating condition drives CO2 emissions? Should a heat exchanger be cleaned during the next opportunity?

Historically, these questions often became studies only when the potential value was high enough to justify data gathering and model setup. With an MCP-enabled NeqSim workflow, the threshold can be lower. Agents can keep the evidence path short: retrieve current data, run the relevant model, compare against limits, and produce a short result that is ready for engineering review.

The goal is continuous readiness, not uncontrolled automation. The organization builds a library of workflows that are ready to run when the question appears.

7.2 A Generic Decision Workflow

A practical operational workflow has seven steps:

1. state the decision and time horizon;
2. identify required data and approved sources;
3. retrieve and quality-check evidence;
4. select or update the NeqSim model;
5. run base case and sensitivities;
6. compare results with criteria;
7. issue recommendation, limitations, and escalation need.

This structure prevents the agent from jumping straight to a calculation. For example, "Can we raise gas export by 5% for the next 24 hours?" is not a pure compressor calculation. It may involve well deliverability, separator liquid handling, compressor driver margin, dew point, export pressure, flare constraints, and power emissions. The agent should either run the relevant multi-area workflow or state that the evidence is insufficient.

7.3 Flow Assurance Screening

Flow assurance is a natural operational use case. Hydrate formation, wax risk, liquid loading, and arrival temperature depend on changing production, composition, pressure, temperature, and inhibitor injection. A daily or weekly screening can combine historian data, lab composition updates, and pipeline models.

An agentic hydrate-margin workflow may:

• retrieve recent pressure, temperature, water content, and flow tags;
• validate composition and inhibitor data;
• run NeqSim hydrate or phase-envelope calculations;
• compare predicted hydrate temperature to operating temperature;
• flag cases where margin is below the operational criterion;
• prepare a recommendation for chemical injection or operating adjustment.

The output should include the method, EOS or hydrate model, selected time window, and uncertainty. If the result is near the limit, the workflow should escalate to a flow-assurance specialist rather than presenting a final answer.

7.4 Compressor and Energy Monitoring

Compression is often one of the largest energy consumers offshore and onshore. Small deviations in suction temperature, molecular weight, recycle, fouling, or driver efficiency can have large power and emissions impacts. Agentic workflows can combine process simulation with historian and vendor evidence to produce regular performance checks.

Typical indicators include:

NeqSim provides thermodynamic properties and compressor calculations. Tags and vendor curves provide reality checks. SAP context can explain whether a trend matches known maintenance events.

7.5 Production Optimization

Agentic workflows can also support production optimization. A modular field model can test multiple production scenarios while respecting equipment constraints. The agent can vary well rates, separator pressures, compressor set points, or pipeline arrival pressures, then report bottlenecks and trade-offs.

The important engineering control is constraint transparency. The workflow must state what limits were enforced: maximum compressor power, minimum hydrate margin, separator liquid capacity, export pressure, emissions cap, flare restriction, or reservoir drawdown limit. Without transparent constraints, optimization results are not trustworthy.

7.6 Integrity and Maintenance Planning

Access to SAP and inspection data enables operational studies that combine performance and integrity. For example:

• Heat exchanger cleaning priority based on duty loss, production impact, and planned maintenance windows.
• Control-valve replacement priority based on valve position saturation, pressure-drop loss, and spare availability.
• Compressor wash or inspection timing based on efficiency trend and known maintenance history.
• Separator inspection planning based on water production, corrosion risk, and capacity sensitivity.

These are not pure simulations. They are decision workflows where simulation quantifies impact and enterprise data constrains action.

7.7 When to Escalate

A fast operational screening should escalate when:

• the result is close to a safety or operating limit;
• source data quality is poor or conflicting;
• the model is outside its validation envelope;
• the recommendation changes a controlled operating procedure;
• the decision affects safety, environment, production commitments, or major cost.

Escalation is a success condition, not a failure. It means the workflow found a question that deserves formal engineering attention.

7.8 Operating Rhythm

Operational workflows become more valuable when they have a rhythm. Not every calculation should be run continuously, and not every workflow needs the same review depth. A useful operating rhythm might be:

This rhythm helps teams avoid two extremes: never using the model until a major study is needed, or running too many automatic calculations with no review path. Each workflow should have a trigger, owner, expected output, and escalation criterion.

7.9 Economics and Emissions in Operations

Operational decisions are rarely technical only. A compressor recycle loss has a power cost and an emissions cost. A heat exchanger cleaning may recover production but require shutdown time. A production increase may improve revenue while increasing fuel gas and CO2 emissions. Agentic workflows can bring these dimensions into the same decision table.

For example, a compressor optimization workflow can calculate:

• additional export gas from a pressure-setpoint change;
• additional driver power and fuel gas;
• incremental CO2 emissions;
• hydrate or dew-point margin;
• compressor operating margin;
• estimated economic value over the operating period.

This does not replace a formal economic model, but it helps operations see trade-offs. A recommendation such as "increase production" is weaker than "increase production only if suction temperature remains below the defined limit, recycle stays closed, and incremental CO2 intensity remains inside the weekly target." The second recommendation is operationally useful because it links action to constraints.

7.10 Human Interfaces

The best operational agent is not one that produces the longest report. It is one that produces the right level of information for the decision. A control-room advisory view may need a short status: margin, trend, confidence, and action. A process engineer may need the full source manifest and sensitivity table. A technical authority may need validation history and standards basis.

Good interfaces separate these layers. The same workflow can produce a compact dashboard card, a detailed notebook, and a formal report. MCP tool outputs and task artifacts make this possible because the underlying results are structured. The interface can choose how much to display without changing the calculation.

The human interface should also show uncertainty and stale data clearly. A green status based on yesterday's composition should not look identical to a green status based on a current lab update. A hydrate margin of 2.0 °C with high data confidence is not the same as 2.0 °C with missing inhibitor data. Agents should surface these differences in the UI and report text.

7.11 Root Cause Analysis: Combining Data, Documents, and Simulation

When equipment trips, vibrates, loses efficiency, or behaves unexpectedly, the traditional response is a manual investigation. An engineer gathers historian trends, reads the datasheet, reviews maintenance history, runs a simplified calculation, and proposes a hypothesis. The process is thorough but slow, and the quality depends heavily on how many data sources the engineer thinks to check.

NeqSim's RootCauseAnalyzer in the neqsim.process.diagnostics package implements a Bayesian-inspired methodology that an agent can orchestrate as a single coherent workflow. The three stages are:

1. Prior (OREDA failure data). The analyzer uses OREDA-derived failure-mode frequencies for the equipment type to set initial hypothesis probabilities. For a centrifugal compressor reporting high vibration, the prior might rank rotor imbalance, bearing wear, surge events, coupling misalignment, and fouling by their known failure rates.

1. Likelihood (historian and document evidence). The analyzer takes historian time-series data, STID design conditions, and operating limits, and updates each hypothesis score based on how well the evidence matches. If the vibration trend correlates with increasing suction pressure and decreasing anti-surge valve opening, surge-related hypotheses rise. If bearing temperature is stable, bearing-wear hypotheses fall.

1. Verification (process simulation). The analyzer can optionally run the NeqSim process model to test whether a hypothesized failure reproduces the observed symptoms. If fouling is a hypothesis, the model can be run with reduced efficiency to check whether the predicted discharge conditions match the observed discharge pressure and temperature.

The result is a RootCauseReport with ranked hypotheses, confidence scores, evidence citations, and recommendations --- all structured as JSON that can feed a task report or an operational dashboard.

Why this matters for agentic engineering

The RootCauseAnalyzer is a concrete example of a class that cannot work in isolation. It needs data from a historian (field measurements), context from STID documents (design limits, datasheet conditions, maintenance history), and computational capability from NeqSim (flash, process model, equipment performance). No single tool or data source is sufficient. The agent orchestrates all three, and the RootCauseAnalyzer provides the structured methodology that makes the combination rigorous rather than ad-hoc.

An MCP tool (runRootCauseAnalysis) exposes this to any MCP client. The agent sends a JSON object containing the process description, equipment name, symptom type, and optionally historian CSV data, design limits, and STID context. The runner builds the ProcessSystem, creates the RootCauseAnalyzer, runs the analysis, and returns the structured report. The agent does not need to know the internal scoring algorithm. It needs to know how to gather evidence from its available data sources and present it in the expected format.

Example: compressor high vibration

An agent receiving a report of high vibration on a compressor might execute the following workflow:

1. Retrieve the compressor performance curve and design limits from STID.
2. Read historian tags for suction and discharge pressure, temperature, flow, speed, vibration, and anti-surge valve position.
3. Read maintenance history from SAP for recent work orders on the compressor.
4. Build the process model from the existing modular field model.
5. Call runRootCauseAnalysis with the process JSON, equipment name, HIGH_VIBRATION symptom, historian data, and design limits.
6. Receive a ranked hypothesis report: surge margin violation (68%), rotor imbalance (15%), bearing degradation (10%), other (7%).
7. Present the report to the operations or rotating-equipment engineer with evidence citations and recommended actions.

The value is not that the agent replaces the engineer. It is that the evidence package and hypothesis ranking arrive in minutes rather than hours, with every data source cited and every deviation quantified.

7.12 Operational Scenarios: What-If Studies from P&IDs

Operational what-if studies are among the most frequent requests in facility engineering. What happens if we close this valve? What if suction pressure drops 5 bar? What if the feed composition changes? What if we apply the current field data and then change one parameter?

NeqSim's OperationalScenarioRunner provides a structured way to define and execute these studies. An OperationalScenario is an ordered list of OperationalAction objects, each specifying an action type and target:

A P\&ID-derived scenario might look like this:

OperationalScenario scenario = OperationalScenario.builder("Close bypass valve")
    .addAction(OperationalAction.applyFieldInputs())
    .addAction(OperationalAction.setValveOpening("XV-2001", 0.0))
    .addAction(OperationalAction.runSteadyState())
    .build();

The OperationalScenarioRunner executes the scenario on a cloned process system, collects before-and-after values for all bound tags, and returns a structured comparison. The agent can run multiple scenarios and present the results as a decision table.

This is how agentic engineering connects to real plant operations. The agent reads a P\&ID to identify the relevant valves and instruments. It reads the historian to get current boundary conditions. It constructs scenarios that represent proposed operating changes. It runs the simulation and returns quantified consequences. The P\&ID, the historian, and the simulation are all required. Removing any one of them makes the study either disconnected from reality or unable to predict consequences.

7.13 Controller Tuning from Historian Data

Control loops are rarely tuned once and forgotten. Operating conditions change, equipment degrades, and control objectives shift. The ControllerTuningStudy class in neqsim.process.operations evaluates controller performance using time-domain metrics computed from a step response:

The study takes pre-recorded time-series arrays --- controller name, setpoint, time stamps, process values, and controller output --- evaluates the step response, and returns a structured ControllerTuningResult with all metrics, a stability assessment, and a recommendation (acceptable, needs tuning, or unstable). An agent can retrieve historian step-response data from a tagreader, pass it to the study for evaluation, and flag controllers that show degraded performance.

This is a practical example of a study that was previously too labor-intensive for routine execution. A process engineer might tune a few critical loops per year. An agentic workflow can screen all loops in a process area weekly, flagging only those that need human attention. The historian provides the evidence; the simulation provides the prediction; the comparison drives the recommendation.

7.14 Water Hammer and Transient Screening

Rapid valve closures, pump trips, and check-valve events can generate pressure surges that threaten pipe integrity. Water hammer screening traditionally requires route geometry, fluid properties, wall thickness, valve closure profiles, and surge-propagation calculations. These inputs come from different systems: piping design from STID line lists, fluid properties from the process model, valve closure times from control narratives or instrument datasheets, and operating conditions from the historian.

NeqSim's WaterHammerStudy class orchestrates this multi-source workflow. It accepts a JSON specification with:

• route geometry (pipe segments with length, diameter, elevation, wall thickness);
• fluid specification or a reference to the process model;
• event schedule (valve closure profile, pump trip timing);
• optional tagreader overrides for actual operating conditions;
• acceptance criteria (design pressure, MAOP).

The study builds a WaterHammerPipe model from the specification, applies field-data overrides where available, runs the transient calculation, and returns a pressure envelope with peak surge, Joukowsky estimates, and pass/fail against design pressure.

The agentic value is integration. An agent can:

1. Extract route geometry from a piping line list retrieved from STID.
2. Get current fluid properties from the process model.
3. Read valve closure time from the control narrative document.
4. Read current operating pressure and flow from historian tags.
5. Run the water hammer screening with all inputs combined.
6. Compare peak surge against design pressure from the pipe specification.

Without the agent, this study requires a specialist to manually collect inputs from five or six systems. With the agent, the inputs are gathered and validated programmatically, and the engineer reviews the result rather than the data collection.

7.15 Dynamic Simulation as Operational Infrastructure

Sections 7.13 and 7.14 showed controller tuning and water hammer as specific dynamic-simulation use cases. But dynamic simulation is a broader operational capability that deserves explicit framing. Steady-state models answer "what does the process look like at equilibrium?" Dynamic models answer "what happens between now and equilibrium?"

Operational decisions that need dynamic simulation include:

In NeqSim, the transition from steady-state to dynamic is handled by the same ProcessSystem. The agent calls process.run() for steady-state and process.runTransient(dt) for dynamic steps. The DynamicProcessHelper class provides configuration for initial holdup, controller tuning parameters, and time-step management.

The agentic workflow for a dynamic study typically follows this pattern:

1. Initialize from steady-state. Run the process model to convergence at normal operating conditions. This sets the initial holdup, pressure, and temperature profiles.
2. Define the event. Specify what changes: a valve closes, a trip signal fires, a feed rate drops, or a setpoint changes.
3. Run the transient. Step through time, recording key variables at each step.
4. Evaluate the response. Check whether pressures, temperatures, levels, and controller outputs stay within acceptable limits. Check whether the system returns to a stable state.
5. Report. Present the time-domain response with key metrics: peak pressure, minimum temperature, settling time, and pass/fail against acceptance criteria.

The MCP server exposes this through the runDynamic tool, which accepts a JSON specification with time-step size, total duration, event schedule, and recording variables. The agent does not need to write a Java simulation loop. It describes the scenario and receives structured time-series results.

Dynamic simulation is particularly valuable when combined with real-time or recent historian data. An agent can read the current operating conditions from historian tags, initialize the dynamic model at those conditions, and then simulate a proposed event. The result shows what would happen if that event occurred right now — a far more actionable answer than a simulation based on design-case conditions from years ago.

7.16 Production Data, Project Documents, and Modification Context in Operations

Operational workflows draw on more than simulation and instrumentation. Three additional data categories from the operational data ecosystem (Chapter 1) deserve explicit treatment in the operational context.

7.16.1 Production Data as Operational Intelligence

Production databases contain well test results, daily production reports, and allocation data. These are not raw sensor readings — they are processed, validated, and often fiscally binding numbers. For operational process simulation, production data serves three purposes:

1. Reservoir boundary conditions. The latest well test provides the actual GOR, water cut, wellhead pressure, and flow rate for each well. A facility simulation that uses design-case well data may be significantly wrong if the reservoir has matured.

1. Throughput validation. Daily production reports provide measured total rates that the simulation should reproduce. If the model predicts 10% higher gas production than the daily report shows, either the model inputs are wrong or a measurement is off.

1. Trend context. Declining well rates, increasing water cut, or changing GOR over months provide the context for operational decisions. A recommendation to increase production rate must consider whether the wells can actually deliver the higher rate.

The agent pattern is to read the latest well test data, set the simulation boundary conditions accordingly, and flag any discrepancy between modeled and reported production. If the well test is more than three months old or the allocation balance is off by more than a threshold, the agent should report this as a data currency or consistency risk.

7.16.2 Project Documentation for Operational Studies

Project documentation provides the design intent: what the facility was designed for, what margins were assumed, and what acceptance criteria were set. In operational studies, project documentation answers questions like:

• What was the original design flow rate for this separator?
• What composition range was the compressor designed for?
• What hydrate margin was required at the design stage?
• Was a higher throughput scenario evaluated and rejected? If so, why?

An agent that retrieves the design basis memorandum or FEED report before running a capacity screening can compare "current operation vs. design intent" rather than just "current operation vs. model prediction." This comparison is far more useful for decision-making because it shows whether the facility is operating inside or outside its design envelope.

7.16.3 Modification Management as Operational Context

Modification records from SAP, MOC systems, or project planning tools provide essential context for operational recommendations. Before recommending a process change, the agent should check:

• Is there a pending modification that affects this equipment?
• Has the recommended change been evaluated before? What was the outcome?
• Is the current configuration temporary due to an in-progress modification?

This prevents the agent from producing recommendations that conflict with approved changes or repeat work that has already been done. It also allows the agent to recognize when a simulation should use the as-will-be configuration (after a pending modification) rather than the as-is configuration.

7.17 The Evidence Package as Integration Pattern

The individual studies described above --- root cause analysis, operational scenarios, controller tuning, water hammer --- share a common integration pattern. Each one combines technical documentation, field measurement data, and NeqSim simulation into a structured, auditable output. The OperationalEvidencePackage class formalizes this pattern.

An evidence package is built from:

• a process system (the simulation model);
• a tag map (the binding between plant tags and simulation variables);
• field data (historian values for the current operating window);
• scenarios (what-if operating changes);
• a benchmark tolerance (the acceptable model-versus-plant deviation).

The package runs the base case, applies field data, compares model predictions against field measurements, executes all scenarios, identifies bottlenecks, and returns a single JSON object that contains all evidence, all deviations, and all scenario comparisons.

This is the key architectural insight of agentic engineering in NeqSim. The value does not come from faster flash calculations or better EOS models, though those matter. The value comes from the structured orchestration of multiple data sources into a single, reviewable evidence chain. The agent is the coordinator. The tag map is the bridge. The evidence package is the deliverable.

The pattern is extensible. A safety study can add barrier evidence to the same package. An economics study can add cost and emissions data. A maintenance study can add SAP work-order context. Each extension adds a new evidence dimension without changing the orchestration pattern.

7.18 Summary

Operational workflows turn NeqSim MCP and agents into a repeatable decision support system. They can make routine studies faster and more frequent while keeping human review and escalation at the center. The new infrastructure in neqsim.process.operations and neqsim.process.diagnostics provides concrete classes that combine technical documents, field data, and simulation into structured evidence packages, root-cause reports, scenario comparisons, and transient screenings.

Key points from this chapter:

• Agentic workflows lower the effort required to run evidence-backed operational studies.
• Flow assurance, compression, energy, production optimization, and maintenance planning are strong use cases.
• Root cause analysis combines OREDA priors, historian evidence, and process simulation into ranked hypotheses.
• Operational scenarios execute P\&ID-derived what-if studies with before/after comparison.
• Controller tuning studies screen loop performance from historian step responses and simulated transients.
• Water hammer screening orchestrates route geometry, fluid properties, valve events, and field data.
• Dynamic simulation complements steady-state for time-dependent decisions: depressurization, startup, surge, and upset recovery.
• Production databases provide reservoir boundary conditions, throughput validation, and trend context for operational models.
• Project documentation anchors operational recommendations to design intent and acceptance criteria.
• Modification management prevents recommendations that conflict with approved or pending changes.
• The evidence package is the integration pattern: tag map, field data, scenarios, and simulation in one auditable artifact.
• Optimization must expose constraints and validation limits.
• Screenings should escalate when limits, data quality, or controlled procedures are involved.

Exercises

1. Hydrate workflow: Design a daily hydrate-margin screening workflow with required tags, model calls, and escalation rules.
2. Compressor energy: Define three compressor performance indicators and the data needed to calculate them.
3. Optimization constraints: List the constraints that should be enforced in a short-term production-increase study.
4. Root cause analysis: A separator shows increasing liquid carryover to the gas outlet. List the data sources an agent should gather, the symptom type, and three candidate hypotheses with the evidence that would support or refute each.
5. Operational scenario: Define a three-action operational scenario for testing the effect of closing a bypass valve around a heat exchanger, starting from current field conditions.
6. Evidence package: Describe the structure of an evidence package for a weekly compressor performance review, listing tag bindings, tolerance criteria, and escalation conditions.

This chapter uses references from the master bibliography.

Learning Objectives

After reading this chapter, the reader will be able to:

1. Define quality requirements for MCP-backed engineering workflows.
2. Explain validation, provenance, audit trails, access control, and model risk.
3. Select appropriate deployment controls for desktop, study-team, advisory, and enterprise use.
4. Plan a staged adoption roadmap from bounded pilots to maintained industrial capability.

Beyond the online book: The online book explains MCP validation profiles and future directions. This chapter combines the organizational side: quality gates, acceptance testing, data access, change management, training, deployment architecture, and adoption metrics.

8.1 Governance Is Part of the Product

An MCP server that exposes process-simulation tools is not only software. It becomes part of the engineering work system. If it is easy to run a calculation, it is also easy to run the wrong calculation quickly. Governance is therefore not a layer added after the tool works. It is part of making the tool useful.

Quality requirements should be visible in every workflow:

• validated input schema;
• explicit units and basis;
• model and version metadata;
• benchmark or validation basis;
• source provenance;
• warnings and limitations;
• human review status;
• durable artifacts.

The MCP contract helps because tool input and output are structured objects. A result can carry convergence status, warnings, and provenance rather than being reduced to a single attractive number.

8.2 Validation and Benchmark Trust

Validation has several layers.

An agent should report all relevant layers. A converged calculation can still be inappropriate outside its domain. A benchmarked tool can still be misused if the input data is stale or wrong.

8.3 Audit Trails and Artifacts

Industrial workflows need durable artifacts. The minimum useful package for a standard study is:

• task specification;
• source manifest;
• input data file or model state;
• notebook, script, or MCP transcript;
• structured result object such as results.json;
• figures and tables;
• final report;
• review notes and open assumptions.

The report is the readable summary of a traceable calculation package. It should not be the only evidence that the work happened.

8.4 Data Access and Cybersecurity

Connecting agents to STID, historians, SAP, production databases, and project documents increases value and risk. Access should follow least privilege. A document retrieval agent should only see documents relevant to the task and user authorization. A tagreader integration should normally read approved tags, not write to plant systems. Enterprise adapters should expose selected context, not broad records.

Important controls include:

• identity and access management tied to user or service account;
• read-only access for operational advisory workflows;
• approved storage and egress paths;
• logging of queries and retrieved documents;
• redaction rules for public or reusable outputs;
• separation between development, study, and production environments.

The agent is a new interface, not a new permission model.

8.5 Deployment and Adoption Controls

Different deployment contexts need different controls.

The same tool can be appropriate in one context and inappropriate in another. Experimental multi-step task solving may be suitable for desktop learning. Enterprise advisory should use validated tools, restricted profiles, and known review routes.

8.6 Model Risk and Quality Culture

Model risk is the risk that a model gives a wrong or misleading result. Agentic workflows can reduce model risk by improving evidence capture, but they can increase it by producing polished reports quickly. Governance should therefore ask:

• Is the model domain clear?
• Are assumptions listed?
• Are units and basis consistent?
• Are uncertainties or sensitivities included where needed?
• Are limitations visible in the recommendation?
• Can the result be reproduced from stored artifacts?

The strongest control is quality culture. Engineers should ask for provenance, limitations, benchmark basis, and source quality. They should reject unsupported confidence. A tool result with a warning is usually more valuable than fluent prose without evidence.

A useful default prompt is:

Use NeqSim tools where possible. Report model, units, input validation,
convergence status, warnings, benchmark basis, source provenance, and whether
this is a screening or design-level result.

8.7 Acceptance Testing for MCP Tools

Before an MCP tool is used in a governed workflow, it should have acceptance tests that engineers can understand.

Acceptance tests turn the tool catalogue into something reviewable. When a tool says it calculates a dew point, the team should know which benchmark cases support that claim.

8.8 Change Management for Skills and Agents

Skills and agents influence engineering outcomes, so they need change management. A skill update that changes a hydrate-margin workflow, relief screening checklist, or standards mapping is not just text editing. It changes how future work is performed.

A practical change process is:

1. propose the skill or agent change in version control;
2. state the reason and affected workflows;
3. include examples or tests where possible;
4. review by a domain owner and tool owner;
5. release with a version note;
6. monitor early use and capture lessons.

Domain knowledge used by agents should be visible and reviewable. Hidden prompt edits should not become the basis for shared engineering decisions.

8.9 Redaction and Reuse

Completed studies can teach the organization, but they may also contain private data. Teams should separate reusable method from confidential evidence.

Reusable knowledge includes generic workflows, public examples, code patterns, validation methods, and anonymized lessons. Confidential evidence includes asset names, equipment tags, internal document titles, proprietary operating data, commercial assumptions, and incident details.

When a study produces a useful skill improvement, extract the pattern and remove the private context. This allows learning without leaking sensitive details.

8.10 Adoption Roadmap

The adoption roadmap should move from bounded pilots to maintained capability.

Each stage should produce reusable artifacts, not only demonstrations. Progress is measured by how much future work becomes easier, safer, and more traceable.

8.11 Capability Stack

Adoption should build a stack, not a collection of demos.

Better document retrieval improves many workflows. Better tag mapping improves hydrate, compression, energy, and safety studies. Better standards mapping improves safety, mechanical design, and field development.

8.12 Training and Community of Practice

The technology roadmap needs a people roadmap. Engineers need training in MCP tool use, prompt patterns, source provenance, model validation, and review responsibility. New users should start with public examples, inspect tool calls, and learn how to distinguish a tool-backed answer from unsupported language-model prose.

A community of practice can collect good prompts, review skill updates, share task templates, compare validation cases, and discuss failures. The most useful sessions are not demonstrations where everything works. They are reviews where a team asks what evidence was missing and how the skill or tool should improve.

8.13 Reference Architecture

A mature enterprise architecture may contain these components.

The desktop Docker workflow is still useful. The reference architecture simply prevents pilots from growing into ungoverned production systems.

8.14 Measuring Value

Agentic engineering should be measured by engineering value, not novelty. Useful metrics include:

• time from question to reviewed screening result;
• number of scenarios evaluated per study;
• reduction in manual data gathering;
• number of reusable skills or workflows created;
• validation pass rate and warning trends;
• number of studies escalated appropriately;
• avoided rework from stale or missing data;
• production, energy, emissions, or maintenance value identified.

Some value is qualitative: better traceability, clearer assumptions, and more consistent reports. These matter because engineering organizations often lose time when assumptions are unclear and evidence is scattered.

8.15 Summary

Governance and adoption are one subject. The same controls that make agentic workflows safe also make them scalable: validation, provenance, artifacts, access control, change management, training, and review gates. MCP provides the structured interface. NeqSim provides the physics. Agents and skills provide workflow intelligence. Industrial value appears when these pieces are adopted as a maintained engineering capability rather than a set of isolated demonstrations.

Key points from this chapter:

• Quality requirements should be built into MCP tools and agent workflows.
• Validation includes input, numerical, engineering, benchmark, and human review layers.
• Data integrations must follow existing access-control and cybersecurity rules.
• Skills and agents should be versioned, reviewed, and owned like engineering methods.
• Adoption should proceed through bounded pilots, governed data integration, modular models, advisory workflows, and enterprise scaling.

Exercises

1. Quality checklist: Build a minimum quality checklist for an MCP flash calculation used in a report.
2. Pilot design: Choose one pilot workflow and define value, data sources, validation, and review gates.
3. Capability maturity: Rate a current team against the maturity stack and identify the next improvement.

This chapter uses references from the master bibliography.

Learning Objectives

After reading this chapter, the reader will be able to:

1. Follow a complete agentic workflow from field-level question to equipment and safety follow-up.
2. See how NeqSim MCP, modular models, STID retrieval, historian data, and SAP context fit together.
3. Distinguish evidence, simulation, interpretation, and recommendation in a worked pattern.
4. Reuse the pattern for similar studies without copying asset-specific details.

Beyond the online book: The online book provides fifteen standalone worked examples and forty case study summaries. This chapter combines those elements into a single end-to-end industrial pattern: from field-level question through modular model, equipment detail threads, flow assurance, safety screening, root cause analysis, dynamic simulation, and an integrated recommendation — showing how the pieces fit together in a real study.

9.1 Scenario and Question

This chapter uses a fictional but realistic field-development and operations pattern. The example avoids private asset names, equipment tags, and proprietary data. The goal is to show the workflow shape, not to document a real facility.

The facility processes gas condensate from an offshore production system. A satellite reservoir is being considered for tieback to the existing host. The study team wants to know whether the host can process an additional production case during the first two years of tieback operation without major modification. The early question is deliberately broad:

Screen whether the existing host can process an additional gas-condensate
tieback case. Use a modular NeqSim field model, approved document evidence,
recent operating data where relevant, and agentic equipment and safety follow-up.
Return bottlenecks, study limits, and recommended next engineering work.

This is not a design approval. It is a structured screening study. The expected output is a ranked list of constraints and a recommendation about which detailed studies should be performed next.

9.2 Task Classification

The first agent action is classification. The task is not a single flash calculation. It spans process simulation, flow assurance, equipment capacity, safety screening, and operational data. A router or study lead can divide the work into packages:

The study lead approves this split before data retrieval begins. This approval is useful because it prevents an agent from pursuing irrelevant detail too soon.

9.3 Evidence Plan

The evidence plan identifies which data sources will be used and what each source is allowed to support. The plan is intentionally explicit.

The source manifest records every retrieved document and tag window. If a compressor map is unavailable, the study uses a conservative screening curve and marks the compressor result as low confidence. If historian tags are missing or bad quality, the base-case calibration step is skipped rather than silently using poor data.

9.4 Modular Field Model

The process-simulation agent builds a modular model with four process areas:

1. Subsea and pipeline: wellstream source, pipeline pressure drop, arrival temperature.
2. Inlet and separation: inlet cooling, slug catcher or separator, HP/LP separation.
3. Compression and export: scrubbers, compressors, coolers, dehydration, export pressure.
4. Utilities and safety interfaces: fuel gas, power demand, relief-load screening interfaces.

The model starts with a base host case. It is validated against recent operating data by comparing key outputs: separator pressure, export compressor suction temperature, export pressure, fuel gas use, and liquid rates. The tieback case then adds an incremental wellstream and reruns the field model.

The important artifact is not only the model. It is the scenario state. The state records the base case, the tieback case, changed inputs, source manifest, and acceptance criteria. This state lets later equipment and safety agents refer to the same scenario without rebuilding context from prose.

9.5 Illustrative Field-Level Results

The following numbers are illustrative screening values for the pattern. A real study would replace them with NeqSim MCP or notebook outputs and source-backed input data.

The field-level screen identifies two likely constraints: export compression and hydrate margin. It also identifies two follow-up areas: separator internals and relief/blowdown. The agent does not conclude that the host can accept the tieback. It concludes that the case is worth further study if compressor and hydrate constraints can be addressed.

9.6 Compressor Detail Thread

The compressor thread starts from the field model. The tieback case gives suction flow, suction pressure, suction temperature, gas composition, discharge pressure, and required power. The equipment agent then retrieves compressor evidence.

The source manifest includes the compressor datasheet, performance map, anti-surge control description, driver rating, and recent operating tags. The plant-data agent selects a recent steady-state window to compare actual and modelled performance. SAP context indicates whether recent maintenance work may affect efficiency or availability.

The compressor thread asks four questions:

The illustrative result is that driver margin is the tightest compressor limit, while surge margin remains acceptable for the base tieback case. The workflow therefore returns a facility constraint: export flow must be limited unless driver margin is recovered or compression is modified. It also returns a next action: confirm compressor map and driver limits with a compressor specialist.

9.7 Flow Assurance Thread

The flow assurance thread evaluates arrival pressure, arrival temperature, and hydrate margin. The agent retrieves pipeline length, elevation, insulation or heat-transfer assumptions, seabed temperature range, inhibitor strategy, and historical operating data. The NeqSim model calculates phase behaviour and hydrate temperature along relevant operating points.

The screening finds that the normal warm case has acceptable margin, while a cold low-flow restart case is close to the hydrate limit. This changes the study conclusion. The tieback may be feasible at steady high flow, but startup, turndown, and shutdown conditions require a more detailed transient or operating procedure study. A production-increase screen that only looked at steady-state export would have missed the controlling case.

9.8 Separator and Liquid Handling Thread

The separator thread uses the tieback fluid and field-model rates. STID datasheets provide separator diameter, length, normal liquid level, high-high level, inlet device, demister type, and nozzle sizes. NeqSim provides densities, viscosities, surface tension, gas and liquid rates, and phase split.

The screening checks gas load factor, liquid retention time, inlet momentum, and demister velocity. The illustrative result is that average capacity remains inside screening limits, but slug or transient liquid handling is not addressed. The recommendation is therefore to perform a dynamic liquid-handling check if the tieback profile has high slugging uncertainty.

This thread shows why field and equipment levels need each other. The field model identifies the increased liquid rate. The equipment study asks whether the actual vessel and internals can handle it. The safety thread then asks whether larger liquid inventory affects relief or blowdown assumptions.

9.9 Safety Thread

The safety thread does not redo the HAZOP. It prepares a screening package. It uses the field and equipment results to identify which safety studies may need update.

The safety output is an escalation map. It states that the tieback screening is not sufficient for management of change. It identifies the formal studies that would be needed before any operating limit or design basis changes.

9.10 Integrated Recommendation

The final recommendation should be short, evidence-based, and honest about uncertainty:

The screening indicates that the host may be able to process the illustrative
tieback steady-state case, but export compressor driver margin and cold-case
hydrate margin are controlling constraints. Separator average capacity appears
less limiting than compression, but liquid-handling dynamics and internals need
review. Safety follow-up is required for relief, blowdown/MDMT, compressor
protection, and HAZOP node updates before any operating envelope change.

The recommendation also lists immediate next work:

1. validate compressor map and driver rating against approved vendor documents;
2. run cold-case flow assurance with uncertainty in ambient and inhibitor assumptions;
3. perform separator internals and slug-handling review;
4. screen relief and blowdown impacts using approved safety methods;
5. update economics and emissions if technical constraints can be managed.

9.11 Remarks on the Illustrative Results

All results in this chapter are illustrative. They use representative but fictitious data: fluid compositions, equipment sizes, tag names, and operating conditions are invented for educational purposes. No real field or operator is named. The value of the worked case is the workflow, not the numbers. The same pattern --- evidence plan, modular model, threaded studies, integrated recommendation --- applies to any real field study.

9.12 Root Cause Analysis Thread: Compressor Vibration

Suppose the tieback has been in operation for six months. The export compressor begins reporting elevated vibration. Operations raises the question: What is causing the vibration increase, and is it related to the changed operating conditions?

This is a root cause analysis (RCA) problem. It cannot be solved by simulation alone, because the cause may be mechanical, process-related, or both. It cannot be solved by documents alone, because the documents describe design conditions, not the current fault. It cannot be solved by historian data alone, because correlation does not identify mechanism. The value of agentic integration is that it combines all three.

Agent workflow

The agent executes the following steps:

1. Retrieve evidence from STID. The document reader retrieves the compressor datasheet, performance map, vibration alarm setpoints, bearing clearance specification, and anti-surge valve datasheet.

1. Retrieve historian data. The plant-data agent reads suction and discharge pressure, temperature, flow, speed, bearing temperatures, vibration levels, and anti-surge valve position for a window surrounding the event. It classifies the time-series into pre-event baseline and post-event deviation.

1. Build the process context. The process simulation agent uses the existing modular field model with the current operating composition and boundary conditions.

1. Run root cause analysis. The agent calls runRootCauseAnalysis through MCP with:

• the process JSON from the field model;
• equipment name: the export compressor;
• symptom: HIGH_VIBRATION;
• historian data: the time-series CSV;
• design limits: vibration alarm level, bearing temperature limit, surge margin limit from the datasheet;
• STID data: compressor type, bearing type, last maintenance date.

1. Receive the ranked hypothesis report. The RootCauseAnalyzer runs its three-stage methodology:

• Prior: OREDA failure frequencies for centrifugal compressors rank bearing degradation, rotor imbalance, surge, fouling, seal issues, and coupling misalignment by their base rates.
• Likelihood: The historian evidence updates the scores. If suction pressure has been trending lower and anti-surge valve has been opening more frequently, surge-related hypotheses rise. If bearing temperatures are stable, bearing degradation falls.
• Verification: The process model is run with reduced surge margin to check whether the predicted operating point matches the observed conditions. If the model reproduces the vibration-correlated conditions when operating near the surge line, the surge hypothesis is strengthened.

1. Present the result. The report might rank:

1. Recommend actions. The report suggests: confirm surge margin with specialist using approved compressor map; review anti-surge controller tuning for the post-tieback composition; consider whether a process adjustment (higher suction pressure or lower flow) can restore surge margin while the root cause is investigated.

Why this thread matters

The RCA thread demonstrates the defining pattern of agentic engineering: no single data source or tool could have produced this result. OREDA provides the statistical prior. The historian provides the operational evidence. The STID documents provide the design context. The NeqSim simulation provides the physical verification. The RootCauseAnalyzer class provides the structured methodology that combines them. The MCP tool makes the entire workflow accessible to any agent or client through a single JSON-RPC call.

This is not a replacement for a rotating-equipment specialist. It is a structured evidence package that arrives on the specialist's desk with ranked hypotheses, cited data, and quantified confidence --- instead of a vague request to "investigate vibration."

9.13 Operational Evidence Package: Weekly Compressor Review

Beyond event-driven RCA, the same integration pattern supports routine operational monitoring. Suppose the facility runs a weekly compressor performance review. The agent builds an OperationalEvidencePackage that combines the tag map, field data, and process model into a single reviewable artifact.

Tag map

The OperationalTagMap binds eight logical tags to historian tags and simulation addresses:

Weekly workflow

1. The plant-data agent reads the historian tags for the last week and selects a representative steady-state window.
2. The field data is applied to the process model through the tag map.
3. The model runs with the field boundary conditions.
4. The evidence package compares model predictions against field measurements for every bound tag and flags deviations beyond the 5% benchmark tolerance.
5. Two operational scenarios are run:

• Scenario A: increase throughput by 10% from current conditions.
• Scenario B: reduce suction pressure by 3 bar (simulate a well decline case).

1. The evidence package returns a JSON object with base evidence, benchmark comparison (pass/fail per tag), scenario results, and bottleneck analysis.

Illustrative output

{
  "base_evidence": {
    "Suction_Pressure": {"model": 71.8, "field": 72.3, "deviation_pct": 0.7},
    "Discharge_Temperature": {"model": 142.1, "field": 148.5, "deviation_pct": 4.3},
    "Power": {"model": 8400, "field": 8750, "deviation_pct": 4.0}
  },
  "benchmark_result": "PASS (all deviations within 5% tolerance)",
  "scenarios": {
    "Increase throughput 10%": {
      "Power": {"before": 8400, "after": 9520, "change_pct": 13.3},
      "driver_margin_pct": 3.2,
      "surge_margin_pct": 12.1
    },
    "Reduce suction pressure 3 bar": {
      "Power": {"before": 8400, "after": 9100, "change_pct": 8.3},
      "driver_margin_pct": 7.5,
      "surge_margin_pct": 6.8
    }
  },
  "bottleneck": "Driver power margin is the binding constraint for throughput increase."
}

This evidence package is produced weekly with no manual data gathering. The process engineer reviews the deviations and scenario trade-offs. If a deviation exceeds tolerance, the workflow escalates to a calibration study. If a scenario shows a constraint approaching its limit, the workflow escalates to the relevant specialist.

The key insight is that the OperationalEvidencePackage class encapsulates the integration pattern that was described conceptually in Chapter 4 and Chapter 7. Tag mapping, field-data application, model execution, benchmark comparison, scenario analysis, and bottleneck identification are all performed in a single orchestrated call. The agent coordinates the data retrieval; the Java class performs the evidence assembly; the engineer reviews the result.

9.14 Dynamic Simulation Thread: Startup and Depressurization

The steady-state threads above identified hydrate margin during cold restart as a potential constraint. A steady-state model cannot evaluate this risk fully because the controlling case is time-dependent: the pipeline starts at ambient temperature, warms gradually as production resumes, and may pass through the hydrate region during the ramp-up window.

This is where dynamic simulation enters the worked case pattern. The agent extends the field model into a transient study by following the workflow described in Section 5.6 and Section 7.15:

1. Initialize from steady-state. The base-case field model runs to convergence at the pre-restart conditions (pipeline cold, wellhead pressure available, flow rate zero).

1. Define the startup sequence. The scenario specifies: choke valve opens gradually over 30 minutes, separator level controller active, compressor starts when suction pressure reaches setpoint, inhibitor injection active from time zero.

1. Run the transient. The model steps through time using runTransient(dt), recording pipeline temperature profile, separator level, compressor suction conditions, and hydrate margin at each step.

1. Evaluate the response. The agent checks whether temperature anywhere in the pipeline drops below the hydrate formation temperature at the local pressure during the ramp-up window. It also checks whether separator level exceeds high-alarm during the initial liquid surge.

1. Report. The output includes a time-domain temperature-vs-hydrate plot, the minimum margin and when it occurs, and a pass/fail assessment.

The illustrative result shows that hydrate margin drops to 1.5 °C at minute 18 of the restart before recovering as warm fluid reaches the arrival point. This is below the 3 °C operating criterion, confirming that a startup procedure with pre-heating or increased inhibitor dosage is needed.

Similarly, a depressurization study for the tieback scenario uses dynamic simulation to predict minimum metal temperature during emergency blowdown. The model tracks pressure and temperature versus time in the HP separator, checks whether the metal temperature drops below the MDMT, and records the time to reach the target pressure for fire-case relief sizing.

These dynamic threads change the overall study conclusion. The steady-state screening showed the tieback as technically feasible at design conditions. The dynamic screening adds that operational procedures (startup, shutdown, depressurization) require specific design attention. This is a common pattern in real field studies: the facility has static capacity, but the dynamic operating envelope imposes additional constraints.

Production data as dynamic boundary conditions

The dynamic simulation becomes more valuable when it uses production data as boundary conditions. The latest well test provides the actual wellhead pressure, GOR, and water cut. If the reservoir has matured and wellhead pressure is lower than the design case, the startup transient may take longer and the minimum hydrate margin may be smaller. An agent that uses design-case well data instead of actual well test data will overestimate the available margin.

The pattern is: read the latest well test from the production database, update the wellstream source in the dynamic model, and re-run the startup transient. Compare the result against the design-case transient. If the actual-well-data case has tighter margins, flag it as a changed operating condition that may require a procedure update.

9.15 What the Agent Did and Did Not Do

The agentic workflow did:

• structure the task;
• retrieve and organize evidence;
• build or update modular NeqSim scenarios;
• run screening calculations;
• connect equipment and safety follow-up;
• produce traceable artifacts.

It did not:

• approve the tieback;
• replace discipline reviews;
• certify relief capacity;
• validate vendor data without specialist review;
• change operating procedures;
• bypass document or historian access controls.

This distinction is the heart of industrial agentic engineering. The agent makes the study faster and more complete. The organization remains responsible for decisions.

9.16 Reuse Pattern

The same worked pattern can be reused for brownfield debottlenecking, production optimization, emissions reduction, and maintenance planning. The details change, but the structure remains:

1. classify the decision and study level;
2. define evidence needs and approved sources;
3. build or select a modular process model;
4. run field-level scenarios;
5. launch equipment detail threads for bottlenecks;
6. launch safety and standards threads for affected barriers;
7. integrate results into a ranked recommendation;
8. store artifacts and reusable lessons.

The strongest workflows are those that make the next study easier. A completed tieback screen should leave behind improved tag maps, document retrieval queries, model states, validation cases, and checklist updates.

9.17 MCP Transcript Sketch

A real MCP transcript contains JSON-RPC messages and tool outputs. A book does not need to reproduce the entire transcript, but a study should preserve enough of the tool path to be auditable. A simplified transcript sketch for the worked case might look like this:

User: Screen tieback case with approved evidence and NeqSim tools.
Agent: Discovering relevant NeqSim MCP tools.
Tool: getCapabilities -> process simulation, flash, comparison, reporting.
Agent: Missing data: tieback composition, host operating window, compressor map.
Tool: document_retrieval -> source manifest entries for datasheets and curves.
Tool: tagreader_window -> selected 60-minute steady-state host window.
Tool: runProcess -> base case and tieback case.
Tool: compareProcesses -> bottleneck comparison table.
Tool: bridgeTaskWorkflow -> results.json draft.
Agent: Summarizing constraints, warnings, and required reviews.

The transcript shows three healthy behaviours. First, the agent discovers tools instead of assuming them. Second, it stops for missing data rather than inventing critical inputs. Third, it uses structured outputs for comparison and reporting.

For a formal study, the full transcript may be too verbose for the report, but the source manifest and results object should preserve the essential parts: tool name, input hash or file, output file, warnings, and version. This lets a reviewer reproduce the path without reading a long chat history.

9.18 Results Object Sketch

A structured results object is the handoff between calculation and reporting. The exact schema can vary, but the worked case needs fields like these:

{
	"study_level": "screening",
	"key_results": {
		"tieback_export_rate_relative_pct": 116.0,
		"compressor_driver_load_pct": 97.0,
		"minimum_hydrate_margin_C": 3.0,
		"separator_gas_load_pct_of_screening_limit": 91.0
	},
	"validation": {
		"base_case_compared_to_historian": true,
		"source_manifest_complete": true,
		"formal_design_approval": false
	},
	"warnings": [
		"Compressor map requires specialist review before design use.",
		"Cold restart hydrate case requires detailed flow assurance study.",
		"Relief and blowdown impacts are screening only."
	],
	"recommended_next_work": [
		"Compressor map and driver margin verification",
		"Cold-case hydrate and shutdown procedure study",
		"Relief, blowdown, and HAZOP update screening"
	]
}

The value of this object is not the illustrative numbers. It is the structure. The report generator can turn key_results into tables, validation into a review summary, and warnings into executive-summary caveats. Other agents can read the same object and continue the workflow. A safety agent does not need to parse a paragraph to learn that relief and blowdown require follow-up.

9.19 Risk Register Sketch

Even a screening study benefits from a simple risk register. It helps the team see which uncertainties matter most.

The risk register does not need false precision. It needs to connect technical uncertainty to next work. In this example, the top risks align with the recommended follow-up studies, which is exactly what a screening risk register should do.

9.20 Summary

This chapter has shown a complete pattern from field-level question to detailed equipment and safety follow-up. The example is fictional, but the workflow is intended to be directly reusable. The central message is that agentic engineering does not replace the engineering process. It connects data, models, tools, and review in a way that makes the process faster and more traceable.

Key additions in this chapter:

• Root cause analysis (Section 9.12) shows how OREDA failure data, historian time-series, STID design limits, and NeqSim simulation combine through the RootCauseAnalyzer to rank failure hypotheses for a compressor vibration event.
• Operational evidence packages (Section 9.13) demonstrate the weekly monitoring pattern where OperationalTagMap and OperationalEvidencePackage automate the data-to-model binding, benchmark comparison, and scenario analysis.
• Dynamic simulation (Section 9.14) adds time-dependent analysis for startup and depressurization, showing how production data changes the dynamic boundary conditions and why steady-state screening alone is insufficient.
• Together, these threads illustrate the defining pattern of agentic engineering: no single data source or tool could produce the result; value comes from the structured combination of documents, field data, production databases, and both steady-state and dynamic simulation.

Exercises

1. Scenario split: Apply the same pattern to a produced-water debottlenecking study and define the process areas.
2. Evidence gap: Identify what should happen if the compressor vendor map cannot be retrieved.
3. Safety escalation: Write the escalation statement for a tieback screen where hydrate margin is below the operating criterion.
4. Root cause analysis: A separator shows increasing liquid carryover to the gas outlet six weeks after a production increase. Design the RCA workflow: list the symptom type, at least four candidate hypotheses, the historian tags that would distinguish them, and the STID documents required.
5. Evidence package design: Define the tag bindings, benchmark tolerance, and two operational scenarios for a weekly heat-exchanger performance review using OperationalEvidencePackage.

This chapter uses references from the master bibliography.

Learning Objectives

After reading this chapter, the reader will be able to:

1. Reuse practical prompts, checklists, and report patterns for MCP-backed NeqSim studies.
2. Select evidence sources, model boundaries, and review gates for common study types.
3. Translate the common workflow into discipline-specific playbooks.
4. Maintain a local library of skills and workflows while protecting confidential data.

Beyond the online book: The online book explains the task-solving workflow and results schema. This final chapter turns the book into practice: reusable prompts, checklists, study templates, discipline patterns, and skill-maintenance rules.

10.1 Why Playbooks Matter

Agentic engineering becomes valuable when good practice is repeatable. A single successful chat session is useful, but it is fragile. A playbook is stronger. It defines the prompt pattern, source requirements, model steps, validation gates, outputs, and review expectations.

Playbooks should be short enough to use and precise enough to govern. They prevent common failure modes: missing source data, wrong units, unsupported assumptions, unreviewed safety claims, overconfident recommendations, and lost artifacts.

The playbooks in this chapter are templates. Teams should adapt them to local requirements, access controls, discipline standards, and professional ownership.

10.2 MCP and Agent Setup Checklist

Use this checklist before asking an LLM to call NeqSim through MCP.

Do not start with confidential facility data. Start with a public example, prove the tool path, then move to governed internal workflows.

10.3 Prompt Patterns

Good prompts define the role, tool boundary, evidence expectation, and output.

Tool-backed calculation

Use NeqSim MCP tools for the calculation. Do not estimate the engineering result
from memory. Before calling the tool, state the required inputs and assumptions.
After the tool call, report model, units, convergence status, warnings,
limitations, and whether the result is screening or design-level.

Missing-data stop rule

If a required input is missing, stop and list the missing input, why it matters,
and approved sources where it could be retrieved. Do not invent default values
unless I explicitly ask for a hypothetical example.

Source-aware document extraction

Read the provided technical documents and extract only values relevant to the
study. For every value, return source file, page or sheet, unit, confidence,
and review status. Mark OCR-derived or ambiguous values as needs_review.

Safety boundary

Treat the safety result as a screening. Identify affected HAZOP nodes, relief
cases, blowdown/MDMT concerns, and barriers. Do not state that a safety case is
approved. List required discipline reviews.

These prompts can become skills or command templates. The aim is to make good behaviour the default.

10.4 Source Manifest Checklist

Every standard or comprehensive study should have a source manifest. At minimum, record:

• source identifier;
• source type;
• repository or system;
• title or description;
• revision or timestamp;
• retrieval time;
• access basis;
• extracted values with units;
• confidence and review status;
• limitations or open questions.

For historian windows, also record tag names, units, start and end time, aggregation method, number of points, bad-quality percentage, steady-state criterion, and rejected periods. For enterprise context, record equipment identity, record type, date range, summarized finding, privacy restrictions, and whether the data is evidence, context, or action constraint.

The manifest should be stored with the task, not only described in chat.

10.5 NeqSim Model Setup Checklist

Use this checklist when building or reviewing a model.

Many model errors are not deep thermodynamic failures. They are missing mixing rules, unit confusion, stale composition, or untracked scenario changes.

10.6 Study-Type Playbooks

Each playbook should state whether the output is a quick screening, a standard study, or a formal deliverable.

10.7 Report and Review Pattern

A concise PaperLab-style report can use this structure:

1. Executive summary: decision question, answer, confidence, and next action.
2. Scope: included boundary, excluded items, study level, and acceptance criteria.
3. Sources: source manifest summary and data-quality notes.
4. Model: NeqSim model, EOS, process areas, scenarios, and validation basis.
5. Results: key tables and figures with units.
6. Discussion: physical mechanisms, uncertainty, and operational implications.
7. Safety and standards: affected standards, barriers, and escalation needs.
8. Recommendation: action, limitations, and required reviews.
9. Appendices: detailed source manifest, tag windows, tool calls, and model state.

Before releasing an agent-prepared study, ask whether the decision question is clear, inputs are sourced and unit-checked, NeqSim tools performed the calculation, warnings are visible, uncertainty is proportionate, safety implications are identified, the recommendation matches the study level, and the result can be reproduced from stored artifacts.

10.8 Discipline Pattern

Every discipline playbook should contain the same minimum elements.

This common structure prevents disciplines from building isolated habits. A production question can become a flow assurance question. A valve question can become a relief, noise, or surge question. A chemical-treatment question can become a materials or environmental question.

10.9 Discipline Matrix

A local implementation should adapt names and review gates to the organization. The important point is the route from question to evidence to tool to review.

10.10 Discipline Notes and Red Lines

Process and production. The agent should expose assumptions, scenario boundaries, active constraints, and trade-offs. Production scenarios should keep reservoir assumptions separate from facility calculations and should not hide flow assurance or compressor constraints behind a production target.

Automation and control. The strongest use cases are read-heavy and diagnostic: trend review, loop diagnosis, alarm support, startup/shutdown evidence, and tag mapping. Changes to set points, trips, alarm limits, or control logic remain governed engineering work.

Valves and piping. NeqSim can support pressure drop, phase behaviour, flow regime, thermal profiles, surge screening, and scenario loads. Final pipe class, wall thickness, flange rating, support design, valve trim selection, actuator sizing, noise assessment, and formal code compliance require discipline approval.

Flow assurance and chemicals. Hydrate, wax, asphaltene, corrosion, scale, inhibitor, and separation-chemistry workflows should tie recommendations to water rate, phase behaviour, temperature profile, injection point, chemical availability, environmental classification, and uncertainty. Chemicals are not a simple tuning knob.

Materials and integrity. The agent should retrieve material specifications, line classes, inspection records, corrosion monitoring, wall-thickness measurements, and relevant standards. A wrong material grade, line class, heat treatment, or inspection date can invalidate a screening.

Environmental and emissions. Process models can estimate stream quantities, power, flaring, venting, chemical use, and energy intensity. Formal reporting may require approved factors, allocation logic, measurement rules, and auditable records.

HSE and technical safety. The agent can prepare HAZOP node packages, LOPA/SIL tables, relief-property screens, blowdown/MDMT evidence, barrier packages, and MOC impact summaries. It should not approve a HAZOP, LOPA, SIL, relief design, safety case, or MOC; claim barrier independence without review; credit operator response without criteria; use stale documents for final conclusions; hide missing data behind assumptions; or present screening as design approval.

Operations and maintenance. The agent should say what is known, what is inferred, what should be checked, and what must be escalated. Root-cause outputs should arrive as evidence packages with ranked hypotheses, not as final diagnoses.

10.11 Building and Maintaining Skills

Discipline playbooks become more powerful when turned into maintained skills. A skill should define when it is triggered, what input is required, what sources are approved, what tools are allowed, how results are validated, what red lines apply, and who owns the review.

Start with a small number of high-value skills:

1. process debottlenecking;
2. production backpressure sensitivity;
3. flow assurance hydrate margin;
4. valve and piping operability;
5. chemicals and corrosion evidence;
6. emissions and energy-intensity;
7. technical safety screening;
8. operations troubleshooting.

Each skill should have at least one public or synthetic validation case. Update a skill when a workflow fails, a tool changes, a standard requirement is clarified, or a repeated review comment appears. A small library of maintained skills is better than a large library of stale ones.

10.12 Failure Modes and Recovery

Failure recovery should update skills or memory. If a team repeatedly sees pressure-basis confusion, add a pressure-basis check. If a document reader misreads scanned tables, improve the OCR review rule. Trust grows when the system learns visibly.

10.13 Success Measures

Discipline adoption should be measured with quality and speed metrics.

The aim is not to maximize the number of agent outputs. The aim is to improve quality, consistency, traceability, and timeliness.

10.14 Final Checklist

Before using an agentic workflow for a real engineering decision, confirm that:

1. the question is clear and bounded;
2. data sources are approved;
3. the tool boundary is explicit;
4. the NeqSim model and version are recorded;
5. units, warnings, and limitations are visible;
6. the study level is declared;
7. safety and standards implications are considered;
8. human review is assigned;
9. artifacts are stored;
10. reusable lessons are extracted without exposing confidential data.

When these statements are true, LLMs, MCP, NeqSim, and industrial data can work together as an engineering system rather than a novelty interface.

10.15 Summary

This final chapter turns the book into a practical operating manual. The common pattern is consistent across study types and disciplines: evidence first, governed tool calculation second, uncertainty and limitations visible, human review assigned, and reusable learning stored.

Process engineers need transparent flowsheet studies. Production engineers need facility-aware production scenarios. Automation engineers need tag-linked diagnostics. Valve and piping engineers need explicit operability and design handoffs. Flow assurance and chemicals engineers need thermal, hydraulic, and chemistry margins. Materials engineers need material-limit and degradation screening. Environmental engineers need auditable emissions and discharge estimates. HSE and technical safety engineers need conservative evidence packages and red lines. Operations and maintenance teams need fast diagnosis with clear escalation.

That is the central message of the book: agentic engineering is valuable when it turns calculation, data access, professional judgement, and review into one traceable workflow.

Exercises

1. Workflow index: Create a local workflow-library entry for one recurring study, including owner, inputs, outputs, and review need.
2. Prompt rewrite: Improve a vague prompt so it requires tool use, source provenance, warnings, and a study-level label.
3. Discipline handoff: Pick a production-rate increase and list the process, flow assurance, valve/piping, environmental, and technical-safety review points.

This chapter uses references from the master bibliography.