Building Ignition 8.3 UDTs With an AI Agent: Import Is Only the First Test

I tested an AI-driven UDT workflow against an Ignition 8.3.8 Gateway. Several deliberately bad payloads crossed the import boundary even though the resulting resources were incomplete or unhealthy.

An instance without a typeId persisted without its intended type. An invalid valueSource was accepted and later reported Error_Configuration. Invalid expression syntax imported and then failed at runtime. An invalid alarm mode stayed inactive. Duplicate sibling names collapsed. Some failed operations still returned HTTP 200.

Those results come from one bounded test environment. They show why an agent should inspect the saved and running state instead of treating a status code as proof.

Start with the authenticated OpenAPI document and the Gateway state. Confirm the tag provider, destination path, parent UDT, existing definitions, and the smallest root the agent is allowed to change.

Capture the current resources before writing. Choose the collision policy deliberately. An overwrite, merge, abort, or rename decision changes the result and should never be left to an agent's guess.

Local checks are faster and clearer than debugging a partially imported resource. Validate required names, data types, value sources, typeId paths, expression syntax, alarm modes, duplicate siblings, parameter references, and nested member paths.

Keep the payload small enough to review. A compact definition and one representative instance reveal more than a large generated hierarchy that no one can inspect.

An HTTP 200 response can still contain a rejected action, partial result, warning, or resource-level failure. The agent should parse the operation result and stop if any member is unresolved.

A dry run is useful when the endpoint supports it, but dry-run success still needs post-write verification after the approved mutation.

Compare the requested structure with the Gateway's saved structure. Check names, typeId values, parameters, nested members, overrides, bindings, alarms, and collision outcomes.

This should be a semantic comparison. Property ordering or defaults may change during serialization, while a missing type or altered member is material.

If a behavior cannot be exercised safely, label it unproven. That is more useful than a clean summary built on missing evidence.

The engineer still defines the equipment model, inheritance rules, parameters, alarm philosophy, naming conventions, and operational acceptance criteria. The agent is useful when it follows that approved model and returns evidence for review.