Custom agents, inside the same guardrails

What defining one involves

Four things, and nothing that resembles writing code.

• A trigger — a schedule, or a state-transition subscription, using the same event model the built-in agents use.
• A scope — which object types, and which subset of them. A custom agent looking at castings should not be reading firmware items, and narrowing the scope is the single biggest lever on both cost and finding quality.
• A prompt — what to look for, expressed in your own words and your own vocabulary. This is where the domain knowledge lives, and it is the part nobody outside your organisation could write on your behalf.
• A tier — Observe or Recommend. Prepare and Execute are not available to custom agents, for reasons set out below.

What it inherits, and why that is the product

A custom agent is not a script with access to your data. It runs inside exactly the same envelope as the agents Manufacturing PLM ships, and the envelope is what you are actually buying.

Permissions are enforced at the data layer, so a custom agent sees what its configured identity may see and nothing beyond it. There is no configuration in which one reads across a tenant boundary or into a restricted programme it was not granted access to.

Citations are required, not encouraged. A finding without a citation to a specific object and field is not surfaced at all, which is what stops a custom agent from becoming a source of confident, unattributable claims that nobody can check.

Metering and budgets apply, so a badly scoped custom agent shows up as a cost line rather than as a surprise at the end of a month. And the audit trail records every run — its trigger, its scope and its findings, including the runs that found nothing, which is how you tell an agent that is working from one that is quietly broken.

The failure it prevents

A company builds an integration that reads its PLM data through an API key, runs a check somebody wrote in Python, and emails the results to a distribution list. It works. It runs for two years.

Then it starts producing findings that are subtly wrong, because a field's meaning changed and the script did not. Nobody notices for a quarter, because the emails look exactly as they always did and nobody can see what the script actually queried.

The problem is not the script — it is that the script is outside everything. No permission model, no citation requirement, no audit record, no metering, and an API key that outlives the person who created it. Custom agents exist so that the entirely reasonable desire to encode your own check does not require stepping outside the system to satisfy it.

How it meets the rest of the product

Findings enter the same work queue as everything else, with the same routing and the same lifecycle. A custom agent's task is indistinguishable in handling from a built-in agent's task, which is what stops custom agents from becoming a second channel that people gradually learn to ignore.

The orchestrator schedules them under the same fairness rules, so a custom agent cannot starve a built-in one, and a badly written one degrades its own throughput rather than everybody's.

Evaluations are testable before they are enabled. A custom agent can be run against a sample scope with its findings displayed and nothing written, which is the only responsible way to discover that a prompt returns four hundred findings on its first day.

Versioning applies to the definition itself. Changing a custom agent's prompt is a recorded change with an actor and a date, so a shift in what an agent reports can be traced to the moment somebody rewrote its instructions rather than being blamed on the model.

How it meets your ERP

Custom agents can read cached ERP values within their scope, and that is where a large share of them end up pointed. The checks companies want most are frequently cross-system: items released here but absent there, cost fields that moved by more than a threshold, structures whose last publication is older than their last revision.

Those checks are specific to how a company has divided its system-of-record matrix, which is exactly why they cannot be shipped built-in. The matrix is decided per tenant, so the useful checks over it are per tenant too.

A custom agent cannot write to your ERP under any configuration. The connector is the only write path, and it requires an attributed actor and a change record that an agent evaluation does not produce.

Where the boundary is

Custom agents are limited to Observe and Recommend. They can report and they can propose; they cannot prepare drafts or execute actions. Those tiers involve writes, and a write path defined by a prompt is not something anybody should ship.

There is also no arbitrary code execution and no outbound network access from an evaluation. A custom agent reads Manufacturing PLM data within its scope and produces findings. Anything needing computation or an external call belongs in the connector SDK, which has the isolation for it.