When people interact with AI capabilities in a product, chat is only one surface option, and it’s not always the right choice. Let’s explore other options.

Chat is often the most common way for a user to interact with an AI system. The user specifies a prompt, hits enter, waits for a response and then interprets that response. This pattern works well for open-ended questions because the conversation gives the user room to refine the request as new information appears.

With that said, this same pattern can introduce unnecessary friction when AI supports a task that already takes place inside an application.

For instance, a support engineer reviewing a customer support case about a billing issue should not have to tell a separate assistant which record is open, then copy its response back into the case. The application should already know the record and the action the engineer is trying to complete.

AI user experience (AI UX) describes how people interact with AI capabilities within a product. Chat is one possible surface, but AI can also appear inside an existing workflow or operate behind it.

In this article, we’ll look at embedded AI and contextual assistance, along with how AI can automate parts of a workflow. We’ll also consider adaptive interfaces and experiences in which the AI remains largely out of view.

Where Chat Fits

Chat works well for tasks that begin with a question and develop through conversation. A support engineer investigating an unfamiliar issue may need to ask follow-up questions or compare possible causes before deciding what to do. A transcript gives that exploration a natural place to unfold.

Chat becomes less useful when it is the default surface for every AI feature. With only a blank text box, the user has to figure out what the system can do and how to ask for it. They may also need to supply information that the application already has, then decide where the generated answer belongs.

These costs are easy to overlook in a prototype because a conversational demo can handle many requests without much interface work.

In a production application, however, the goal is not simply to give the user access to an AI model. We need to help the user complete a task with less effort and a clear understanding of what the application changed.

Bringing AI Into the Workflow

Embedded AI places an AI capability inside the feature where the work already happens. Instead of opening a general assistant, a support engineer might select a “summarize case” CTA beside the case history. The application supplies the current record to the model and places the result in a summary field that the engineer can review.

Contextual assistance goes a step further by drawing on the state around the interaction. The application may know which customer the engineer is helping and which part of the case is selected. It can also apply the engineer’s permissions before choosing what information to send. This context saves the user from having to describe the same setup in a prompt.

The interface still needs to show what the AI produced and where the result will go. Users should be able to edit a draft before saving it, and an action that changes a record should make that change clear. Embedding AI should reduce interaction work without hiding a consequential outcome.

The Progress Telerik and Kendo UI AI components reflect this range of possible surfaces. Going inline, a component like the React Inline AI Prompt can place assistance beside the content a user is editing, while the React SmartPaste Button can turn unstructured clipboard text into fields within an existing form. Neither experience requires a separate conversation to become useful.

Moving from Answers to Workflow Progress

Some tasks need more than a generated answer. Workflow automation becomes useful when AI must move work through a sequence toward a defined outcome. In the support example, the application could classify the issue and retrieve the relevant policy and could then draft a response and route the case for approval.

This automation does not need to be an agent when the steps are known in advance. Normal application code can coordinate the sequence and call the model only for the parts that need language understanding or generation. Agent behavior becomes useful when an intermediate result determines which tool or information source should come next.

Adaptive Interfaces

An adaptive interface changes the assistance or information it emphasizes based on the current situation. In a support application, the case view might surface an escalation action when the response deadline is close. A lower-risk case could instead show a suggested reply beside the response editor.

Adaptation can make a dense business application easier to use because the interface prioritizes what matters for the current task. It can also make the product difficult to learn if navigation moves unexpectedly or familiar controls disappear. The stable parts of the application should remain recognizable even when AI changes the recommendations around them.

The interface also has to account for incorrect predictions. It should identify an adaptive suggestion as a recommendation and let the user dismiss or correct it. Those corrections can become evaluation data without forcing the interface to reorganize itself around every model output.

When AI Can Remain in the Background

With an invisible AI experience, AI works without asking the user to start a conversation. A support system might classify an incoming case and route it to the right queue before an engineer opens it. The user gets a better starting point without having a visible exchange with a model.

This approach works when direct interaction would add unnecessary friction. Search can use semantic matching behind an ordinary search box, and a form can suggest structured values from pasted text. The interface can remain familiar while AI improves the behavior underneath it.

Keeping the model out of view doesn’t remove the need for accountability. A user should be able to correct a classification that affects their work, while consequential actions still need an appropriate review step. The team also needs evaluations and production traces so it can find failures that users may never recognize as model errors.

How much explanation we provide should depend on the consequence of the result. A reordered list may need only a small cue, while an automated change to a customer record should show what changed and give the user a way to review it.

Building Beyond the Chat Panel

A chat panel can often send messages to one backend endpoint and render the returned text. An embedded experience needs a closer connection between the interface and the rest of the application. The backend gathers permitted context from the current record, while the model returns an output the interface can place into the task.

Structured output becomes especially useful here. Instead of returning a paragraph that describes a proposed update, the model can return fields that the application validates and renders through existing components. The user can then review the proposed state in the same interface used for an ordinary change.

In simplified TypeScript, the backend could treat the model’s response as a proposed change rather than application state:

The model proposes the update, but application code validates its shape and keeps it pending until the user approves it. The model therefore contributes to the workflow without gaining direct authority over application state.

Workflow automation adds another layer because the backend must own execution and recovery. The model can recommend an operation or choose from allowed tools, but application code still checks permissions and validates the request. It also records the result and determines when human approval is required. A simplified execution boundary could look something like this:

The model can propose an action, but the backend determines whether to pause or execute it and records the result.

Designing the interface and the backend together prevents AI from becoming an isolated feature. It allows the capability to use the application’s context while preserving the controls that already govern the workflow.

Choosing the Right AI Surface

The right surface depends on how the task begins and how much responsibility the AI takes on. The following comparison gives us a practical starting point:

It’s good to keep in mind that multiple patterns can appear within the same application. A support system might route incoming cases in the background and place an AI-generated summary inside the case view. In addition, it can guide a known escalation workflow while retaining chat for issues that require further exploration.

To choose among these surfaces, we should begin with the user’s task rather than the model’s capabilities. Chat earns its place when conversation is part of the work. If the application already knows the relevant object and desired outcome, we can usually bring assistance closer to that context. When AI can change application state, the interface must provide the right level of review and recovery.

Wrap Up

Chat will remain a useful AI surface for open-ended work, but it does not need to contain every AI capability. Embedded assistance can reduce the effort of describing context, while workflow automation can help users move through a larger task. Adaptive and invisible experiences extend AI into the rest of the product without requiring every interaction to begin with a prompt.

For full-stack developers, the broader opportunity is to design AI around the work people already do. That means connecting models to the application’s context and returning results through interfaces that users understand. The strongest experience may include a conversation, but it can just as reasonably look like a better form or a more helpful workflow.

For instance, the Progress KendoReact library provides several ways to build these experiences without defaulting to a chat panel. The Inline AI Prompt and SmartPasteButton bring assistance into content and form workflows. Data Grid Semantic Search and AI-powered highlighting extend the same idea to data-heavy interfaces.

For more on building AI-powered applications and experiences with Progress, check out the following resources: