Give AI Agents Business Actions, Not System Commands

An AI agent’s real authority is not defined by what its prompt tells it to avoid.

It is defined by the actions available to it. Those actions determine how much authority the agent really has.

Give an agent actions such as “get item,” “update field,” “add relationship,” or “start workflow,” and the organization has effectively asked AI to reconstruct a PLM process.

The agent must work out which record to use, which revision applies, which sequence to follow, what may be changed, and what should happen when information is missing.

That is too much process responsibility to place inside the AI.

Give the same agent actions, such as “find approved equivalent parts,” “prepare a draft part request,” or “submit the request to the part steward,” and the boundary is different.

The agent chooses from approved business actions. The actions enforce the rules. Aras Innovator® governs the lifecycle process. A responsible human being still makes the product decision.

It is not a question of whether an agent can use tools. The question is whether those tools clearly express the trusted business action.

Small operational tasks deserve another look

Many engineering organizations have a category of manual work that was never automated.

The tasks are not particularly difficult. They were simply too small, variable, or distributed across systems to justify a conventional integration project.

An engineer searches for an existing part. Someone checks whether a supplier part has already been approved. Product information is copied from an email into a request form. A colleague identifies the relevant program. The completed request is sent to a part steward for review.

The process works because experienced employees know where to look and which information matters. They understand which shortcuts are acceptable, which actions require approval, and, just as importantly, when a case is too ambiguous to continue.

AI agents can change the economics of this work. They can interpret a request, gather information from multiple systems, identify what is missing, and hand a case off to the next person responsible.

But giving an agent broad system access does not recreate the judgment of an experienced employee.

It creates a new source of operational risk.

A new part request shows the difference

Consider an engineer working on a fictional development program. We will call it “Program Atlas.”

The engineer receives a supplier specification and prompts the agent:

We would like to use supplier part SP-1847 in Program Atlas. Check whether we already have an approved equivalent. If not, prepare a new part request and send it to the appropriate part steward.

The agent should not be given generic permission to search every part, create any object, update any relationship, or start any workflow.

Instead, it should be given five recognizable business actions:

1. Confirm the supplier part. Verify the supplier identity, part number, source document, and intended application.
2. Find approved equivalents. Search for internal parts that meet the stated classification, program, and application criteria.
3. Check existing requests. Determine whether the same supplier part or an equivalent request is already under review.
4. Prepare a draft part request. Populate the required information, attach the supplier evidence, and identify missing fields.
5. Submit the draft to the part steward. Route the complete request into the established review process.

These actions allow the agent to remove searching, copying, and coordination work without transferring product authority to the AI.

The agent cannot create a released part, approve a supplier, add the part to a released BOM, confirm technical equivalence, promote an object to an approved lifecycle state, or override the established part-governance process.

Those boundaries matter. The part steward or responsible engineer still decides whether an existing part is genuinely equivalent, whether a new part should be created, and whether it is acceptable for the intended product context.

That is how action design becomes an autonomy boundary.

The agent chooses; the business action enforces

The responsibilities should be clear.

The agent chooses

The agent interprets the employee’s request and selects the relevant approved action.

It may decide that it first needs to confirm the supplier part, then search for equivalents, and finally prepare a draft request.

The business action enforces

Each agent action checks the rules before taking action.

For example, “prepare a draft part request” could verify that the requesting employee has access to the program, the supplier document has been attached, the intended use has been described, and all mandatory product information is present.

The action can also check whether a confirmed equivalent has already been found or a duplicate request is in progress. It can restrict the new request to a draft state and make sure a part steward has been identified before the process moves forward.

The employee does not have to instruct the agent to perform each check.
The controls are built into the expected action.

Aras Innovator governs

Once the draft is created, Aras Innovator manages the product context, permissions, relationships, lifecycle state, review workflow, and traceable record.

The human decides

The part steward or engineer evaluates technical equivalence, product suitability, supplier acceptability, and the need for a new internal part.

The agent moves approved work forward. It does not take ownership of the product decision.

How InnovatorEdge AI and MCP fit together

Edge AI provides the governed layer between Aras Innovator and AI agents. It turns approved Innovator objects and processes into discoverable, callable tools while managing authentication, connection profiles, permissions, and the audit trail needed to understand how those tools are used.

The Model Context Protocol (MCP) provides the transport that makes those tools visible and invokable by MCP-aware agent hosts. The distinction is important: Edge AI defines and governs the tools and business actions available to an agent; MCP provides a standard way for agents to discover and call them.

MCP is an open specification that can be implemented by many systems. Edge AI is Aras’ governed implementation for applying that model to product lifecycle data and processes, helping organizations make approved business actions available to AI agents without bypassing the controls already established in Aras Innovator.

With this approach, Edge AI can present approved business actions to an agent through MCP while Aras Innovator continues to enforce the underlying access controls, permissions, and process rules. The agent gets a defined set of actions it can invoke, rather than unrestricted access to system-level commands.

Start with work that is frequent, bounded, and reviewable

The strongest starting points are usually processes that happen often enough to create recurring friction and cross two or more systems, but require limited expert judgment.

They should also have a natural stopping point. Ideally, the agent produces a draft, recommendation, or prepared case for a clearly identified reviewer. The process should leave a traceable record and be able to stop safely when information is incomplete or the situation becomes ambiguous.

A practical way to get started is to use this checklist:

1. Identify small operational tasks that employees have stopped trying to automate.
2. Select one recurring process with a clear owner and limited downside.
3. Define the few business actions needed to complete it.
4. State explicitly what each action may and may not do.
5. Build validation, evidence, and stop conditions into the actions.
6. Require a human decision before any change to the governed product definition.
7. Measure whether the process removes handoffs without creating additional review or correction work.

The agent interprets the request.

The business action enforces the rules.

Aras Innovator governs the product lifecycle.

And the responsible person remains accountable for the decision.

These distinctions matter because the objective is not to give AI broad access to PLM.
It is to give an agent a precisely bounded ability to move approved work forward.