Connect AVEVA PI to OpenAI
You're building an OpenAI agent or Custom GPT that should be able to answer questions about plant operations — and the process data lives in AVEVA PI. The agent needs to query tag values, pull trend data, and surface process context on demand. The problem is that OpenAI's function calling and Custom GPT actions expect cloud-accessible REST endpoints, and AVEVA PI is an on-premise historian on a private OT network that was never designed to answer calls from an AI model running in OpenAI's cloud.
If you've already started and hit a wall, the list below is probably why. These barriers aren't obvious from the OpenAI documentation — they only show up when you have a real PI system on the other end.
Why it's hard
Seven reasons connecting an OpenAI agent to AVEVA PI is harder than writing a function definition.
OpenAI's function calls go to a cloud endpoint — not an OT protocol
When an OpenAI assistant or Custom GPT calls a function, OpenAI's infrastructure makes an outbound HTTP request to whatever URL you specified. It has no concept of OPC, PI SDK, or any OT historian protocol. The only way PI data can appear in that response is if you have a REST endpoint somewhere in the world that retrieves it. If the PI server is on a private OT network with no internet-facing API, that endpoint doesn't exist yet.
PI Web API exists on the OT network — OpenAI calls from the public internet
PI Web API is the closest thing AVEVA PI has to a REST interface. But it's installed on an on-premise server, accessible only from inside the OT network or through a VPN. OpenAI's function calls originate from OpenAI's cloud infrastructure — completely outside your network perimeter. Making PI Web API reachable from OpenAI requires exposing it to the internet, which most OT security policies explicitly prohibit.
Function schema quality directly affects agent behaviour
OpenAI models decide whether and how to call a function based on its name, description, and parameter schema. A poorly described function gets called at the wrong time, with the wrong parameters, or not at all. Functions that return raw PI data — cryptic tag names, numeric values without units, Unix timestamps — produce responses the model can't interpret well, which leads to hallucinated context or incorrect answers about process state.
Raw PI time-series data fills the context window
A function that returns all PI values for a time range can produce thousands of data points. Each data point in a function response consumes tokens. For long time ranges or many tags, the function response alone can consume most of the model's context window — crowding out the conversation, the system prompt, and the model's ability to reason about the data. The endpoint needs to return aggregated, summarised data, not raw historian dumps.
PI tag names are opaque — the agent needs readable context
PI tag names like "CDT158.PV" or "R-201.TIC-101.PV" are internal identifiers that encode equipment and control loop conventions known only to the engineering team. When a function returns a tag name alongside a numeric value, the model has no way to know what the value represents. Without descriptive names, units, and asset context, the agent can't give a meaningful answer — or worse, it confabulates one.
Custom GPT Actions require a public OpenAPI spec
If you're building a Custom GPT rather than an API-based assistant, the integration mechanism is Custom GPT Actions — which require an OpenAPI 3.x spec for an endpoint accessible from ChatGPT's servers. PI Web API has its own OpenAPI spec, but it's complex, not designed for LLM consumption, and exposes far more than you want a chatbot calling. You need a purpose-built, simplified API with a clean schema — not a raw PI interface.
Token costs scale with data volume — and PI generates a lot of data
Every function response that goes back into the model's context costs tokens. PI historians can generate enormous volumes of data — high-frequency samples across hundreds of tags. An agent that queries raw PI data for every user question can become expensive quickly. Without server-side aggregation that returns compact, well-structured summaries, token costs grow proportionally with the scope of each query.
What teams usually try
Three common approaches — and where each one runs into trouble.
Expose PI Web API directly as the function endpoint
Deploy PI Web API, open a network path from the public internet to it, then define OpenAI functions that call PI Web API endpoints directly. The agent queries PI in real time with each function call.
The catch: Exposing PI Web API to the internet is a security decision that most OT teams won't approve. The PI Web API response schema is complex and not designed for LLM consumption. Function responses will include raw compressed PI data that fills context windows. And every PI server upgrade risks breaking the function schema.
Build a custom middleware API
Write a custom REST service that connects to PI internally, transforms its responses into LLM-friendly JSON, and exposes a clean cloud-accessible API. Define OpenAI functions against this purpose-built layer.
The catch: You're now a middleware developer. The service needs hosting, authentication, monitoring, and ongoing maintenance. Every PI configuration change that affects the tags you're surfacing requires code changes. You've built a custom integration for one historian — every additional OT source is another project.
Upload PI data to a vector store and use file search
Export PI data periodically to files, upload them to an OpenAI vector store, and configure the assistant to use file search as its retrieval mechanism. Avoids any outbound HTTP call to the plant.
The catch: The agent answers questions about past snapshots, not current plant state. "What is the pressure on Reactor 2 right now?" becomes "What was it as of the last upload?" The export pipeline needs to run reliably on a schedule, and for large PI deployments with many tags and long histories, the files can be very large.
How TrendOps solves it
TrendOps Edge connects to AVEVA PI on the OT network and forwards normalised, context-rich data to TrendOps Platform in the cloud. Your OpenAI agent defines functions that call TrendOps Web API — a clean, purpose-built endpoint designed for AI consumption. No OT network access required, no raw PI schema to parse, no context-window flooding from bulk time-series dumps.
The agent's function calls go to TrendOps Web API — a cloud-accessible HTTPS endpoint. No reverse proxy, no DMZ, no internet-facing PI server. The OT network has no inbound connections in this path.
TrendOps resolves PI tag names and asset context before data reaches the function response. The model receives values with readable names, engineering units, and source context — not "CDT158.PV = 247.3".
TrendOps handles aggregation server-side. Time-series history comes back as compact, interval-based summaries — not thousands of raw PI samples. Function responses stay small and don't crowd the context window.
TrendOps Web API ships with an OpenAPI 3.x spec designed for AI agent consumption — not a raw PI Web API schema. Custom GPT Actions can import it directly without modification, and function names are descriptive enough for the model to call them correctly without extensive system prompt coaching.
TrendOps Edge polls AVEVA PI continuously and keeps TrendOps Platform current. Function calls return real-time process data — not a snapshot from a file upload that ran last night.
TrendOps Edge pushes data out over a single outbound MQTT connection. There are no inbound paths into the OT network. OpenAI's function calls never touch the plant network — they terminate at TrendOps Platform in the cloud.
TrendOps Web API works as function definitions in the OpenAI Assistants API and as Custom GPT Actions. The same endpoint, the same schema, the same API key — whether you're building a bespoke agent in code or configuring a Custom GPT in ChatGPT.
Because TrendOps normalises data across all connected sources, the same function definitions work whether the data comes from AVEVA PI, DeltaV, FactoryTalk, or SQL. The agent doesn't need separate functions for each historian — one set of tools covers the whole plant.
What you end up with
An OpenAI agent with real-time access to AVEVA PI data — calling a clean cloud API, not a raw OT historian.
The agent receives descriptive names and units — not opaque PI tag identifiers.
Current process values — the agent knows what's happening right now, not from a stale export.
OpenAI calls TrendOps cloud API — the OT network is never in the function call path.
One set of functions, every OT historian — the agent isn't limited to AVEVA PI.
Don't want to build your own AI agent integration?
TrendGuru — TrendOps's built-in AI agent — already has access to your plant data. Ask questions about your AVEVA PI historian in plain language and get answers instantly, deployed directly in Microsoft Teams. No function definitions to write, no OpenAPI spec to maintain, no token costs to manage.
Learn about TrendGuru →Your OpenAI agent shouldn't need to know what a PI tag name means
TrendOps gives your OpenAI agent a clean, cloud-accessible API for AVEVA PI data — with descriptive names, aggregated history, and no OT network in the call path.
Book a Demo