When Should Product Engineering Use AI Agents?

When should product engineering use AI agents?

Product engineering should use AI agents when a workflow requires interpretation, ambiguity handling or context-dependent judgment. It should use deterministic software when rules are known, outputs must be repeatable and traceability is essential.

The most reliable architecture combines both:

• governed systems provide authoritative engineering data;
• tested functions perform calculations, validations and rule-based decisions;
• explicit workflow state records what has happened and what comes next;
• documented interfaces expose data and actions;
• an agent selects and orchestrates those capabilities where judgment is genuinely required;
• a person remains responsible where engineering risk demands human authority.

This boundary matters because an agent is software. It cannot reliably replace the undocumented knowledge, manual coordination and informal exceptions that experienced engineers use to hold a fragmented process together.

What is the common misconception about AI agents?

The common misconception is that an agent can be inserted wherever a person currently performs work and then imitate the entire human role.

On a process diagram, the work may look structured: retrieve information, apply a rule, enter a value, notify the next person and make a decision. In reality, the engineer may also know:

• which of several files is authoritative;
• that one spreadsheet field has a different meaning for a particular product;
• which design rule changed after a past failure;
• which exception was agreed but never documented;
• whom to ask when two systems contradict each other.

The documented process shows the visible steps. The human supplies missing context, process state, integration and exception handling.

When an agent is placed on top of this environment, it is asked to infer what the organization itself has not made explicit. The agent may produce a convincing prototype because experts prepare inputs and correct mistakes. It becomes brittle when exposed to everyday variation.

The problem is not simply that the agent needs a longer prompt or more rules. The workflow was designed for people to complete it.

What should AI agents do?

Agents are valuable where the correct action cannot be reduced to stable rules alone.

Good candidates include:

Interpret natural language

An agent can classify a supplier response, extract intent from an engineering change description or turn an informal request into a structured starting point.

Understand unstructured information

An agent can identify relevant passages across reports, requirements or lessons learned when meaning depends on context rather than exact keywords.

Select among available capabilities

An agent can decide which approved analysis, search, calculation or workflow action to invoke when that choice depends on the situation.

Support context-dependent judgment

An agent can assemble evidence, compare alternatives and explain uncertainty to help an engineer make a decision.

Coordinate work with variable paths

An agent can orchestrate dependable functions when the sequence depends on information discovered during the workflow.

In each case, the agent works over trusted building blocks. It does not invent authoritative data, reproduce a validated calculation from prose or silently decide which product revision is correct.

What should remain deterministic software?

Known business logic should be implemented explicitly when the same input should produce the same result.

Examples include:

• unit conversions and engineering calculations;
• geometry, material or tolerance checks with defined rules;
• product configuration validation;
• access-control decisions;
• lifecycle-state transitions;
• required-field and completeness checks;
• traceability and audit recording;
• fixed routing rules;
• safety or regulatory constraints that must be enforced consistently.

These capabilities should be tested, versioned and exposed through dependable interfaces. An agent may decide when to call them or explain their result, but it should not reconstruct them from documents each time.

This produces a durable principle:

Agents should handle ambiguity. Software functions should enforce deterministic business logic.

If the whole process follows stable if-then rules, an agent may add cost, latency and uncertainty without adding value. Conventional automation is the better choice.

Why do document-based agent workflows become brittle?

Documents are useful for human communication. They are weak substitutes for executable rules, explicit process state and governed data.

Asking an agent to read a technical note and reproduce a calculation creates several uncertainties:

• whether the agent found the current document;
• whether the rule applies to this product and revision;
• whether an exception exists elsewhere;
• whether the calculation was interpreted consistently;
• whether the same input will produce the same output tomorrow;
• whether the result can be traced and validated.

Adding more instructions may improve common cases while making the system harder to understand and maintain. The prompt gradually becomes an informal software system without the testing, typing, interfaces and controls expected of conventional software.

Documents should provide context where interpretation is necessary. They should not remain the only implementation of rules that require repeatability.

What are the building blocks of an AI-ready process?

A dependable agentic workflow requires five foundations.

Building block	Human-centered process	AI-ready process
Reliable data	People decide which file or spreadsheet to trust	Governed systems provide authoritative, contextualized data
Accessible functions	Employees search, copy values or ask colleagues	Documented interfaces expose calculations, simulations, tests and actions
Explicit business logic	Rules live in formulas, documents and experience	Tested functions produce consistent, repeatable results
Process coordination	People notify each other and start the next step	Events and workflow services trigger the appropriate action
Explicit process state	Experienced employees know what happened and what comes next	Status, ownership, exceptions and next actions are represented for software

These building blocks do not need to be created as one large platform program. They can be developed around a valuable workflow and designed for reuse.

The agent then becomes a relatively thin reasoning and orchestration layer. Reliability comes mainly from what sits beneath it.

How should an agentic engineering workflow be designed?

Start with the decision and the operating outcome, not the agent.

1. Map the real workflow

Observe how work is completed, including spreadsheet steps, corrections, phone calls and undocumented exceptions. The official process map is rarely enough.

2. Separate deterministic work from judgment

For every step, ask whether stable inputs and rules should always produce the same result. If yes, implement that logic as conventional software. If no, define the ambiguity the agent or engineer must resolve.

3. Establish authoritative context

Identify the product, configuration, revision, units, lifecycle state and source required to interpret each input correctly.

4. Expose capabilities through interfaces

Provide dependable ways to retrieve data, run calculations, perform validations and update systems. Avoid making the agent operate through document copies when a governed service can exist.

5. Make state and exceptions explicit

Represent what has happened, which outputs were produced, who owns the next action and when human review is required.

6. Define the agent’s authority

Specify what it may read, recommend, invoke or change. Higher-risk engineering decisions require stronger validation and human control.

7. Test the complete workflow

Evaluate not only response quality but repeatability, traceability, failure handling, access control, operational ownership and performance under real product variation.

This method may reveal that only a small part of the workflow needs an agent. That is a successful design outcome, not a failure of AI ambition.

What is a practical decision model?

Use three questions for each workflow step:

1. Are the rules known and stable?
2. Must the same input produce the same output?
3. Does the task require interpretation or context-dependent judgment?

The answers suggest the appropriate mechanism:

Conditions	Preferred mechanism
Rules are known; repeatability is required; little interpretation	Deterministic software or workflow automation
Rules are known; context must be interpreted to select a rule or capability	Agent orchestrating tested functions
Information is ambiguous; alternatives require engineering judgment	Agent-assisted human decision
Rules and ownership are unknown; data sources conflict	Redesign and clarify the process before automating

The final row is the one most often overlooked. An agent should not be used to conceal a process the organization does not understand.

What are warning signs that agents are compensating for weak foundations?

An initiative is at risk when:

• everything in the architecture is described as an agent;
• agents pass state through shared documents or free-form messages;
• prompts contain growing lists of deterministic rules and exceptions;
• experts must repeatedly correct outputs that should be predictable;
• the agent chooses among conflicting sources without governed authority;
• system integration is simulated through copying and pasting;
• a vendor owns the workflow logic and no internal team can maintain it;
• users cannot explain why an output was produced;
• failure is attributed to model intelligence before the workflow is examined.

Several warning signs together indicate an AI investment–impact gap: AI is being layered onto a human-centered operating model rather than supported by reusable digital capability.

The AI Initiative Impact Gap Diagnostic provides the complete concise checklist.

What are the implications for engineering and IT?

Reliable agentic AI requires a new collaboration model.

Engineering must own the domain problem, workflow meaning, deterministic rules, acceptance criteria and operational outcome. IT must provide secure platforms, integration patterns, identity, interfaces, observability and software engineering guardrails. Cross-functional teams need enough software and data capability close to the engineering domain to turn knowledge into maintained digital assets.

Buying an agent platform does not remove these responsibilities. It makes them more important because software creation and orchestration become easier while lifecycle ownership, quality and integration remain organizational concerns.

The goal is not maximum agent autonomy. It is dependable engineering performance with the appropriate combination of human judgment, AI reasoning and deterministic software.

Frequently asked questions

Are AI agents suitable for engineering calculations?

They can select, parameterize or explain a validated calculation, but known calculation logic should usually run in tested deterministic software. The agent should not recreate a safety-critical or repeatable calculation from prose.

Can retrieval-augmented generation make documents reliable enough?

Retrieval can improve access to relevant context, but it does not turn documents into governed process state or executable business logic. Authority, applicability, revision and traceability still need explicit treatment.

Should agents be allowed to update engineering systems?

Only within clearly defined authority, validation and audit controls. The acceptable level depends on the reversibility and engineering risk of the action. Recommendations and reversible low-risk actions can permit more autonomy than lifecycle approvals or safety-related changes.

Does every AI-ready workflow require APIs?

Software needs dependable interfaces, but the exact implementation can vary. APIs, event streams, workflow services and governed data products are common mechanisms. The principle is repeatable, documented access—not a specific technology.

How can a team start without modernizing every system?

Choose one valuable workflow. Expose the minimum authoritative data and deterministic functions it needs, assign lasting ownership and design those capabilities for reuse. Expand incrementally as additional workflows consume the same foundations.

Related concepts

Agent reliability depends on connected engineering data, a clear operating model between IT and engineering and the broader capabilities of an AI-ready product engineering organization.

References

1. Kevin Pilch, AI Initiative Impact Gap Diagnostic, Version 1.0, July 2026.
2. Kevin Pilch, The AI-Ready Product Engineering Organization, Version 1.3, June 2026.