The previous parts of this chapter have looked inward: at the construction of an AI process, at the deterministic backbone, and at the question of where AI may decide and where better not. This article turns the perspective around and asks how users experience AI when it does not run alongside the application, but inside it.

An example from PLM daily life: design engineers have opened a part data record and ask in natural language: “Which change requests concern this part, and which is still open?” The answer does not appear in a separate chat window that they would then have to laboriously reconcile with the object they have open. It emerges in the application: the agent works in the context of precisely the data record that is currently open. It finds the linked requests, displays them in the user interface, checks their status, prepares the result, and explains the connection right where the work is happening anyway.
 

Access Is Not Integration

The fact that an agent can access an application via an interface is becoming increasingly a matter of course. Standards such as MCP make it easier to make tools, data, and functions of an application available to agents. That is important, but it is not yet product integration.

An external agent remains an external agent. It uses the application as a tool. The user interface, the interaction model, the runtime, the model choice, and the rules for its actions lie outside the product. The application can provide functions, but it does not really shape the agent.

The aspiration of the PROSTEP AI Workbench (PAW) and the associated language APL is a different one. The agent should not merely access the application. It should be capable of being designed as part of the application, with a matching user interface, controlled capabilities, described procedures, clear points for follow-up questions, permissions, logging, and model choice. This turns it from a mere user into a function of the software. The difference therefore does not lie in the fact that the agent can use an interface, but in who designs and constrains it.

The Agent as Part of the Application

An agent that runs alongside the application can do many of the things that a fully integrated agent would also do. With suitable interfaces, it determines the application context and the structure of the user interface, and uses this information to assist users. That, however, is where the commonalities end. Already at the question of data protection, a limit is reached for most external agents, because they have no permission to use local or company-specific models.

The more serious limitation, however, consists in the fact that the ability to control only runs in one direction, namely from the agent to the application. The other way around it becomes difficult – the application can only influence the agent to a very limited extent. And this fundamentally distinguishes the integrated agent from an external tool. An integrated agent can be configured more deeply; one can have interventions made into its internal procedures in order to produce a specific behavior, and get it to react directly to control commands from the surrounding software.

Depending on the application, this integration can also encompass speech input and output. Users can dictate a task instead of typing it into a form or chat window; the agent can ask follow-up questions or read out a result when that fits the working situation. Speech is not a separate gimmick here, but a further form of operating the same application, with the same context, the same permissions, and the same controlled capabilities.

For users, this means that they remain in their familiar user interface and formulate their concern in natural language rather than clicking in a graphical interface. The agent works in the system, so that no switching between tools and no manual transfer of results are required. Support sits where the work takes place. From the product team’s perspective, this means that the agent is designable. Its behavior, its user interface, its depth of intervention, and its boundaries are part of the product design. It is thereby more than a personal assistant for the users: it is a deliverable product function. Put pointedly, one can say that application and agent merge with one another.
 

Controlled Capabilities Instead of Free Tool Access

Such an agent does not become reliable, however, simply by being given a long list of tools: access to many tools does not yet make its actions reliable. If it decides for itself, freely, which tool from a list of several hundred it uses, when, how often, and in what order, the risk is high that it will often get it wrong. It is therefore important to make available to it as small, well-chosen a list of tools as possible, tailored to the specific task at hand. APL supports precisely this: equipping the agent situationally with selected tools, choosing the appropriate language model, and thereby letting it solve a dedicated, delimited task. If one then also uses APL’s ability to structure more demanding procedures as an AI procedure with algorithmic and cognitive parts, rather than letting an agent improvise freely, one obtains a requirement-appropriate scaling of AI integration – from free interaction with the agent all the way to fully structured APL procedures for complex, AI-heavy sub-tasks.

In the design engineers’ example, therefore, the agent does not have to improvise freely how it finds open change requests for a part. It can use a capability provided for this by the application: start from the opened part, search for linked change requests, check status, secure sources, summarize the result. The agent recognizes the user intent and selects the appropriate capability. The execution itself remains controlled.

This combines two modes of operation. The agent understands the open user intent and the context of the user interface, while APL ensures that the execution does not vanish into the model’s free-form run, but remains visible, bounded, and repeatable as a described procedure.

Adaptable in User Interface, Process, and Model

That the agent can work in this way is no coincidence, but part of the architecture, which allows adaptations at several levels:

• User interface and interaction: how the agent appears, whether it is operated via text, speech, or both, where it asks follow-up questions, how suggestions are presented, and which actions the users have to confirm.
• Application context: which data, objects, relationships, and functions the agent sees is determined by the application.
• Process: which APL procedures are available, which boundaries they have, and which results are only proposed rather than written directly is designable.
• Model: which language model drives the agent is a design decision, just as much as the question of whether it is deployed as a cloud model or as a locally operated model when data must not leave the company.

The last point is more than a technical detail. In many PLM and engineering environments, product data, design knowledge, and change information are highly sensitive. The architecture must therefore permit model choice, data flow, and execution to be adapted to one’s own requirements. Model choice thereby becomes part of the product and operations decision, and not a hidden default of the agent platform.
 

The Same Pattern Beyond PLM

The built-in agent is not a PLM special case. The same pattern carries in quite different applications. In a presentation generator, the agent does not merely produce text. It works on a designed artifact: slides, layouts, placeholders, finished views. It can generate a slide, view the result as an image, and recognize layout problems before the users see them. That is only possible because the agent sits inside the tool and can immediately judge its output.

In a diagramming tool, human and agent work on the same structured workspace. The human moves an element, the agent adds relationships, proposes a structure, or cleans up a depiction, and it does so on the same artifact and not decoupled alongside it. The agent works with the data, functions, and results of the application. And it links open user intent with the controlled capabilities of the product. Product integration is the common denominator.

 

The Question of Reliability

The agent in the user interface is thus not simply a chat with access to application tools, but a designed product function. It is visible in the look and feel of the application, tied to its context, bounded by its rules, and equipped with controlled process capabilities. Humans formulate what is to be achieved. The agent understands the application context and selects the appropriate capability. APL ensures that the execution remains visible, bounded, and repeatable. Today we still speak of an agent that is integrated into an application. The development goes further, however: the more fully AI capabilities merge with the functions of the product, the less remains of an agent that can be delimited. At the end, the application itself is a